Asteroid collision

[MCMic]

At some point we warped through an asteroid, and expected to crash but we just went through, at least from main screen point of view.

Is there asteroid/ship collision?
Is it taken into account while warping?

Maybe this was a visual artifact, like the main screen camera went through but not the ship.

[smcameron]

Heh, it appears that there is no player-ship/asteroid collision detection.

The collision detection in general works by checking distances between objects at the time that various objects are moved by snis_server (that is to say, at 10 Hz). Very fast moving objects (e.g. during warp) may indeed tunnel through each other even if there were asteroid/player-ship collision detect in its current form. To fix that, I suppose there would need to be something more sophisticated, like taking the previous and new positions of each of the two objects being compared, and sort of replaying time at a higher frequency depending on object sizes and relative speeds while checking for collisions, or... something.

The way asteroids are spinning, and might by this spinning be expected to impart an impulse to the player ship, asteroid/player-ship collision response should probably be modeled via some kind of collision capsule, as is done with OBJTYPE_BLOCK. (You can test this with the TESTSPHEROID Lua script... if you edit it you can change the rotational velocities of the 4 objects, then drive your ship into them and see how they bat your around when you run into them, or because they are rotating, they slam into you.) Perhaps this OBJTYPE_BLOCK collision response should be done for other objects as well as asteroids (NPC ships, starbases), giving those objects an invisible collision surface and providing a way for generic objects to have a collision surface. That is something I've thought about a little bit, vaguely, and it probably is worth it for asteroids, and probably starbases, maybe not for NPC ships, or maybe only the bigger ones.

[smcameron]

Hmm, asteroid meshes, scaling, and rotation is done entirely client side currently, though I think the mesh choice, and scaling are done in a deterministic way depending on object ID, so this could be duplicated on the server side. The rotation rate is also done deterministically, but, the initial orientation is the same at the time the asteroid is created, but, the time of creation will differ from one client to the next, and from the server, so the orientation becomes problematic (different on each client, different on the server). Orientation could be moved server-side, at the cost of network bandwidth (16 bytes per asteroid per tick.) Only the scale is needed server side for "simple" collision detection, but the rotation will need to be handled for the OBJTYPE_BLOCK style collision response.

[smcameron]

Added rudimentary player-asteroid collision detection:

• eb15b6e Add player asteroid-collision detection

[MCMic]

Starbase is a complicated topic regarding collision, it would feel better if there was collision, but all beginners I’ve played with went through the starbase at least once before managing to target the magnet. Maybe it would actually help, if the collision somehow bounce us to the magnet despite the damage.
I guess we should at least try it and see how it feels. As long as it does not destroy the ship, it should not be too annoying to collide with the starbase and it would feel a lot better than going through.

[smcameron]

Good point about the docking ports... And with the variety of stations, each kind would need its own specialized collision surface, so it's quite complicated. Probably easiest way to get better collision detection with the starbases to re-build all the starbases out of OBJTYPE_BLOCK to get the collision detection that's already there, and allow attaching docking ports to OBJTYPE_BLOCK, but it would not be the most aesthetically pleasing way to do it. I think I'll let that problem lie for right now, maybe with a bit of time the solution will become more obvious to me.