Custom persistant fields question

#1 Grr i'm such an idiot. Ignore this. I fixed it. The field names I added had spaces, and it doesn't handle spaces.

#2 Think twice, post once. But good of you to share the solution to your problem with us.

#3 Posting for some reason tends to make me look at the problem differently than if I didin't post :p I can't explain it but I can rack my brain for days on a prpblem, post it, and suddenly the answer hits me.

#4 Hmm, well the problem is fixed but i'm hitting a data flow problem now.

In the constructor for sky I inditialize default values. In the onAdd() function, I transfer the field values to where they need to be. It seems Sky:onAdd() is called twice though (even though I only have one sky). The first time around my, for lack of a better term, set datablock values are there. The second time around its reverted to the default values as set in the constructor.

Stepping through the code is quite a mess. The Sky constructor is called 3 times before I end try to load a mission. The onAdd is not called. Then when I start to load amisson, the constructor called once more, followed by an onAdd with the correct loaded values. Then after the mission is finished loading yet another sky constructor is called followed by an onAdd with the default values, not the loaded ones.

My lord how many skys is the engine trying to make? Can anyone explain this behaviour?

#5 Sure. The constructor is called at arbitrary times for internal usage. Some things in the code like to instantiate objects to see if they're, say, GuiControls before they add them to editor lists. So that accounts for the calls to the constructor. I take it you didn't try looking at the call stack, eh? :)

The calls to onAdd are also simple to explain. As you should know from reading the docs, Torque uses a ghosted networking system. So every object that is networked exists twice, once on the server, once on the client. The client side instance receives its state info from the server, so it starts with the default values; the server object is set up by your script.

#6 But when I am the server, I still get 2 copies?

#7 Ok I see it now. I thought I could avoid the network implications at least in the short term while I was testing. Guess not.

I'm sure my problem them stems from the fact that I do not currently have code in packUpdate and unpackUpdate for the new fields. Gues i'm going to have to figure out how the packing and unpacking is laid out so I can add these.

Thanks for your help Ben.

#8 You're welcome.

And please read the docs on SimObject and co. They will save you a LOT of work.

#9 I have it all working now and it is very sweet. I learned a lot doing it to, and i'm going to be posting the patch from the work I did. I'm starting a new thread about it, but just wanted to say thanks for the help.