I’m trying to implement death and re-spawning into my game which uses sim-eth-es as its base. I can set position when the player first spawns, however when I attempt to ‘warp’ the player entity to a new spawn point after death it seems like simethereal doesn’t notice that the zone for the player entity has changed and it stops sending object update messages to the client, this only happens if the spawn position is far enough away from the ‘death’ point to be outside of the network zone. How should I implement this functionality?
Well, it depends on how you are warping them maybe.
There isn’t anything I can think of that would cause this if the zone manager is being notified appropriately. After all, leaving a zone is a pretty common thing to happen.
Its being set by doing stuff like pos.set(x, y, z) in body class. I logged body position location in the bodypositionpublisher updatebody class, it shows the correct location is being used in the bodyposition publisher. From what I can tell it doesn’t look like the client is updating its zone correctly. If I load another client I can see my players tank loaded and driving around in the new spawned location, that information just isn’t being given to the original client until it enters the clients zone. (I determined this by printing output from the sharedobjectupdater objectupdated class)
Is there a way to force update the clients watched network zone?
Normally… by moving the object. Any other way would mean the client would be briefly watching the wrong zone. Which doesn’t sound so bad until you realize that all of its messages are relative to the zone that the server thinks… so if the client and server are not in sync with the current zone then the messages are total garbage.
It’s possible that the zone ID compression is messing things up here. Since all zone IDs are sent to the client relative to the current zone, it’s possible that when the zone changes more than ‘zone radius’ that an invalid ID is sent.
I’m only speculating, though, since the zone change message should really have an uncompressed zone in it. I will try to find time to look at the code soon.
Interesting. I’ll be using the same functionality - but haven’t gotten to that part yet. I guess I figured it was just changing the position of the entity, but it doesn’t sound like it.
So, I spent a bunch of time looking at this today … From what I can tell Ethereal is simply not designed to handle a position change that moves the entity out of the current zone. It has no provisions for dealing with that at all. I was able to hack a solution in that basically just does a call to zoneIndex.setCenter(selfPosition, entered, exited) with the new warped position to recenter the network zones but that is not a good solution. I was able to get the desired results using that method.
Basically when the entity moves out of the current network zone, it no longer publishes a new position using stateChanged(StateBlock b) which means that it always thinks it is in the old network zone because zoneIndex.setCenter(selfPosition, entered, exited) is called in ‘endFrame’ with the same selfPosition.
Any thoughts on a more elegant solution would be appreciated.
You may be misusing the word “zone” here… because obviously you can move out of the zone or you’d be stuck in a 32x32x32 space.
If you mane “out of the current zone + zoneRadius” then it’s definitely true that I never tested that.
I wonder if a warp will require removing the object from the zone manager and then readding it or something. I will have to take a look at what can be done without busting all of the optimizations.
That is what I mean yes… I was using the term zone to mean all of the currently ‘watched’ zones for a particular network state listener. So currentzone + zoneRadius.
Thank you! If there is anything I can do to help, let me know.
package ch.artificials.bg.net.server;
import com.simsilica.mathd.Vec3d;
public interface ShipRegistrar {
public void register(Long shipId, Vec3d position);
}
So the game session object get just a ship registrator and has nothing to know about connections but the service knows it. Ok it might be hackish but it works and I do understand my solution (even 2 months later now).
I do not have a warp but a game reset (which is actually also kind of a warp, because I also make a big position jump depending how far you are away from the base).
In my opinion java gives quite a lot tools to hide and bind that connection in a way that you can do this re-register of the ship with a new position in pretty nice way (also from unit testing perspective it is not that bad). But might be that I oversee something!!
Wondering if someone already filed a bug for this on the SimEthereal github pages. (I haven’t looked.)
I’m back from a week+ long vacation without a computer. I’m trying to carve out some time soon to dedicate to bugs in my OSS projects. While I make no promises that I will hit a particular issue or not, having problems reports makes it way more likely.
