Migraine Door Challenge!

[Legacy_WhiZard]

               

Lightfoot8 wrote...
1%6 is 0 and 7%6 is 1.  The operation returns an integer.  
Edit:  sorry long day.  

Well, looks like all of us have committed noob like errors today.
               
               

               
            

[Legacy_WhiZard]

               

Lightfoot8 wrote...
2  Is this for multi-player or single player?  If it is single player, You could do it all with just two areas. if all the areas look alike.

Quite right, I was thinking along the lines of different looking faces, perhaps multiple in the same area, and extending the possibility to faces with different number of sides.
               
               

               
            

[Legacy_WhiZard]

               

Leurnid wrote...
It seems that you will need to modify the node associated with the door, as well as modify the rotated door associated with the node, so that coming back from the other side, you land in the right place, not just land in the right place on the outbound trip. Then of course, a script will need to stitch the door to the node (and on to the door), or maybe that can all be handled by just having a generic call from the door, and let the node management script handle it all?!  

So long as the door nodes work properly initially, the changing of doors should have no effect on the side you enter one and exit the other through.
               
               

               
            

[Legacy_Lightfoot8]

               I was thinking of keeping it more simplistic with it always being a cube grid with 4 doors always.    

It makes it simple to just lay the areas out in rows of your cube size.  Where the first row would be areas numbered 0 to nCube size-1. Second row wound be areas  nCubeSize to  2*nCubeSize -1..  
and the last row being (nCubeSize-1) * nCubeSize to (nCubeSize* nCubeSize) -1;
Where nCubeSize is the number of areas along one side of the cube.


 So basicly if you are in area number x of the cube.  You are in row x/nCubesize and collumn x%nCubeSize.  

Sorry if that is basicly what you have above, and I am sure it is, I just have not read through it all yet.
               
               

               
            

[Legacy_WhiZard]

               

Lightfoot8 wrote...

I was thinking of keeping it more simplistic with it always being a cube grid with 4 doors always.    

It makes it simple to just lay the areas out in rows of your cube size.  Where the first row would be areas numbered 0 to nCube size-1. Second row wound be areas  nCubeSize to  2*nCubeSize -1..  
and the last row being (nCubeSize-1) * nCubeSize to (nCubeSize* nCubeSize) -1;
Where nCubeSize is the number of areas along one side of the cube.


 So basicly if you are in area number x of the cube.  You are in row x/nCubesize and collumn x%nCubeSize.  

Sorry if that is basicly what you have above, and I am sure it is, I just have not read through it all yet.

I understand what you are doing, and we are tackling the problem differently.  It would be up to the OP to find out whether he/she wishes to use areas/faces which are all similar and then script the differences, or if he/she wants to use fundamentally different layouts for one face to the next.  The way I have mine working all faces would be distinct and thus remembered distinctly (including map exploration, map pins, creatures remaining and all the rest).  What you propose will use a lot less resources but will have limitations with regard to textures and tiles.

Both are quite feasible directions, and I doubt the OP will try an icosahedron or any other weird shape, though my script can handle these because I am trying to do it broadly.

One thing your solution does handle that mine does not is having mulitple doors along the side of a single face (though you are accomplishing this through each face being composed of multiple areas, (though technically only two areas are there)).   I could add this functionality, but am not sure, given the circumstance that it is needed, how the OP would want to have the multiplicity of doors per side handled.
               
               

               
            

[Legacy_Leurnid]

               took a nap, got some fresh coffee...

The idea is for each face to be a unique area, with traps, monsters, and puzzles (traditional PnP dungeon crawl). Ideally, some areas of said dungeon would be inaccessible unless/until certain faces are aligned correctly. I have seen a number of PnP dungeons over the years that feature tesseract puzzles, usually as the safeguard or access method to the final boss or big ticket item of the crawl. I prefer making the entire crawl the tesseract, and present it as the macro-puzzle that must be solved for the big pay-off.

With that said:

• The solution will need to handle more than 1 door per side.  The number *must* be consistent within the module, but ideally, the script would allow that number to be defined, and not hardcoded.
• This sould support multiplayer, but a unique key should be reqquired to use the switches and perimeter doors.
• Doors will close and lock shortly after opening, and will be forced closed when the switches are accessed.

WhiZard's solution so far as I grasp it, will work for more doors, as all you need to do is increment the number of spaces the door nodes 'swap' places by defining a 'number of doors per face' in the switch's script.

The other reqs are easily handled with cut'n'paste from the vault.

I have a little demo-mod (using one area to save time) with six isolated square areas, each with 4 doors. Currentlly, they are assigned transitions between the doors, so it acts as a 'fixed' tesseract. My efforts at figuring this scripting issue out so far have been limited by my ignorance. As I said previously, I know exactly how I would code the swaps and array the nodes in BASIC, but this isn't a C=64.


Vaguely related bonus tale:
I DM'ed a local tournament dungeon one year that had as a penultimate challenge a 'maze' of 20 identical triangular rooms, with murals and statuary in each that would subtly indicate the number of the room. About 6 rooms in, most teams caught on.  Every group discovered while trying to meta-game the maze with their d20's, that there are 3 common and many not so common number arrangements for d20's, and the module didn't use any of those.
               
               

               
            

[Legacy_WhiZard]

               

Leurnid wrote...
WhiZard's solution so far as I grasp it, will work for more doors, as all you need to do is increment the number of spaces the door nodes 'swap' places by defining a 'number of doors per face' in the switch's script.

Quite true.  Multiply both nSidesPerFace and nShift by nDoorsPerSide, and you get it working when the sides have multiple doors.  I was fearing you might go a little more complex and actually ask for a system where the sides would expand and door entrances would increase as the PW grew.

While I was working at this script, I was also having fun drawing a Klein's Bottle model  where the 2D surface, though continuous in all directions, could not be mapped in 3-space.  For fun I even added a rotating feature about the "center" of the weird shape.
               
               

               

                     Modifié par WhiZard, 14 avril 2012 - 03:34 .
                     
                  

            

[Legacy_Leurnid]

               I am not a big fan of personal public displays of ignorance, but I am doing so well, I thought I would double down:
This appears to be scripted to a testable state, if so, what gets attached to what? Spell it out like I am a 5 year old for bonus points.
I am still perplexed at how/where the node-door action is getting handled, but I have found the scripts I ook at often seem to be missing critical bits but work perfectly.
               
               

               
            

[Legacy_WhiZard]

               

Leurnid wrote...

I am not a big fan of personal public displays of ignorance, but I am doing so well, I thought I would double down:
This appears to be scripted to a testable state, if so, what gets attached to what? Spell it out like I am a 5 year old for bonus points.
I am still perplexed at how/where the node-door action is getting handled, but I have found the scripts I ook at often seem to be missing critical bits but work perfectly.

Doors have their direction set when placed in the Toolkit.  The arrow points in the direction that creatures going into the area will be placed.  What happens when you click on the area transition and your character approaches it is governed by the OnAreaTransitionClick event.  The default script for this is at_corridore_001.  You will be copying this script into a new blank script changing only the line:

object oTarget = GetTransitionTarget();

The rotating doors will instead use the object I defined by the first declaration:

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

You can either make this declaration above void main() and then write in the replacement

object oTarget = GetTargetForTransition()

Or you could just integrate the single line

object oTarget = GetObjectByTag(GetLocalString(GetModule(), GetTag(OBJECT_SELF)));

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).
               
               

               
            

[Legacy_Lightfoot8]

               

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 
               
               

               

                     Modifié par Lightfoot8, 14 avril 2012 - 11:07 .
                     
                  

            

[Legacy_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.
               
               

               
            

[Legacy_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.     
               
               

               
            

[Legacy_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 .
                     
                  

            

[Legacy_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 .
                     
                  

            

[Legacy_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.