I just re-read this later and realized I forgot to say can make them really good at hitting you by making them set their angular velocity every frame instead of adding to it.
they're always at maximum angular velocity so they just go flying whenever they hit the ground. usually they go flying towards you since they're always rotating in a way that would head towards you, but they miss half the time and go too fast to dodge.
So #2 is off the list for now, since I can't figure out how to make the marbles actually good at hitting you.
Never mind, just forgot to orthonormalize my basis in _input() as well as _process() and it could decay due to rounding errors if you went too long without orthonormalizing it by switching gravity.
Oh wow, it's actually crashing every time I do that. Lovely, I should probably update to the latest version they've probably fixed this
Current to-do list:
1. Make the player marble inherit from a generic "marble" so I can make AI-controlled marbles as well.
2. Make AI-controlled marbles that roll towards the player and try to knock them off the stage.
3. Allow marbles to jump, with variable strength.
4. Make marbles break upon forceful impact, with variable resistances against this and "soft" surfaces that prevent it entirely.
so now my camera acts how I want; gravity rotation is not instantaneous but mouse motion is. I still need to start doing a raycast to make the camera move towards the ball to avoid having things between the camera and the ball, but other than that the camera is pretty close to done.
finally figured out an issue that was causing my basis to break (all zeroes; no rotation and a scale of 0)
it was an error where very small numbers were not equal to zero but were small enough that normalizing the vector had no effect. rounding the vector fixed the issue. had a ton of trouble with this. also orthonormalize the basis regularly now, since at one point it ended up not being orthonormalized which ALSO casued it to break in the exact same way apparently somehow maybe?
oh and the devs marked this issue as "not critical. fix in 3.2"
Camera code has been fixed up somewhat. Camera is now separate from gravity, and should rotate at PI radians a second to have its Y+ aligned with the floor normal, prioritizing Z when flipping completely upside-down. Still need to do the raycasting and redo the lagging-behind-the-ball thing
So I noticed gridmaps were a bit more slippery than they should be. "Well, that's no big issue, I'll just go and change the physics material..."
Gridmaps cannot have physics materials applied, and because the default material changed in 3.1, they're way too slippery for me to actually use. 😒 greaaaaat.
I'm currently rewriting the camera code to:
1. Not go through walls! About to do my first thing with raycasting 😃
2. Not be sluggish! Current camera control relies on interpolation between two transforms for the whole lagging-behind-the-ball thing, but that makes rotation also sluggish. I'm redoing a whole bunch of stuff with a better system now that separates camera orientation from gravity so I can make it smoothly switch between gravities while not being sluggish to respond to your inputs.
Update: I of course immediately lost this while trying to add a second object to my MeshLibrary 🙃 Good job, Moth
New features since the last video:
1. Camera control! You can actually look around!
2. Camera lag! The camera now has a target position that changes rather than the camera just changing instantly, and it moves towards that. The further away it is, the faster it goes.
3. Gravity changers! The arrows change your gravity to the direction they point.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!