Object animation's "saved" state

[boblishman]

OK ... I have managed to get my first "real" door working using the IPO animations (I even managed to incorporate sounds that are actually synchronised to the animation!) ... but ... (oh, why do I hate that word so much!) ... I have noticed something about the animation that is "puzzling"... and wonder if I need to add something to my alcscript to "fix" it.

It seems that the position of the door (open or closed) is automatically stored in the .sav file for my Age.
If I exit my Age with the door open, when I return it is still open.
However, if I then press the door button (to close the door), the animation starts from the CLOSED position. (It works correctly if I exit the Age with the door closed - obviously!).
Once the door has "snapped" into the closed position and then it opens, it then continues to works correctly. It´s just the FIRST time I click the button upon entering my Age (with an OPEN door) that forces the door to the closed position in order to complete the "opening" animation for the "first time".

It seems that the .sav file is remembering the position of the door but not the "state" of it ... and it seems my Alcscript "forces" the door animation to always start from the Closed position when I first enter the Age with an OPEN door.

Here is how I made the door ...

1) the door is triggered by a buttton called "DoorButton"
2) The door is called "Door1"
3) the click region is called "Doorswing"
4) The avatar animation empty is called "DoorButtonOneshot"
5) The sound emitter is called "emit_doorswing"
6) The door ogg. sound is "psnlCloset_close" (Cyan's)
7) Avatar animation is called "DoorButtonTouch"

and the relevant alcscript ...





any ideas anyone ?

(I´m guessing it has someting to do with "nextstate" ... but I really have NO idea ... )

[Nadnerb]

I'll start off by saying that this is the expected behavior. If you check out the demonstration age "AnimatedDoor" more closely, you will see that it does the same thing.

The reason for this is because animation states are saved (not excluded) and responder states are not saved. (excluded) The result of this combination is that the responder is reset to the first state when you link in, but the door remains in it's saved state. The ideal solution would be to save the state of the responder so both the animation and control states would be persistent. (no magically closing doors while you're not there) However, I have done no testing (nor even attempted) to change the exclude states on these things, so I can't tell you how to do that.

The way this should be handled is through SDL states, and python. This would require passing the animation responder to a python script and calling the script from the control buttons. The script would read SDL states on link in and would handle all the door control events. (saving them to SDL) I might be able to tell you how to do that, but not for a week or so, since I'm away from all my uru stuff at the moment.

[Paradox]

SynchState flags can be set on all plSynchedObject derived classes using AlcScript.

(I don't have any example in front of me, so I'm doing this from memory. If someone still has a copy of the .blend file for my Pahts shell, please double check my 410Door object and tell me if I'm correct.)

Code: Select all

[objectname]:
    type: object
    synchflags:
      - <flag values here>

The possible flags:

Code: Select all

    enum Flags {
        kDontDirty = 0x1,
        kSendReliably = 0x2,
        kHasConstantNetGroup = 0x4,
        kDontSynchGameMessages = 0x8,
        kExcludePersistentState = 0x10,
        kExcludeAllPersistentState = 0x20,
        kLocalOnly = kExcludeAllPersistentState | kDontSynchGameMessages,
        kHasVolatileState = 0x40,
        kAllStateIsVolatile = 0x80
    };

In Alcscript, specify all flags in lowercase without the "k" prefix. Ex. "dontdirty"

Edited to add: Flags set on the main object will propagate to all sub-objects created from the object AlcScript. Additional flags may be set on responders as needed. Hopefully this issue will be resolved at some point so that flags are not duplicated due to propagation to children.

[Nadnerb]

Thanks Dox.

That's what you should do then, either set the door to excludepersistentstate or the responder to not exclude. (ie, use the field, but with a bogus flag so it will write an empty bitmask)

[boblishman]

That's what you should do then, either set the door to excludepersistentstate or the responder to not exclude. (ie, use the field, but with a bogus flag so it will write an empty bitmask)

errr ... could someone please translate that into a language I can understand ...

what exactly would I put into my Alcscript to SAVE the "open" state of the door ?

(This also raises the question of multiplayer situations ... would all players see the same "state" of the door using this method ? ?

[Nadnerb]

That means that if you want the responder to remember your door state:

Remember that I can't test this, so try it and see if it works

Code: Select all

[object containing responder]:
    type: object
    synchflags:
      - oogaboogabogus
    animations:
        # if you gots animations on this object, they're goin here
    logic:
        actions:
             # and your responder is in here

[boblishman]

no luck I'm afraid ... door still "snaps" to closed position before opening ...
(alscript exported without any complaints)

[Robert The Rebuilder]

boblishman: Use PlasmaShop's PRPTool to open the door's SceneObject in your PRP file. Then click on the Synched Object Info link, which will show a dialog with checkboxes - one for each of the enumerations that Paradox listed. If the plugin interpreted Nadnerbs' "oogabooga" nonsense flag correctly, then there should not be any checkboxes checked. Otherwise (if there is a checkbox checked), report it as a bug in the plugin.

[boblishman]

here's what I've got ...

door1.jpg (77.83 KiB) Viewed 4840 times

(means absoultely nothing to me I am afraid ... )

[boblishman]

I'm just guessing again ... but does this "problem" have anything to do with the "curstate: 0" line in the door1 Alcscript code ? ..(I´ve juest read the definition of "curstate" is the other thread ... )