Paul i am using default constants in sim-eth-es example if you mean these :
gridSize = 64
MAX_OBJECT_RADIUS = 5;
/**
*
*
* @author Paul Speed
*/
public class GameConstants {
public static final String GAME_NAME = "SimEtheral Example 2";
public static final int PROTOCOL_VERSION = 42;
public static final int DEFAULT_PORT = 4271;
/**
* We add an extra channel on the client->server connection to send
* chat related messages. This is its own separate TCP socket that
* avoids tying up the main connection.
*/
public static final int CHAT_CHANNEL = 0;
/**
* Send entity-related messages over a separate channel to avoid
* clogging up the main channels.
*/
public static final int ES_CHANNEL = 1;
/**
* The size of the rendered space-grid cells. This is just a visualization
* setting but it's best if it is at least a multiple/factor of the gridSize.
*/
public static final int GRID_CELL_SIZE = 32;
// To allow players to see farther in space, we'll use a larger grid
// size for the zone manager. We could have also used a wider zone radius
// and we might use both. The gridSize used in a real game is mostly a
// balance between how likely it is that an object will fall into more than
// one zone at a time, with how many objects are likely to be in a zone.
// Also, while the zone radius can be increased to include more surrounding
// zones in a player's view, there is considerably more management involved
// with each new zone, more network messages, etc.. Finding the sweet spot
// will depend largely on the game.
private static final int gridSize = 64;
/**
* The 3D zone grid definition that defines how space is broken
* up into network zones.
*/
public static final ZoneGrid ZONE_GRID = new ZoneGrid(gridSize, gridSize, gridSize);
public static final float MAX_OBJECT_RADIUS = 5;
/**
* Defines how many network message bits to encode the elements of position
* fields. This will be a function of the grid size and resolution desired. Keep in
* mind that objects can be in a zone even if their raw position is not in that
* zone because their radius may overlap that zone. So the proper range needs
* to account for this overlap or there will be odd position clipping at the
* borders as objects cross zone boundaries.
*/
public static final Vec3Bits POSITION_BITS = new Vec3Bits(-MAX_OBJECT_RADIUS,
gridSize + MAX_OBJECT_RADIUS,
16);
/**
* Defines how many network message bits to encode the elements of rotation
* fields. Given that rotation Quaternion values are always between -1 and 1,
* 12 bits seems sufficient based on ultimate resolution and visual testing.
*/
public static final QuatBits ROTATION_BITS = new QuatBits(12);
/**
* Defines the overall object protocol parameters for how many bits ar used
* to encode the various parts of an object update message.
*
* <p>The first parameter defines how many bits are used to encode zone IDs.
* Zones are always defined relative to the player so this will be a function of
* the zone radius. For example, a radius of (1, 1, 1) means a 3D grid that's
* 3x3x3 or 27 different zones. At least 5 bits would be necessary to encode
* those IDs. I use 8 here arbitrarily to give some space for zone radius
* experimentation. 8 bits should support a zone radius up to (3, 3, 2).</p>
*
* <p>The second parameter is how many bits are associated with the real
* object IDs. These IDs are not sent with every message so it's important that
* the value properly encompass all potential IDs. For example, using a long ID
* from an ES you would need 64 bits. If game sessions are short lived and your
* object IDs are only ever 'int' then 32 bits is the proper value. This should
* usually be 64 bits and I'm keeping it as such... even though this example
* could get away with 32 bits. Since these values are not sent with every message
* and people might cut/paste these settings, I'm going with the safer choice.</p>
*
* <p>The last two parameters are the Vec3 and Quat bit sizes defined above.</p>
*/
public static final ObjectStateProtocol OBJECT_PROTOCOL
= new ObjectStateProtocol(8, 64, POSITION_BITS, ROTATION_BITS);
/**
* Defines the 3D zone radius around which updates will be sent. The player
* is always considered to be in the 'center' and this radius defines how
* many zones in each direction are included in the view. (A 2D game might
* only define x,y and leave z as 0.) So a radius of 1 in x means that the
* player can see one zone to either side of their current zone.
* A total zone radius of (1, 1, 1) means the player can see a total of 27
* zones including the zone they are in.
*/
public static final Vec3i ZONE_RADIUS = new Vec3i(1, 1, 1);
}
Note : I don’t have this problem when using SimplePhysics system.
Which is weird because the values you report to the zone manager should effectively be equivalent… unless somehow the bounding box you send is messed up. (most likely cause)
this thread safed my life I stared on the code for hours. My ship did stuck in the corner 0, 0 of a not visible rectangle (but the debug printing did say it is still flying) and on the console I had exactly this error you had. One single line did fix everything
Sorry for pumping the thread for just say: “Yay!!!”
I stared on the code for hours. My ship did stuck in the corner 0, 0 of a not visible rectangle (but the debug printing did say it is still flying) and on the console I had exactly this error you had. One single line did fix everything 
