Get dummy object, and door animation stuff too

[Legacy_Leurnid]

               

    object oObject = OBJECT_SELF;
    string sDummy = (GetTag(oObject)+"_dummy");
    object oDummy = (GetObjectByTag (sDummy,1);

I am trying to get a (viewable but not reachable) dummy object to change the state/animation to match the object manipulated.

Dummy objects have tags matching the original object, with the suffix '_dummy'.

This does not seem to be working... I suspect the bit I cobbled (above) is where the error lies. 
               
               

               

                     Modifié par Leurnid, 23 avril 2012 - 10:53 .
                     
                  

            

[Legacy_Failed.Bard]

               

Leurnid wrote...

    object oObject = OBJECT_SELF;
    string sDummy = (GetTag(oObject)+"_dummy");
    object oDummy = (GetObjectByTag (sDummy,1);

I am trying to get a (viewable but not reachable) dummy object to change the state/animation to match the object manipulated.

Dummy objects have tags matching the original object, with the suffix '_dummy'.

This does not seem to be working... I suspect the bit I cobbled (above) is where the error lies. 

// Get the nNth object with the specified tag.
// - sTag
// - nNth: the nth object with this tag may be requested
// * Returns OBJECT_INVALID if the object cannot be found.
// Note: The module cannot be retrieved by GetObjectByTag(), use GetModule() instead.
object GetObjectByTag(string sTag, int nNth=0)

This line:

  object oDummy = (GetObjectByTag (sDummy,1);

gets the second object by that tag, not the first. 
               
               

               
            

[Legacy_Leurnid]

               doh! thanks
               
               

               
            

[Legacy_Leurnid]

               

void main()
{
    object oDoor = OBJECT_SELF;
    string sDummy = (GetTag(oDoor)+"_dummy");
    object oDummy = (GetObjectByTag (sDummy,0));


        PlayAnimation(ANIMATION_DOOR_OPEN1);
        AssignCommand(oDummy, ActionPlayAnimation(ANIMATION_DOOR_OPEN1) );

}

It's simple stuff, I know, but I am tickled pink about it.

I am using this for areas with balconies overlooking dummy foyers, and the foyers below looking up at the dummy balcony... so doors left open or close in one or the other keep the appropriate state when you transition between the two.

Pedantic?  

Why yes, yes it is.
               
               

               
            

[Legacy_henesua]

               No its not pedantic, but it is very cool.

I also had to control paired doors by script and was equally excited when I got it working.  I have a script that doesn't allow creatures without hands to open a door. The trouble I had was that the paired door in the other area would open. So I had to restrict the opening of both doors rather than just the one "used".

Damn script affects DMs too. I need to either change the script to treat DMs special, or change my DM avatar to one that has hands.
               
               

               

                     Modifié par henesua, 23 avril 2012 - 07:22 .
                     
                  

            

[Legacy_Leurnid]

               I have also noticed that because doors hang from the same side, unless you have a set of doors that have left and right hand versions, the only way to get your trans doors to line up correctly is to put one door in backward, which breaks door-to-door transitions (you appear in the dead space behind the door, and getting out sends you back to where you came from).  this can be solved with 2 door-to-waypoint transitions, but the door animations need to be scripted. I am experimenting with a hinky but one off solution for that.. I am using the same Tag for both doors:

void main()
{
    object oDoor = OBJECT_SELF;
    string sDupe = (GetTag(oDoor));
    object oDupe = (GetObjectByTag(sDupe,1));


        PlayAnimation(ANIMATION_DOOR_OPEN1);
        AssignCommand(oDupe, ActionPlayAnimation(ANIMATION_DOOR_OPEN1));

}

It works fine in my test so far, but both transition doors are in a common area.  I am going to break them up across areas and see if they still behave.

I know that isn't a 'good' solution (probably), but  I learn by breaking things.

I am learnin' baby!
               
               

               
            

[Legacy_Leurnid]

               If I go with 2 tags, I can make the backward door trans to the correct facing door, but the correct facing door will still need a WP.  If I do that, I can use the dummy door template to drive the door with the WP, and use get transition target on the dummy door going back, I think.  But I want to shake and bake the redundant tag version and see if it holds up across areas.
               
               

               
            

[Legacy_Leurnid]

               Ok, it works across areas just fine...

Somebody explain how this is bad. I am sure this can't be good, but I am not able to see why.
               
               

               
            

[Legacy_Leurnid]

               A nearly identical script for the on close, and on death, optionally...

The dummy script isn't even needed, the dupe scriipt works fine for non-transition doors.
               
               

               
            

[Legacy_Lightfoot8]

               

Leurnid wrote...

Ok, it works across areas just fine...

Somebody explain how this is bad. I am sure this can't be good, but I am not able to see why.

Sorry, No can do.   I see nothing wrong with it.
               
               

               
            

[Legacy_Leurnid]

               The entire thing is working incredibly well... glad to hear from a seasoned scripter that the solution isn't going to bite me.

I have set up On Open, On Close, and On Death scripts for both Dummy and Dupe solutions.

For area transitions with the Dummy scripts, I only need one way point, the dummy door should point to the original, the original to the wp at the dummy, for one of the transitions.

Area Transitions with the Dupe scripts require waypoints for both doors.

The Dupe arrangement has the benefit of symmetry, but the Dummy has one fewer WP to deal with. I have also included a timed door closer, but the Dummy arrangement for area-trans requires a small door closer file to be placed on the dummy.

I am thinking 'dummy' is a poor word choice: the dummy solution is better for area-trans, and the dupe solution is better for what the dummy door was originally for.
               
               

               
            

[Legacy_Leurnid]

               I think I found a problem with using the same tag for 2 doors you want to link behaviors for... If the doors get more than 6 or 7 tiles apart, they start to behave erratically, sometimes triggering themselves, sometimes triggering no other door at all.

edit: yep at between 7 and 8 tiles, the doors script ranges out and cannot find another door with the same tag, and starts to slam the door you are trying to open, closed.

So, the duplicate trick would work for nearby features, but it's bad if you are trying to manipulate doors over greater distances.

Luckily, the first solution, the dummy door trick, works fine across zones.  I am going to check it at that 8 tile range and see if it gets finicky too.
               
               

               

                     Modifié par Leurnid, 25 avril 2012 - 03:06 .