Dynamic Field modification has no impact in Torque World
by Aidan Sliney · in Torque Game Engine · 10/04/2007 (11:20 am) · 1 replies
Hi there, I don't know if this is the most appropriate part of the forum to ask this :
I've modified the engine code in order to make convert 'massCenter' from a static parameter to a dynamic one. It is no longer part of the datablock parameters of the Vehicle class.
I can easily access and modify masscenter from the script : %myObj.massCenter, but I can't see the effect of the modification in the Torque world.
Does it have something to do with the client/server structure of torque ?
Do you know how I could make the modification from script have an impact in the Torque World ?
Thanks !
I've modified the engine code in order to make convert 'massCenter' from a static parameter to a dynamic one. It is no longer part of the datablock parameters of the Vehicle class.
I can easily access and modify masscenter from the script : %myObj.massCenter, but I can't see the effect of the modification in the Torque world.
Does it have something to do with the client/server structure of torque ?
Do you know how I could make the modification from script have an impact in the Torque World ?
Thanks !
Torque 3D Owner Stephen Zepp
Now, what I think you might be looking at doing is working with persistent fields, which is an entirely different animal.
Persistent fields are effectively "shared memory" between a class member variable (declared in c++), and script. After implementing the member variable within your class, and writing c++ code to actually use that member variable (for example, what is changing the massCenter supposed to actually do? Does it affect physics? Does it affect rendering?), you must then expose this member variable to script via the ::initPersistFields() class method, which is inherited from the SimObject class.
Now as you have guessed, even with changing how this new member variable is used within the class, you have to take into account the client/server architecture, and network this new class member variable so that it can be delivered to the client. In many cases, this will be done within the ghosting system, via the ::packUpdate() and ::unPackUpdate() methods which are inherited from NetObject.
Finally, you will note once you start searching for ::initPersistFields() within your class that in many cases, member variables like this within classes that are intended to have multiple instantiations (Player, Vehicle, etc, vs PlayerData, VehicleData) are not normally exposed like this directly--instead, when appropriate, they are exposed via ConsoleMethods that in turn call accessor methods within the c++ side of your implementation.
This is more style than anything else--nothing really stops you from using persistent fields directly for "active" classes, but it's more common to create accessor methods within your class for these member variables, and then expose those accessor methods via ConsoleMethods so TorqueScript can call them when appropriate.