Game Development Community

Networking issue

by Adam Beer · in Torque 3D Professional · 10/18/2014 (10:54 am) · 8 replies

I am running into some kind of issue with networking in T3D 3.5. I have a level with quite a few objects (872 objects) and its having issues registering all the ghost objects I think. I added 2 item class objects and while loading I got disconnected for invalid packet: failed to register ghost "you have an incorrect version of the fps starter...". In the console its saying it failed to load the datablock:

ShapeBase::onAdd - no datablock on shape 7191:Item ((null))
Connection error: Invalid packet. (failed to register ghost).
CDROP: 5943 IP:28.6.80.61:15035 <---this isnt even my ip either...

Another strange thing is I have 2 particle emitter nodes for fire and 1 of them randomly spawns particles from 0 0 0 sometimes, while the emitter node is in the correct place. Anyone have any ideas what could be going on here? I didnt think I would be running into these kinds of issues with only ~870 objects.

PS. On a side note, are SpawnSpheres ghosted at mission start and if so - whats the point? Why would a client need those?
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Associate Chris Haigler
Jester Dance
#1
10/18/2014 (12:57 pm)
You're well under the stock limit on ghosts (4096).

All of the errors point to some datablock either not being loaded (script error?) or being invalid for some reason (missing texture/sound/etc.). The result is the client trying to create a 'ghost' of an invalid object.

Edit: SpawnSpheres are marked 'ScopeAlways' but at first glance this seems like an oversight. SpawnSpheres inherit from MissionMarker, a legacy class from Tribes 2 dev. MissionMarker needed to be 'ScopeAlways' because they were used as waypoints that were seen by all clients.

I'm not sure there's any reason to ghost spawn spheres at all.

Torque Owner Adam Beer
Ignition Games Inc.
#2
10/18/2014 (1:18 pm)
Thanks for the reply Chris. There dont seem to be any errors with the datablock as I already have an object using the same datablock in the mission. I turned on net debugging and on mission load im getting "Item unpackUpdate does not match packUpdate" and it looks like its coming from the PositionMask. I have made no changes to the networking code or the item/shapebase/gamebase/sceneobject class's either.

As for the spawnSpheres, what netflags would I set on them to have then just be non-scoped, non-ghosted server objects?

Associate Chris Haigler
Jester Dance
#3
10/18/2014 (1:32 pm)
Does setting $pref::Net::packetSize to a higher value (try 1200) have any effect?

In the SpawnSphere::SpawnSphere constructor, add:

mNetFlags.clear(Ghostable | ScopeAlways);

They may be marked as Ghostable & ScopeAlways so that they work correctly in the editor, but if that's the case the net flags should be adjusted dynamically based on the value of gEditingMission.

Torque Owner Adam Beer
Ignition Games Inc.
#4
10/18/2014 (2:03 pm)
Im currently testing in single player so I believe for local connections it gets set to a very high number in the engine anyways, but I tried 1200 and that had no effect.

The results ive been seeing have been been random and now im just seeing some of my Item class objects be invisible. I can see them and select their bounding boxes in the editor but as soon as I try to move one, the engine crashes.

Ive added those changes to the SpawnSphere, hopefully that'll speed up load times a bit! (I have ~200 spawn spheres in my mission)

Torque Owner Adam Beer
Ignition Games Inc.
#5
10/18/2014 (2:33 pm)
After more testing and checking...it turns out that I did make a change in the engine. In NetConnection::checkMaxRate() I had upped the local connection packet size to 2048 from 1024. Im not a networking guru but Im going to assume that in conjunction with this packet setting and the massive amount of objects being loaded, the packet size went over a limit it shouldnt have which caused these issues. Would I be right in this assumption?

if (isLocalConnection())
   {
      packetRateToServer = 128;
      packetRateToClient = 128;
      packetSize = 2048; // Changed back to 1024 and like magic, everything worked again
   }

Associate Chris Haigler
Jester Dance
#6
10/18/2014 (3:05 pm)
Yep. Packet size needs to be kept below the MTU size for the underlying network otherwise you'll get fragmentation or other undefined behavior. Most of the networks you'll run into will use an MTU of 1500 but there are lots of exceptions to this rule.

I wouldn't set packetSize above 1200, and even that is high for a multiplayer game.

Torque Owner Adam Beer
Ignition Games Inc.
#7
10/18/2014 (3:09 pm)
That is exactly what I thought I read somewhere! Thanks for clarifying Chris!

In case any of the SC guys are reading, would it be a good idea to add a comment around that line that states exactly what Chris pointed out?

Torque Owner Daniel Buckmaster
T3D Steering Committee
#8
10/18/2014 (6:24 pm)
We'd accept a PR along those lines!