What are dynamic-fields?

#1 Dynamic fields tend to be variables that programmers assign at runtime to an object.

So if you had, $player = ServerConnection.getControlObject(); and then typed $player.score = 100; The score would be a dynamic field. As you said, that variable is not networked so tend to only be used for client side only.

Why are they not networked? Well first it would be very inefficient p2p to have them networked. Secondly, in order to have something networked in Torque you will need to add the variables to the pack/unpack updates as well as for some variables the read/write packet data. The actual data that is sent across the network is quite limited for performance reasons. If you are creating a single player game you don't really need to worry about that though.

#2 Isn't having dynamic fields sort of nonsensical then?

#3 The dynamic variables are stored where they are created which should be the server for nearly all of them.

The client side should only be concerned with popping up GUIs and rendering sounds and graphics.

If you need to send their values to a client you can do a commandToClient, but for most things the client should not be using its own dynamic variables.

Having the variables on the server makes it harder for someone to hack their value locally, for example it may seem easier for every client to keep track of their own ammunition but having the server keep track of ammunition makes it harder for someone to add to their ammunition by using a local console command.

In the FPS example a dynamic variable called client is created under the players ID to keep track of what that particular players controlling client ID is.

The code looks something like:

%player.client = %this;

Then later on in one of the many player methods this value can be retrieved with:

%obj.client

If we need to send information to a client about how much ammunition they have you would do something like:

%ammoName = %obj.getMountedImage(0).getName().ammo;
%currentAmmo = %obj.getInventory(%ammoName);
commandToClient(%obj.client, ShowCurrentAmmo, %currentAmmo);

This wouldn't be possible if the dynamic variable called client hadn't been made earlier.

#4 Yeah that makes sense, but how about showing a player its level, exp, inventory, etc. All of those things are stored server side. I just use commandToClient to get those visible to the player?

#5 Yep. If you're not adding these things to the C++ source and networking them there (for example, see ShapeBase damage level networking), then you'll need to use commandToClient whenever one of those values changes.

The counterpoint to these 'dynamic' members, which are created script-side at runtime, are the members of objects defined in the C++ classes, then exposed to the console. Search for initPersistFields to see where the magic of linking C++ class members to script works.