Maximum datablock size

#1 Well, the problem with splitting up into several datablocks is that the player class is only really designed to have one.

I guess I may have to do some manual net stuff, but any suggestions would be much appreciated.

Ian

#2 What are you sending in the datablock that's taking up so much space?

#3 Hey Josh.

The data for our human simulation system. That is, around 120 "joints" and their data: lower limit, upper limit, mass, strength, their vector of rotation, and a few other necessery pieces. The vectors are what pushed it over the edge, for the past six months that data has been contained in the dts, but it needed to be moved.

The data could be stored client side (changing it wouldn't help as the server is authorititive) but I'd like to support server side mods.

Ian

#4 I would suggest using a datablock for each joint. It sounds like you have enough data per joint that doing so would be worthwhile. It's sort of painful, but it shouldn't be insurmountable. One useful trick here is that you can generate datablocks using script, instead of having to type it all out by hand.

Or you can do some sort of custom NetEvent based solution, but I think just using the datablock system would be easier.

#5 As Ben mentioned, I'd suggest looking into NetEvent. Look at the recent PathManager code snipit here. Use the chunking to send across the joints. It shows how the PathManager maintains a state on the server and client sides and uses NetEvent to "chunk" the data across in blocks of 10 nodes.

Once I figured out how the chunking worked, it wasn't that hard to manipulate into a more generic application of the system. I set my "host" object to be a scope always ghost and then use the scripting system to have the client request the "chunks" from the server for that "host".

In script, that might look like a server command from the client:

commandToServer('SendNodes', %hostObjectID);

Which the server would recognize and then call a ConsoleFunction:

function serverCmdSendNodes(%client, %hostObjectID)
{
   // Send nodes to client
   %client.transmitNodes(%hostObjectID);
}

The transmitNodes ConsoleFunction should be a part of the NetConnection, and should locate the hostObject by its ID, then "chunk" across the nodes to the client.

The server maintains a list of node collections. After "Phase 2" of downloading the mission (Ghost Always Objects) it calls a server command on the client that tells the server to transmit a specific collection of nodes, in "chunks". The part of the resource to focus on would be "PathManagerChunkEvent". Each chunk event will break apart the collection of nodes into a smaller collection of, say, 10 nodes and then (much like packUpdate/unpackUpdate) will send the nodes across. Make sure you set your events to be GuaranteedOrdered so they will be processed in order. Then, on the client side, the processEvent method is called where you can then reconstruct the entire collection from the smaller "chunked" collections.

Once understood, this method saves headaches...

- Brett

#6 Thanks Ben and Brett: I'll definitly look into the netEvent system you described.

Ian