[solved] How can I script a door to always open "forwards"?

[Legacy_BCH]

               The default behavior of doors in the game appears to be to always open away from the character that is opening the door, if the door is one that opens horizontally (rather than a portcullis, for example).

I'd like to force some doors to always open toward the opening character, even if that means the door swings through the character, because the doors in question have been moved out of their openings using the Adjust Location trick, and opening away from the character will usually mean the door swings away and passes through a wall or something.

I ask here, in the Scripting forum, because I'm hoping for a scripting solution, as I know exactly zero about changing the appearance of models or their animation behavior.

Any ideas?
               
               

               

                     Modifié par BCH, 14 février 2012 - 06:10 .
                     
                  

            

[Legacy_GhostOfGod]

               Yep. Just a simple matter of putting something like this in the doors OnOpen event:


void main()
{
    PlayAnimation(ANIMATION_DOOR_OPEN1);
}


There are 2 open animations. "ANIMATION_DOOR_OPEN1" and "ANIMATION_DOOR_OPEN2". Depending on the door, you might need to switch the animations.

Good luck.
               
               

               
            

[Legacy_BCH]

               Ah, thank you!  I got so hung up on ActionOpenDoor() and DoDoorAction() that I didn't even think to look at the animations themselves.

Now on to the second part of my question.  I've gotten the door in question to always open into the room by putting PlayAnimation in the door's OnOpen script (which also has a delayed close and relock script call).  However, when a character passes through the door in another area that leads to this door, the animation for this door still defaults to opening away from the character. 

This implies to me that the OnOpen event for this door is not firing, so I wrote the following script and put it on the OnOpen event of both doors.  However, I must be missing something, because the behavior has not changed.

void main()
{
    object oDoor = OBJECT_SELF;
    object oDest = GetTransitionTarget(oDoor);
    int nAnimation = GetLocalInt(oDoor, "BCH_DOOR_ANIMATION");

    // if an animation was specified, play it
    //  and check the destination door for a specified animation as well
    if (nAnimation == 1)
    {
        PlayAnimation(ANIMATION_DOOR_OPEN1);
        nAnimation = GetLocalInt(oDest, "BCH_DOOR_ANIMATION");
        if (nAnimation == 1) AssignCommand(oDest, ActionPlayAnimation(ANIMATION_DOOR_OPEN1) );
        if (nAnimation == 2) AssignCommand(oDest, ActionPlayAnimation(ANIMATION_DOOR_OPEN2) );
    }
    else if (nAnimation == 2)
    {
        PlayAnimation(ANIMATION_DOOR_OPEN2);
        nAnimation = GetLocalInt(oDest, "BCH_DOOR_ANIMATION");
        if (nAnimation == 1) AssignCommand(oDest, ActionPlayAnimation(ANIMATION_DOOR_OPEN1) );
        if (nAnimation == 2) AssignCommand(oDest, ActionPlayAnimation(ANIMATION_DOOR_OPEN2) );
    }
}

Any ideas?

(Sorry, my first time posting code here, not sure how to properly format it yet.)
               
               

               

                     Modifié par BCH, 14 février 2012 - 06:07 .
                     
                  

            

[Legacy_henesua]

               When a PC opens one door, I think the linked door receives some kind of signal, but from what I can tell it is not an OnOpen event so the OnOpen script does not execute on the linked door.

The best solution I have come up with is to also control the animation of the linked door from the first door's OnOpen event.

So if you are telling door 1 to play ANIMATION_DOOR_OPEN1  tell the linked door to play ANIMATION_DOOR_OPEN2 and vice versa.
               
               

               
            

[Legacy_wyldhunt1]

                There is no good way to post code here.
Although... that was one of the better examples of a destroyed code block. '>
I tend to paste my code in Pastebin and give a link to it in my post.
IE: http://pastebin.com/NEXL1aFt
               
               

               

                     Modifié par wyldhunt1, 14 février 2012 - 06:09 .
                     
                  

            

[Legacy_BCH]

               Thanks!  Actually, I screwed up and forgot to set up one of the doors variables properly.  That was causing the problem.

The code snippet above works perfectly!  And I think that's also exactly what Henesua is talking about.
               
               

               
            

[Legacy_BCH]

               

wyldhunt1 wrote...

 There is no good way to post code here.
Although... that was one of the better examples of a destroyed code block. '>
I tend to paste my code in Pastebin and give a link to it in my post.
IE: http://pastebin.com/NEXL1aFt

Of course, out of my 8 or 9 attempts to post that snippet, you probably saw the worst one, the one that displayed ten thousand non-breaking spaces. :innocent:
               
               

               
            

[Legacy_henesua]

               Yeah, I didn't bother to read through that code. It was too much trouble to parse, and I just guessed at what the problem was based on my own experience.

One issue I notice in your code now that I can read it. You are handling Waypoint destinations the same as door destinations. You might want to separate the two situations.
               
               

               
            

[Legacy_Rolo Kipp]

               <dropping...>

Or, if you have a door that absolutely, positively must *always* open in a single direction (*cough* Vault *cough*) you can go into Max and physically (in a virtual way) move the "DWK_dp_open1_*" and "DWK_dp_open2_*" nodes (and the DWK mesh, and related bits) so they both open the same way :-)

<...a couple coppers>
               
               

               

                     Modifié par Rolo Kipp, 14 février 2012 - 06:52 .
                     
                  

            

[Legacy_BCH]

               Henesua, what problems might my current method cause?  I assumed that treating transitions as if they were doors in this situation would not be a problem, because transitions would presumably never have the local variable BCH_DOOR_ANIMATION set on them.

If there is a problem lying in wait for me in this script, it would not be the first time I didn't see it.  Or, y'know, the hundredth time.

Rolo, thanks for the 2cp.  I haven't dived into the models or gone near the CCC yet because I already have more scripting work to do than I have time for, and there seems to be an effectively infinite amount of custom graphical content out there that I'd love to have.  The community is producing it faster than I could include it in my module! '>

But I have to say, that is a very cool-looking vault door.
               
               

               
            

[Legacy_henesua]

               I don't know what the issues would be, but it is my habit to try to control the application of my code. If my code will only work on a door, then I try to restrict its application to doors.

Granted, I do this because I tend to write bug ridden code anyway. And so this narrows down what i need to look for when i am debugging. But in this case, it may not cause any bugs.
               
               

               
            

[Legacy_BCH]

               Ah, got it.  Yeah, that sounds like a good general principle.  I thought you had seen some particular mistake in my near future, but I will definitely take your advice, thanks.