fix: sync Moss Mother stalactite timing - #91
Conversation
|
You might be able to simply add the stalactites as entities to the registry under the name In general, if projectiles or other game objects are called from an event by a parent, but then do their own (random) processing before spawning/moving, you can add them as children to that parent in the registry. That will be much less work than trying to make custom implementations for each of them. Otherwise, this system isn't worth making and we could have better done custom implementations for all entities. |
Extremelyd1
left a comment
There was a problem hiding this comment.
Small comment on something that can be removed and an additiona remark when testing Moss Mother:
The antic for the falling stalactites doesn't play on scene clients due to the action PlayParticleEmitterInState not being implemented in EntityFsmActions. See the Antic state of the Control FSM of the stalactites. They can be implemented similarly to other ...InState actions, there is already functionality to handle actions that play only in a specific state and stop when that state is exited.
The code itself isn't that complicated, I just wasn't sure where it should live.
EntitySpawnerdidn't really seem right since the stalactites are already part of Moss Mother's scene and aren't actually spawned entities.The normal FSM sync already sends the FALL event, but the remote client still runs its own random wait and physics, so the rocks can fall at different times or from slightly different positions. This just adds the host's timing and positions to that existing event.
I left the gates out since they feel more like room/world-sync stuff than Moss Mother’s entity FSM.
Does this seem like a reasonable place for this kind of boss-specific exception? And how should we handle similar rooms in the future?