Programmer.setSkinName('baffled')

#1 I don't know why the console method works when neither should work

Set your skin name in 3DS Max to base.elevator, and make sure at all costs the b is lowercase

Base.elevator will not allow skin changing
base.elevator.jpg will not allow skin changing

has to be base.elevator

#2 I'm not at home so can't test this myself, but try:

%thisObj.schedule(0,setSkinName,"broken");

If this works, the problem is likely that the object isn't completly set up yet... like I said, not sure till I go home and look at some code.

#3 @James: Sorry, I meant that the texture filename was base.elevator.jpg, not the 3DS Max material name. To the best of my knowledge, the material name in 3DS is completely irrelevant to the exporter.

@Tim: No luck, but thanks for the idea! I'll continue to chew on this until I find a solution.

#4 The problem is most likely your use of single quotes in the script. Single quotes denote a tagged network string (used to help reduce network sends for common strings). For passing parameters to scripts and the like, you should be using double quotes.

#5 That crossed my mind; I tried it with a double-quoted string, but still no success. It's a real head-scratcher... well, for me at least. =)

#6 Are you sure your elevator control has shapebase as parent?

#7 Absolutely... it works fine from the console, it's just not working in the OnAdd() method.

I just discovered another clue: getSkinName() on the object returns broken, which is what I'm trying to set it to, but the skin on the object is the default skin. Is there some command that needs to be issued to refresh the image?

#8 Test the object in showtool.

#9 Works perfectly in ShowTool Pro. I force it to use "broken", and it pops right up.

SetSkinName() seems to work fine, except within the OnAdd() method of this object. If I move the setSkinName() command into a method that gets called when the player activates the object, it immediately switches to the requested skin when the object is triggered. I just can't seem to get it to start up in that state.

#10 Mighty odd.
did you try the schedule() idea with a longer delay ? like maybe a second.

when you say it works fine from the console,
do you mean the server-side console or the client-side ?
(or, if single player, the server-side object or the client-side)

what happens if you:

* start up the server
* connect with a client
* manually set the skinName on the server
--> confirm the client sees the right thing
* connect with a second client (or disconnect and reconnect the first)

#11 When I'm running in single-player mode, and I type .setSkinName(broken); from the client console, it updates the skin correctly.

If I run a dedicated server, connect with a client, and issue a call to a server command that updates the skin, it updates correctly.

If I issue that same setSkinName call in the OnAdd method (with a 5000ms schedule delay, or even 15000ms), the client sees only the base skin, not the "broken" skin. The server echoes the results of getSkinName to the console and it comes back as "broken".

#12 Okay.

what happens if you:

* start up the server
* connect with a client
* manually set the skinName on the server (or use your commandToServer)
--> confirm the client sees the right thing
* connect with a second client (or disconnect and reconnect the first)

#13 Whup! Missed the last part.

That displays correctly on the connected client, but the new client sees the incorrect base skin.
When the command to update is sent again, the new client is updated.

#14 Try something like this:

function ElevatorControl::OnAdd(%db, %thisObj)
{
   echo("Panel added... db= " @ %db @ ", obj= " @ %thisObj);

   %skin = "broken";
   %thisObj.setSkinName(addTaggedString(%skin));
}

#15 No dice. I'm pretty sure the problem isn't with the tagged strings; I've tried direct references and non-tagged strings and everything in between.

I get the impression the problem lies in the communication between server and client, but where? Why? How? It makes no sense! (sobbing uncontrollably)

#16 From the sounds of things, the object isn't sending the new skin string handle to the clients. I'd suggest that you open up the source and put some console echos in to make sure the correct data is being sent and received. Do a search for "SkinMask" in shapebase.cc. It should be self-explanatory from there.

#17 Hey John -

it sounds to me like the SkinName stuff isn't working right during the initialUpdate of the ghost object.
that is, when the object is first ghosted to the client.

as Daniel suggested, search for SkinMask and throw in some debug prints or breakpoints.
specifically in packUpdate() and unpackUpdate(). note that in unpackUpdate() the word "SkinMask" may not appear, so you might need to look at the code to see which readFlag() param corresponds to the writeFlag(mask & SkinMask) in packUpdate().

bear in mind that this seems to be working fine for you once the ghost is already established,
so only bother paying attention when a new client connects. (or more formally, when your custom textured object comes into network scope for a client)

one gotcha which has gotcha'd me a few times is that when an object is first ghosted to a client, if the client's unpackUpdate() calls into script to do some stuff, the script will have problems because the object won't yet have been registered with the simulation. that is, if unpackUpdate() includes a line like "con::executef(this, blah blah)", that's all well and good except on the very first unpackUpdate(), in which case in script the %this parameter will be 0.

i'm a bit tired, hopefully this makes sense. let me know if otherwise.

#18 Excellent! Thank you all for your help... I'm going to wade through some code, and I'll post the updated status in a few days.