Author Topic: Seamless Area Transitions  (Read 446 times)

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Seamless Area Transitions
« on: March 09, 2013, 09:10:51 pm »


               I have rewritten the All-In-One Seamless Area Transitioner, and called it...

SEAMLESS AREA TRANSITIONS


Version 1.1 is availableRelated ThreadsI received a few requests to release my changes to Jaga's code, but the Copyright specifically restricted such sharing. On March 4th however I decided to rewrite it, and issue my changes under the GNU GPL so no one would be restricted from releasing their own improvements.

Although my code is a little messy in places, the script is much easier to read and configure than it was before.

Please let me know what you think of it, let me know about any bugs you encounter, and make suggestions for improvements.

Version 1 Features
  • Does everything that the All-In-One... did
  • Configured to be compatible out of the box with the original
  • Areas may be any size and shape, and may differ in size and shape relative to one another
  • Area Tags may contain more than just the area's coordinates, and thus more than one grid of areas (region) can exist in a module.
  • Grids can be configured as Cartesian or have the same orientation as the orginal by Jaga
  • Grid Nodes may be flexible (any size allowed and each node can be a different size) or inflexible (each grid node is a fixed size, but an area may contain one or more grid nodes, and thus adjacent areas may be different sizes).
  • Trigger can be an Area Transition Trigger (instead of a Generic Trigger), and the script can work with Transition Targets if they are specified for the trigger.

CHANGE LOG
v1.1
Changes to script area_trans:
  • SetLocalInt(oPC, "AREATRANS_DIRECTION_BACKUP", nDir)

    • new local integer used in diagonal transitions
    • if the diagonal direction fails, the nearest cardinal direction (N, S, E, or W) is used in its place to find a transition area
    • This local integer is set, used, and deleted within the script, so users need not be concerned with it.
  • int AREATRANS_SQUARES_PER_GRID_UNIT

    • new global used to correct math error in FindAreaContainingGridTag()
  • string GetDirectionName(int nDir)

    • new function to encapsulate code for generating name from direction integer

               
               

               


                     Modifié par henesua, 11 janvier 2014 - 03:29 .
                     
                  


            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Seamless Area Transitions
« Reply #1 on: March 10, 2013, 10:45:49 pm »


               ILLUSTRATIONS

I wanted to clarify for people looking at this system how it works. The changes I made are difficult to describe in words. So to better explain what I have done, I put together two illustrations. The first is remedial, but serves as background for understanding how areas are laid out in both Jaga's system as well as mine.

CARTESIAN PLANE
'Posted

      The grid is defined by X and Y axes which cross at the origin. The X axis runs east and west and the Y axis runs north and south. Numbers increase to the north (+y) and east (+x) and decrease to the south (-y) and west (-x). All areas linked together by Seamless Area Transitions sit on a grid. A module can have more than one grid, each defined by a string from 0 to 23 characters long.

Note: The grid used in Jaga's "All-In-One Seamless Area Transitioner" is not Cartesian. Jaga flipped the Y axis so that numbers increase toward the south. My "Seamless Area Transitions" accommodates for this by allowing the user to choose between Cartesian or non-Cartesian.

Definitions
  • A grid unit is the space between parallel lines on the grid.
  • A grid node is a location where lines cross on the grid.
  • A square on the grid is a space on the grid defined on all four sides by grid lines in which no lines cross.
  • Areas on the grid are rectangular or square with each corner touching a grid node. The coordinates of an area are defined by the grid node in its southwest corner. The last 9 characters in an area's tag identify its coordinates.
  • Regions are another name for a grid. A module may have more than one grid or region. The region that an area belongs to is defined by all the characters preceding the last 9 characters in its tag. The maximum length of a region's name is thus 23 characters.
  • Inflexible Grids are grids with a fixed number of meters for each grid unit. Once the user defines this, the dimensions of every square on the grid are known.
  • Flexible Grids are grids in which no real world dimensions define the grid units. One area fills each square, but each area is unrestricted in size or shape.


AN INFLEXIBLE, CARTESIAN GRID
'Posted

     The illustration above is an example of the possibilities one has when using an inflexible grid.
     This grid has Cartesian coordinates. The two bold, white lines crossing the grid are the X and Y axes. The faint white lines are shown to help you visualize the grid. The black text on the outside of the grid identifies the coordinates as used in an area's tag. Those across the bottom identify the X component of a coordinate, and those on the left, the Y component. For this example, assume that the Z component is p00 for all areas on the grid.
      Each contiguous field of color is an area. Any areas which touch one another, may be linked by a seamless area transition. Note that each area can be of a different size and shape from those adjacent to it. Four areas are labelled. These are A (which is a red, 1x4 area), B (yellow, 1x1), C (green, 4x1), and D (yellow, 3x3).
      For our example, let us assume that each grid unit is 80 meters (the length across 8 area tiles arranged in a row). Thus the two large blue areas measure 320x320 meters, the largest areas that can be created in NWN. This means that in our example 80 meters is the largest figure we can use for a grid unit. The smallest figure we can use is 20 meters because 20x20 meters is the smallest that we can make an area, and we can not fit more than one area within a square.
 
Example Area Coordinates
  • Area A - p00n03p00
  • Area B - p00p01p00
  • Area C - p01p01p00
  • Area D - p02p02p00

      As mentioned previously, the area coordinates comprise the last nine characters of the area's tag. Each grouping of three characters from left to right identifies the X, Y, or Z coordinates respectively. And the coordinates of an area define the area's origin on the grid - the southwest corner of the area. Since NWN uses Cartesian coordinates inside the areas, the southwest corner of an area is always considered its origin regardless of whether you configure Seamless Area Transitions to use Cartesian grids or Non-Cartesian grids like Jaga used.
      So p00n03p00 is X = "p00", Y = "n03", and Z = "p00". "p" stands for positive and "n" stands for negative. This is a convention carried over from Jaga's system so that modules using his script are compatible with Seamless Area Transitions.
 
      Lets say that a player character is in Area A near the northern edge. From our point of view looking at the diagram, we would say that the PC is standing in the square with grid node p00p00p00. If they travelled north, they would enter the square at p00p01p00, which is contained by Area B. Area B just so happens to also have the same coordinates. Likewise if the PC travelled northeast from p00p00p00 they would arrive in the square at p01p01p00 which lies in Area C, and also defines the coordinates of Area C. Once in Area C, the PC travels east for 180 meters, a little over half the area's length from west to east, then turns north. Their position now lies in the square at p03p01p00. If they travel north from this square they will arrive in p03p02p00, which is in the middle of the south side of Area D.


Any questions?
               
               

               


                     Modifié par henesua, 10 mars 2013 - 10:52 .
                     
                  


            

Legacy_Aikidoka23

  • Newbie
  • *
  • Posts: 47
  • Karma: +0/-0
Seamless Area Transitions
« Reply #2 on: March 11, 2013, 04:17:55 pm »


               MMMm going to have to get my head around this. There is an issue with my module if people want to add new regions. I think basically each new region will require a new grid... Can't go into it now, but will absorb this '<img'> Thanks
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Seamless Area Transitions
« Reply #3 on: March 11, 2013, 04:26:29 pm »


               I intend to develop a means to tie regions together (perhaps by borrowing from Rolo Kipp's work), but this should work for you as is now.

By the way, I discovered a math bug this morning, and some things I can improve. I'll get to making these changes available ASAP.
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Seamless Area Transitions
« Reply #4 on: March 12, 2013, 02:18:41 pm »


               Version 1.1 is now available.

I addressed a math bug which made complex areas problematic, and improved area finding when attempting to transition in a diagonal direction.

Previously if exiting from a corner, a diagonal direction (NE, NW, SW, SE) would be tried and if it failed, then the transition stopped. Now it tries a fallback direction. If the PC is in a corner, first it tries a diagonal direction, then it tries the next most likely cardinal direction based on which edge the PC is closer to.
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Seamless Area Transitions
« Reply #5 on: March 22, 2013, 04:38:19 pm »


               If anyone is using this and has feedback as to how I can improve it, or even why you think it sucks etc... I would very much like to hear it.