Can someone explain this bit of TorqueScript to me?
by Robert Lee · in Torque Game Engine · 01/24/2005 (9:06 am) · 3 replies
From particleEditor.cs (line 331)
I had do something similar in my own particle editor work and I'd like to understand what I'm doing.
Thanks.
//grab the client-side emitter node so we can reload the emitter datablock
$ParticleEditor::clientEmitterNode = $ParticleEditor::emitterNode+1;I had do something similar in my own particle editor work and I'd like to understand what I'm doing.
Thanks.
#2
01/25/2005 (9:01 am)
Thanks, that helps.
#3
It works now only due to some very implementation specific details of the engine, could break at any time, and as Martin says, won't work for remote connections.
The "proper" solution in this case would probably be to implement a subclass of ParticleEmitter that would maintain a local pointer to its client version or something similar. Slightly hackier, but at least the details aren't QUITE as horrific.
01/27/2005 (5:39 pm)
That is, incidentally, a HORRIBLE HORRIBLE HACK, which I am shocked made it into the particle editor code.It works now only due to some very implementation specific details of the engine, could break at any time, and as Martin says, won't work for remote connections.
The "proper" solution in this case would probably be to implement a subclass of ParticleEmitter that would maintain a local pointer to its client version or something similar. Slightly hackier, but at least the details aren't QUITE as horrific.
Torque 3D Owner Martin "Founder" Hoover
The ParticleEmitterNode class is a networked object, meaning it exists on the client and the server.(Even if it's just you running Torque by yourself, there is still both a client and server running)
When editing the particle emitter you are constantly changing the dataBlock values for the emitter. In a strictly server/client arrangement, datablocks are not meant to be dynamic. In general it's intended for all the required datablocks to exist when a client connects to a server, so that they are sent once, with no need to constantly re-send them.
Now when you run into a case where some field(s) of the datablock need to be changed constantly, it's wasteful to re-send the entire datablock, most of which might not have been changed. Often the solution for this is to make the dynamic fields a member of the instanced object, and using a NetMask, send all the clients only the data that has been changed.
Now for particleEmitters, many of the dataBlock fields are constantly being changed. In order to make them dynamically updated would require a good bit of code that would really only ever be needed during the editing process. (Unless you want to dynamically create brand-new particles on the fly through code and have them properly networked)
So instead of having to add a lot of code to sync client and server data, the editor basically takes a quick shortcut, ignores the server and sets the new particle data on the clients ghosted version of the object.
To do that, you need the ID. Now just above that line in particleEditor.cs you can see what's contained in the $ParticleEditor::emitterNode global:
$ParticleEditor::emitterNode = new ParticleEmitterNode()
So that Global is the ID of the object in the server side of the engine. But since it is a networked object, once the server side creates it, the server tells the clients to create it. And since this is all taking place on a single machine, the next object to be created is the client ghost, and it's ID number will be 1 higher then the servers.
Basically it is saying Take the ID number of the server object, and add 1 to it in order to refrence the client's version.( so we can edit it on the fly).
This works just fine when it's all happening on the same machine, but won't work for remote connections.
Hopefully that made some sense, since I just condenced a whole lot of Torques networking code into just a few words.