T3D 1.1beta 3 BUG Crash when add more than 38 nodes for DecalRoad or MeshRoad - RESOLVED
by Sibsan Suksuchano · in Torque 3D Professional · 10/01/2010 (3:09 pm) · 12 replies
Build: T3D 1.1 Beta 3
Platform: Windows 7
Target: load mission
Issues: Crash when open level that has more than 36-40 nodes of decalRoad or MeshRoad.
Steps to Repeat:
1. Create some level with MeshRoad that have 36 nodes up.
2. Save level.
3. State new game and open that level.
4. Crash.
More Info
Debug message said "DecalRoad::unpackUpdate, failed to find Material of name &s!".(I think "&" should replace with "%").
I have found some thread about this issue they say it about maximum packet size of road is too big.
Could somebody give me a hotfix.
Platform: Windows 7
Target: load mission
Issues: Crash when open level that has more than 36-40 nodes of decalRoad or MeshRoad.
Steps to Repeat:
1. Create some level with MeshRoad that have 36 nodes up.
2. Save level.
3. State new game and open that level.
4. Crash.
More Info
Debug message said "DecalRoad::unpackUpdate, failed to find Material of name &s!".(I think "&" should replace with "%").
I have found some thread about this issue they say it about maximum packet size of road is too big.
Could somebody give me a hotfix.
About the author
Abstract Wings Co., Ltd. (ABWING) is a gaming technology developer especially Arcade Games, we do Hardware Software and also Arts for good games.
Recent Threads
#2
Note that we've only been able to reproduce this using Mesh Roads. Using decal roads has not reproduced this bug yet.
10/04/2010 (7:50 pm)
Bug confirmed.Note that we've only been able to reproduce this using Mesh Roads. Using decal roads has not reproduced this bug yet.
#3
The crash only occurs for us in debug mode but the issue still exists in release mode. We get the same (similar) decal road error message in the log.
11/05/2010 (4:12 am)
I've also experienced this with Decal roads (Not sure of the node count that triggers the problem).The crash only occurs for us in debug mode but the issue still exists in release mode. We get the same (similar) decal road error message in the log.
#4
This means that both road classes are bound in their total number of nodes by the packet size. MeshRoad only reaches the limit faster since it packs more data per node but DecalRoad hits the limit too at some point.
Fixing this is non-trivial though. One way would be to separate the fields of each node record into separate updates, i.e. transmit field A in update 1, then field B in update 2, etc. This would be easiest to implement as it can be controlled through the dirty masking. The best solution would be to add packet splitting to the networking layer which would solve this problem universally for all classes.
01/20/2011 (1:23 pm)
Both decal and mesh roads transfer a significant amount of data in their update packets. Essentially, both are sending the complete states for all nodes over the wire. However, update packets in Torque are fixed-size and there is no support for breaking an update into multiple packets.This means that both road classes are bound in their total number of nodes by the packet size. MeshRoad only reaches the limit faster since it packs more data per node but DecalRoad hits the limit too at some point.
Fixing this is non-trivial though. One way would be to separate the fields of each node record into separate updates, i.e. transmit field A in update 1, then field B in update 2, etc. This would be easiest to implement as it can be controlled through the dirty masking. The best solution would be to add packet splitting to the networking layer which would solve this problem universally for all classes.
#5
BTW, solution 2 I outlined here--splitting update packets of individual objects--is probably technically unfeasible. The networking layer would have to buffer the data, wait for the corresponding follow-up packet(s) to arrive (with all the uncertainties of networking this brings with it), stitch them together, and then call unpackUpdate on the respective object.
01/20/2011 (1:47 pm)
BTW, solution 2 I outlined here--splitting update packets of individual objects--is probably technically unfeasible. The networking layer would have to buffer the data, wait for the corresponding follow-up packet(s) to arrive (with all the uncertainties of networking this brings with it), stitch them together, and then call unpackUpdate on the respective object.
#6
A similar solution could probably be applied for mesh and decal roads.
01/20/2011 (2:03 pm)
I remember paths having the same issue several years ago: all nodes in a path were sent in a single packUpdate, which would bork if it got past the packet size. It was updated to use netEvents to send each node data (I believe it was a resource, which later got merged into trunk) as a chunk. A similar solution could probably be applied for mesh and decal roads.
#7
Great, thanks for the pointer! Checked it out. Yeah, that could be a way to handle it.
01/20/2011 (2:12 pm)
Great, thanks for the pointer! Checked it out. Yeah, that could be a way to handle it.
#8
01/20/2011 (5:22 pm)
Thanks EVERYONE , thanks for work together.
#9
BTW, for a temp workaround, one can increase the packet size through $pref::Net::PacketSize. For local connections, a fixed 4k buffer for the initial ghosting is used (NetConnection::activateGhosting). That should be sufficient but can be increased as well.
Still, I'm working on a proper fix and will post when I have something. Currently following up on an idea that might actually solve this in a much simpler way but need to get a little more network code reading done first.
01/20/2011 (5:30 pm)
BTW, for a temp workaround, one can increase the packet size through $pref::Net::PacketSize. For local connections, a fixed 4k buffer for the initial ghosting is used (NetConnection::activateGhosting). That should be sufficient but can be increased as well.
Still, I'm working on a proper fix and will post when I have something. Currently following up on an idea that might actually solve this in a much simpler way but need to get a little more network code reading done first.
#10
04/12/2011 (6:12 pm)
Fixed in 1.1 Final. (Fixed in 1.1 Preview as well) 
#12
- Dave
04/13/2011 (11:46 am)
Wow, Ted. That sure beats my 50 node road I used while working on the fix. :)- Dave
Full Sail QA&U Lab Intern