Author Topic: Tileset area size  (Read 548 times)

Legacy_ZugothNDeadly

  • Full Member
  • ***
  • Posts: 174
  • Karma: +0/-0
Tileset area size
« on: October 29, 2015, 10:39:01 am »


               

Is it ever possible to surpass the area size? The maximum size is 32x32.



               
               

               
            

Legacy_Tarot Redhand

  • Hero Member
  • *****
  • Posts: 4165
  • Karma: +0/-0
Tileset area size
« Reply #1 on: October 29, 2015, 10:47:07 am »


               

Just curious as to why you would want to. 32x32 would seem to be huge and already has load time implications.


 


TR



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Tileset area size
« Reply #2 on: October 29, 2015, 12:58:37 pm »


               

I don't think that number is hardcoded. Area size is simply determined by two entries in the ARE file. You can adjust them to make long tunnels.


 


I've never hit a cap so far. Instead, think about the complexity of the tileset models, and then figure what is a good fit for your users. As TR said, 32x32 can cause some load time delay, but that depends on the tileset. Crypt takes a lot longer to load up on 32x32 than does OC Rural. On my machine, my new granitelands tileset with no placeables or on-tile vegetation takes LESS time to load a 32x32 map than does the crypt.


 


Also think about pathing. If you have a large area with a great number of tiles blocking the path from one point to another, in a way which forces more tiles into the pathing mix, then your pathing detection times will be substantially longer. As an example, if I set one third of my granitelands tileset walk faces to type 7, disallowing movement, the pathfinding time will be substantially higher, even with proper pathnode setup on each tile.


 


There are a few other things to think about with tilesets and areas. The first is the distance at which your on-tile grass and in-area fog are set to fall off. You can set your fog fall off in the module, but grass falloff is calculated from a value in your nwn.ini file. I think by default grass fall off is set to 20 meters, which is horrible looking. Setting it to 100 meters causes substantial lag. Area fog is also set to about 5 tiles distant (45m is what the toolset defaults to I think). Setting fog closer reduces the fog drawing calculations, and may also change the distance at which placeables disappear. This all adds up to additional mesh needing to be drawn when you set higher values.


 


I think ultimately the question is what are the limitations of your machine and that of your players? And also, what can you accomplish with a very large area which you cannot with multiple smaller ones?



               
               

               
            

Legacy_kamal_

  • Sr. Member
  • ****
  • Posts: 347
  • Karma: +0/-0
Tileset area size
« Reply #3 on: October 29, 2015, 02:08:29 pm »


               

I don't think that number is hardcoded. Area size is simply determined by two entries in the ARE file. You can adjust them to make long tunnels.

 

I've never hit a cap so far.



I plan on investigating whether this is also true in nwn2 right away. Thank you for the insight/info.


 


edit: the nwn2 toolset will force you into a valid area size. Bummer.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Tileset area size
« Reply #4 on: October 29, 2015, 04:09:14 pm »


               

Doable, requires manual edit of the area files via GFF editor. I used this to make 1x1 area, but should be possible to make 30x30 area, but much difficult to do thats for sure.



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Tileset area size
« Reply #5 on: October 29, 2015, 05:20:45 pm »


               

If you open the area file with a GFF editor, you'll see a width and height entry. You can then change those numbers to suit your needs. But that is not all. You then need to fix the tile list. If 16x16 is 256, then you need tiles for 0 to 255. So calculate your last tile name by (width*height)-1.


 


If you are subtracting tiles to make your number, this should be easy, as you can just delete the branches you don't need. If you are adding tiles, you need a GFF editor which allows you to clone branches.


 


It may be possible to cheat the toolset, but I have not yet tried this. What I mean is you might be able to just add the tile entry branch, and then set just the tile_id node to 0, omitting the rest. The toolset makes up for many parts of missing data by adding them when you change something. This might be one of those times.


 


I'm using GFF editor 1.3.4.7 and it has a copy/paste node/tree function in the Edit menu. You can also right click to delete node/tree. It should have everything you need. When you copy a node and paste it to the tile_list tree, it will put it on the bottom of the list, and give it a strange number. I copied 186 as a test and pasted it. The number was then 001, not 186 or 256 as expected, so be careful.


 


If I could, I'd make a suggestion to whoever takes the time to make odd shaped areas outside the 32 limit of the tileset, and that is to pack up an ARE file for each of your odd sizes and put it on the vault. That way a user can just go in the ARE file and change the tileset used. I'd suggest setting every tile to tile_id=0, assuming every tileset will start with either a ground terrain, or blocking terrain, open tile.