36 réponses à ce sujet

[WhiZard]

Lightfoot8 wrote...

WhiZard wrote...

  The default script for this is at_corridore_001. 

Hmm,  I have never heard of that script.  In Fact it is not even in the vanilla x3 scripts.   

the Default door transistion script is x3_g0_transition.nss
Before the x3 expansion it was: nw_g0_transition.nss 

It is an x3 overwriting of an older script.  Doors by default when linked through the Toolset will be using it.  If you click the edit button you will be directed to this script.

The main difference between x3_g0_transition.nss and at_corridore_001 is that the latter does not dismount henchman.  x3_g0_transition is also more heavily commented.

[Lightfoot8]

WhiZard wrote...

Lightfoot8 wrote...

WhiZard wrote...

  The default script for this is at_corridore_001. 

Hmm,  I have never heard of that script.  In Fact it is not even in the vanilla x3 scripts.   

the Default door transistion script is x3_g0_transition.nss
Before the x3 expansion it was: nw_g0_transition.nss 

It is an x3 overwriting of an older script.  Doors by default when linked through the Toolset will be using it.  If you click the edit button you will be directed to this script.

The main difference between x3_g0_transition.nss and at_corridore_001 is that the latter does not dismount henchman.  x3_g0_transition is also more heavily commented.

Sorry whiz, 
at_corridore_001 does not exsist in the bif's in vanilla nwn.  you have either edited the Bif's with a mass leto edit of the doors or something else if your game is acting that way.     If you edit the OnAreaTransistionClick on a door with no script, you simply get a script names 'untilted###'  where ### is the current number for use.   If you have not done bif edits im guessing that you have a hak that is overriding the standard doors.     

[WhiZard]

Lightfoot8 wrote...
Sorry whiz, 
at_corridore_001 does not exsist in the bif's in vanilla nwn.  you have either edited the Bif's with a mass leto edit of the doors or something else if your game is acting that way.     If you edit the OnAreaTransistionClick on a door with no script, you simply get a script names 'untilted###'  where ### is the current number for use.   If you have not done bif edits im guessing that you have a hak that is overriding the standard doors.     

Found out what is going on.  When you select "Set Up Area Transition" button under the area transition tab the system will create a script with the name "at_" + the first 9 characters of the tag + "_" + a three digit number beginning with 001.  Thus if you did it for CorridorExit, you would get "at_corridore_001".  The script used by the Toolset is slightly different than x3_g0_transition in the above mentioned way.

Modifié par WhiZard, 15 avril 2012 - 01:03 .

[Lightfoot8]

Yes I came up with the same conclusion after doing some more testing. I also do not know where the templet for the script created by the toolset is comming from. I do not see any standard scripts that matches it. ( using lilac script search tool).

I also did a test to figure out what script is the default script. ( the script being used if there is no script name in the Event) The default script is nw_g0_transition.nss, Even with the 1.69 patch installed.

For the record, I have to half eat my words, with the fact that the toolset will create a script by that name for use. if the door has the correct tag and a transistion has been set up via the wizard.

Modifié par Lightfoot8, 15 avril 2012 - 01:16 .

[WhiZard]

More information, I looked through a few tilesets, and in some for door linking the associated script included the Henchmen dismounting and in some it didn't. Nevertheless, all full line comments in x3_g0_transition were omitted. This may mean that the script is pieced together based on tileset properties (like interior area) or the nature of the two doors linked.

[Leurnid]

Bear in mind, I am a scripting rube...

WhiZard wrote...
...
For the doors to use this object correctly, you will need to set the local variables in the module for the doors.

A simple way to accomplish this is to have the door that is linked in the "Destination Tag" field, and then have an opening script cycle through all doors on each face getting the door they are linked to (by GetTransitionTarget()) and setting the module variable using the GetTag() function to get the variable name and its value).

So uh, that hit my brain and splattered jello all over the inside of my head.

Test set up: 

• 1 area divided into 6 rooms. *
• Each room has 4 doors total, one per side.
• Each room has one switch placeable.
• Each door, currently, has the transitions set to the 'neutral' postions of the cube, and has your 'door script' in OnAreaTransitionClick.
• Each switch has the 'switch script' you wrote in OnUse.

* Will it impact the operation of this if the 'rooms' being rotated are all in one area?  Keeping it all in a single area is not a hard requirement, and was done for expediency. If I read that script correctly, I think it will be an issue...

Action Requested:
"have an opening script cycle through all doors on each face getting the
door they are linked to (by GetTransitionTarget()) and setting the
module variable using the GetTag() function to get the variable name and
its value)" ...as simple as that probably is, it perplexes me.

[WhiZard]

Leurnid wrote...

Bear in mind, I am a scripting rube...

WhiZard wrote...
...
For the doors to use this object correctly, you will need to set the local variables in the module for the doors.

A simple way to accomplish this is to have the door that is linked in the "Destination Tag" field, and then have an opening script cycle through all doors on each face getting the door they are linked to (by GetTransitionTarget()) and setting the module variable using the GetTag() function to get the variable name and its value).

• Each switch has the 'switch script' you wrote in OnUse.

* Will it impact the operation of this if the 'rooms' being rotated are all in one area?  Keeping it all in a single area is not a hard requirement, and was done for expediency. If I read that script correctly, I think it will be an issue...

Action Requested:
"have an opening script cycle through all doors on each face getting the
door they are linked to (by GetTransitionTarget()) and setting the
module variable using the GetTag() function to get the variable name and
its value)" ...as simple as that probably is, it perplexes me.[/list]

I have put all the variables on the module so it doesn't matter how many or few areas are used for each face.  Just have the doors on the sides of the face (in clock-wise or counter-clockwise numbering) have the object set to the module variable determination I had indicated above.   The rest of the doors (the ones inside each face) do not need rotating even if they connect to a different area.   The opening script would likely need to be run from the module (though you may have to wait for the doors to enter their respective areas).  Since GetObjectByTag() doesn't care about areas there is no issue with how many areas are used in a face.

Modifié par WhiZard, 15 avril 2012 - 10:53 .

[Leurnid]

I could not find any script prefixed 'at_' for the door transition click script, so I tried using 'x3_g0_transition.nss', as you indicated it was the same except for comments and possibly Henchman dismount issues.
The specific line you indicated to replace:

object oTarget = GetTransitionTarget();

does not exist, but a similar:

object oTarget=GetTransitionTarget(OBJECT_SELF);

does.

I replaced that line with:

object GetTargetForTransition()
{
return GetObjectByTag(GetLocalString(GetModule(), GetTag(OBJECT_SELF)));
}

attempting to save and compile that give an error on that line:

4/15/2012 6:40:20 PM: Error. 'wiz_trans' did not compile.
wiz_trans.nss(28): ERROR: PARSING VARIABLE LIST

Also, I am still totally confused by this:

For the doors to use this object correctly, you will need to set the local variables in the module for the doors.

A simple way to accomplish this is to have the door that is linked in the "Destination Tag" field, and then have an opening script cycle through all doors on each face getting the door they are linked to (by GetTransitionTarget()) and setting the module variable using the GetTag() function to get the variable name and its value).

If you could elaborate on that, it would really help.

[WhiZard]

Leurnid wrote...

object oTarget=GetTransitionTarget(OBJECT_SELF);

Any calling of the object GetTransitionTarget(), (the above one referenced is the only one existing in that script) will need to be replaced for the doors that are rotating.

I replaced that line with:

object GetTargetForTransition()
{
return GetObjectByTag(GetLocalString(GetModule(), GetTag(OBJECT_SELF)));
}

Those two lines represent the declaring of a function that returns an object.  Typically this function is put above void main() and then within void main() all you have to do to execute the function is use the call it by the name it was declared, GetTargetForTransition().

Example:

void main()
{
object oTarget = GetTranistionTarget(OBJECT_SELF);
}

gets replaced with

object GetTargetForTransition()
{
return GetObjectByTag(GetLocalString(GetModule(), GetTag(OBJECT_SELF)));
}

void main()
{
object oTarget =GetTargetForTransition();
}

[Leurnid]

is GetTargetForTransition a function you are creating?

Googling it only returns this thread, I assume that it isn't defined anyplace is why the compiler keeps failing.

I see what you did there!  Ok, we need to define it on the door script too!  It is being defined in the switch script, but that isn't helping to compile the door script... I think

edit: Success!

Ok, now, what variables do I need to create on the module...


*thinks he sees the light at the end of the tunnel, but it might be a train*

Modifié par Leurnid, 16 avril 2012 - 03:53 .

[WhiZard]

Leurnid wrote...
Ok, now, what variables do I need to create on the module...

Here is a sample of how to do it.

void SetFace(string sFacePrefix, int nSidesPerFace, int nDoorsPerSide)
{
SetLocalInt(GetModule(), sFacePrefix, nSidesPerFace);
SetLocalInt(GetModule(), sFacePrefix + "door", nDoorsPerSide);
int n = nSidesPerFace * nDoorsPerSide +1;
string sTag, sTag2;
while(--n)
  {
  sTag = sFacePrefix + "_" + IntToString(n);
  sTag2 = GetTag(GetTransitionTarget(GetObjectByTag(sTag)));
  SetLocalString(GetModule(), sTag, sTag2);
  }
}

void main()
{
SetFace("RubixA", 4, 2);
SetFace("RubixB", 4, 2);
SetFace("RubixC", 4, 2);
SetFace("RubixD", 4, 2);
SetFace("RubixE", 4, 2);
SetFace("RubixF", 4, 2);
}

I have also added a few lines to the switch function to account for doors per side.

void RotateFaces(string sFacePrefix, int nShift = 1)
{
int nSidesOnFace = GetLocalInt(GetModule(), sFacePrefix);
int nDoorsOnSide = GetLocalInt(GetModule(), sFacePrefix + "door");
nShift *= nDoorsOnSide;
nSidesOnFace *= nDoorsOnSide;
int n = nSidesOnFace + 1;
int nSide = 1;
int nPosition;
string sSide1;
string sSide2;
while(--n)
  {
  sSide1 = sFacePrefix + "_" + IntToString(n);
  nPosition = 1 + FindSubString(sSide1, "_");
  nSide = StringToInt(GetSubString(sSide1, nPosition, GetStringLength(sSide1) - nPosition));
  nSide = ((nSide + nShift - 1) % nSidesOnFace) + 1;
  sSide2 = GetLocalString(GetModule(), GetStringLeft(sSide1, nPosition) + IntToString(nSide));
  SetLocalString(GetModule(), sSide2, sSide1);
  SetLocalString(GetModule(), sSide1 + "#Temp", sSide2);
  }
while(++n <= nSidesOnFace)
  {
  sSide1 = sFacePrefix + "_" + IntToString(n);
  SetLocalString(GetModule(), sSide1, GetLocalString(GetModule(), sSide1 + "#Temp"));
  DeleteLocalString(GetModule(), sSide1 + "#Temp");
  }
}

[Leurnid]

Thank you so much for your time and effort. You deserve a medal for services above and beyond. I was honestly expecting a pat on the head or a kick in the butt when I started this thread.

I will plug this into my module and see how badly I screw it up this time =D

Funny you should use 'rubix' in there... Obviously, this is leading up to such a challenge, but a true rubix has the issue of overlapping domains controlled by switches, and needs a much more elaborate system. You need swaps for the 'perimeter' transitions, but you also need to rotate 'ownership' for the transitions that don't change but are on the cubelets being rotated... I have 6 pages of hand-written documentation on how to manage the swaps and ownership, and know how I would code it in BASIC, but not a clue for NWN.