Game Development Community

SetSkinName And Zones

by Scott Doerrfeld · in Torque Game Engine · 07/17/2007 (1:15 pm) · 2 replies

So I've noticed a bug with the setSkinName function for DTS objects. If I call setSkinName on an object, the material actually only changes for clients who can "see" this object. For example, say I change the texture on an object in Zone 1 and Client X is in Zone 2. When Client X enters Zone 1, the object displays the base material for Client X, rather than the new material. This is because the object wasn't visible to Client X when the material change happened.

So......am trying to figure out how to fix this.

Should I change the functionality of setSkinName so it actually changes the texture in the base/default material list? How do I get access to that list?

Or is there a way to update the material for an object even when I am not seeing it?
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Torque Owner Scott Doerrfeld
#1
07/17/2007 (6:50 pm)
So I realized that there is a function called 'setScopeAlways' which will cause any NetObject to be ghosted to all clients at all times. So, one solution to the above skinning problem is to call %player.setScopeAlways() on each player object as they get added to the scene. This means every client will get the skin update on any one player, regardless of whether they are in the same zone or not when the update is called.

Though I am not sure of the impact it could have on network performance to have EVERY player scoped to all clients at all times...does anyone know? Does this mean they will always render? Does it mean I will always get their movement updates even if they are in a different zone than me?

Torque 3D Owner Stephen Zepp
#2
08/07/2007 (1:56 pm)
The normal strategy for something like this is to make sure that the data that gets changed while not in scope is set to update during an InitialUpdateMask check. In most complex objects, you'll see an if clause that has "InitialUpdateMask" as part of the test for writing a logical grouping of data to the bitstream, and any change that can occur while an object is out of scope (as you mention) should have a write (and read) to the bitstream in this clause to cover that scenario.