Ok, I have created the first of 3 or so tutorials on this subject. This first tutorial is how to create a working .set file, with a single flat terrain tile. Creating A single flat tile.
The next tutorial will be a short, simple, tutorial on how to apply a texture to that ground plane. I should have that finished by the end of the day today.
Finally, the 3rd tutorial will be about how you create a 2nd terrain, and the basic tiles needed to get the two terrains to work in game. But that may take me a bit of time to create, so please be patient.
How to create a simple Tileset Terrain with nwMAX?
Débuté par
Raven_Xantrice
, sept. 21 2011 02:51
Retour en haut
#27
Posté 25 septembre 2011 - 12:15
Raven_Xantrice
-
- Members
- 96 messages
He thats cool Bannor Bloodfist! I will read this now! 
#28
Posté 25 septembre 2011 - 12:43
s e n
-
- Members
- 408 messages
henesua wrote...
Estelindis wrote...
One would just area-transition between two different versions of the area whenever one wanted to go from lower city to upper city.
Is there a tool that enables you to duplicate an area, but change the tileset?
i think you can safely do this with tileset duplicator, once you extracted the area file from the module
#29
Posté 25 septembre 2011 - 01:00
Bannor Bloodfist
-
- Members
- 935 messages
The tileset duplicator will do just that, duplicate and rename the TILESET, it will not touch any .GFF files, nor allow you to edit/change the .ARE etc. It also won't change woks etc. All that that has to be accomplished with some other utils.
Having a renamed set will not work in replacing a tileset in an area, you can't just switch it that way. Too many details are stored in the .ARE file that contain the specific tile name, it's location in the area by row/column etc, and that specific tile's rotation.
Those changes CAN be made using the NwNEditor I mentioned. By following the steps I mentioned. Tileset Duplicator can NOT help with editing the .ARE but it MIGHT affect the converted .XML format of the .ARE. First, you have to have a file that the duplicator can read.
Just double checked the tileset duplicator, the only file types it handles are these: SET;WOK;2DA;INI;MDL;ITP;DWK
Having a renamed set will not work in replacing a tileset in an area, you can't just switch it that way. Too many details are stored in the .ARE file that contain the specific tile name, it's location in the area by row/column etc, and that specific tile's rotation.
Those changes CAN be made using the NwNEditor I mentioned. By following the steps I mentioned. Tileset Duplicator can NOT help with editing the .ARE but it MIGHT affect the converted .XML format of the .ARE. First, you have to have a file that the duplicator can read.
Just double checked the tileset duplicator, the only file types it handles are these: SET;WOK;2DA;INI;MDL;ITP;DWK
Modifié par Bannor Bloodfist, 25 septembre 2011 - 01:04 .
#30
Posté 25 septembre 2011 - 01:04
Raven_Xantrice
-
- Members
- 96 messages
WOW! Awesome tutorial Bannor Bloodfist! TSC don't run... don't know why but I can use SET-Editor instead! Thank you very much for the time you have spend in this!
#31
Posté 25 septembre 2011 - 01:07
Bannor Bloodfist
-
- Members
- 935 messages
Raven_Xantrice wrote...
WOW! Awesome tutorial Bannor Bloodfist! TSC don't run... don't know why but I can use SET-Editor instead! Thank you very much for the time you have spend in this!
Are you using Gmax or 3damax?
TSC has very limited functions with Gmax. Likely the latest version doesn't even load correctly. But for 3dsmax, it works just fine.
#32
Posté 25 septembre 2011 - 01:19
Raven_Xantrice
-
- Members
- 96 messages
I use 3dsmax 8. Have this is more scripts (NWmax and VelTools worked) there comes no window and if I run the script nothing happens, same if I use the utility tab (the script is not to find"?") That confused but don't know really what the pros of TSC in view to setedit is. Okay, its near... and directly, is it faster to use?
#33
Posté 25 septembre 2011 - 01:34
Bannor Bloodfist
-
- Members
- 935 messages
Copy this into a new file named nwn_tsc_startup.ms and place that file in your 3dsmax scripts\\startup folder.
As to differences between the two programs, there are several, and I actually have to end up using both for different things.
Jlen's seteditor does NOT support 1.67->1.69 tilesets or .set files correctly.
It does not recognize the new pathnodes added in 1.67 and it does something funny with some other settings, like if you have custom grass texture to replace the default growing grass that bioware uses. There are some other bugs too.
the TSC by Velmar, doesn't not allow you to create groups in the .set file, but it does recognize the updates information needed by the 1.67->1.69 tilesets, new grass, new pathnodes etc. It does NOT handle files like searching for unused/missing or searching/replacing textures, while Jlen's does.
So, I end up using both. And Notepad too at times.
My main advantage to using TSC is that it runs within max, which is where I create the tiles, it allows me to add new tiles easily, to delete tiles from a set (one at a time) and adjust the pathnodes, visibility nodes, it will show the full .set in a list format where you can pick and choose what tile to load into the max editing window etc.
So, there are reasons to use both, depending on what you are attempting to accomplish. Since most of my time is spent inside of 3dsmax, using the TSC is sort of second nature for me, unless I need to accomplish something that the TSC can't handle.
From what I have seen, or been able to attempt to accomplish, the TSC will NOT allow you to add new terrain definitions, nor crosser definitions, which I think can be done inside Jlen's, but when you edit with Jlens, you lose the 167->1.69 pathnodes, and it will actually corrupt them. IE, Jlen's does NOT recognize the difference between upper and lower case pathnodes, and converts all to be the upper case.= when it writes out the file.
global autostart=true
filein "nwn-set/set-manager.ms"
-- globally define tileset-objects
global Door
global Tile
global TileDummy
global TileGroup
global Terrainlist
--load nwn tileset helper files
global outstream
global exportstart = 0
global NWN_exportfile
global NWNterrains =#()
global NWNcrossers =#()
global PN_items = #("A","B","C","D","E","F","G","H","I","J","K","L","M",
"N","O","P", "Q","R","S","T","U","V","W","X","Y","Z",
"a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","z")
-- functions
global existFile
global GetNameByPosition
global NWN_ReadList
global loadTerrainNames
global loadCrosserNames
global loadPathnodeImage
global compareByX
global compareByY
global sortGroupByPosition
global roundpos
global group_gridalign
global crosser_return
global opt_return
global relative_pos
global export_tile
global export_Group
global ExportTileset_Start
global ExportTileset_groups
loadfrom = (getDir #scripts ) + "\\\\nwn-set\\\\objects\\\\nwn_set.ms"
filein loadfrom
loadfrom = (getDir #scripts ) + "\\\\nwn-set\\\\objects\\\\tilehelper.ms"
filein loadfrom
loadfrom = getDir #scripts + "\\\\nwn-set\\\\objects\\\\grouphelper.ms"
filein loadfrom
loadfrom = getDir #scripts + "\\\\nwn-set\\\\objects\\\\doorhelper.ms"
filein loadfrom
loadfrom = getDir #scripts + "\\\\nwn-set\\\\objects\\\\tiledummy.ms"
filein loadfrom
loadfrom = getDir #scripts + "\\\\nwn-set\\\\objects\\\\terrainlist.ms"
filein loadfrom
As to differences between the two programs, there are several, and I actually have to end up using both for different things.
Jlen's seteditor does NOT support 1.67->1.69 tilesets or .set files correctly.
It does not recognize the new pathnodes added in 1.67 and it does something funny with some other settings, like if you have custom grass texture to replace the default growing grass that bioware uses. There are some other bugs too.
the TSC by Velmar, doesn't not allow you to create groups in the .set file, but it does recognize the updates information needed by the 1.67->1.69 tilesets, new grass, new pathnodes etc. It does NOT handle files like searching for unused/missing or searching/replacing textures, while Jlen's does.
So, I end up using both. And Notepad too at times.
My main advantage to using TSC is that it runs within max, which is where I create the tiles, it allows me to add new tiles easily, to delete tiles from a set (one at a time) and adjust the pathnodes, visibility nodes, it will show the full .set in a list format where you can pick and choose what tile to load into the max editing window etc.
So, there are reasons to use both, depending on what you are attempting to accomplish. Since most of my time is spent inside of 3dsmax, using the TSC is sort of second nature for me, unless I need to accomplish something that the TSC can't handle.
From what I have seen, or been able to attempt to accomplish, the TSC will NOT allow you to add new terrain definitions, nor crosser definitions, which I think can be done inside Jlen's, but when you edit with Jlens, you lose the 167->1.69 pathnodes, and it will actually corrupt them. IE, Jlen's does NOT recognize the difference between upper and lower case pathnodes, and converts all to be the upper case.= when it writes out the file.
#34
Posté 25 septembre 2011 - 02:03
Raven_Xantrice
-
- Members
- 96 messages
Oh okay, that I don't know!^^ But this don't work for me. I don't see the script, can run with "Run Script" but nothing happens.... very strange oO'
#35
Posté 25 septembre 2011 - 06:41
s e n
-
- Members
- 408 messages
tileset duplicator allows to substitute strings of letters contained in files and inside the files, for every kind of file, so it is possible to safely use it to rename a tileset prefix: if you have abc01, and you clone the tileset to abc02, you can use the duplicator to rename every instance of abc01 contained in the are file to abc02, and youre done
Modifié par s e n, 25 septembre 2011 - 06:41 .
#36
Posté 25 septembre 2011 - 07:04
Bannor Bloodfist
-
- Members
- 935 messages
Have you tried this Sen? I did absolutely nothing for me with the are file.
[Edit:} Actualy, it appears that the .are only stores the tileset name as in ttr01 in one location, the rest of the data in the .ARE file is tile numbers.
So, edit the .are file, change the name of the Area to a new name, and change the tileset reference to the new prefix, IE tctr05 or whatever it happens to be and it should work, provided the new tileset is now in the hak resources of the mod, or the override folder where it can be found.
It will work, provided the tileset is an exact duplicate. (with the renamed tiles, which tileset duplicator can handle just fine).
All of this depends on the individual tileset, and the naming conventions used in that set.
Many tilesets have tiles from other sets referenced in them too, as in addons to expand a given tileset. Which is what about 90% of tileset related stuff on the vault is... an expansion in some fashion of a bioware set.
The tileset duplicator is set to handle one translation/rename at a time. For several sets on the vault, you will have to run it more than once and adjust the tileset prefix name each time.
In otherwords, you may be able to accomplish this with tileset duplicator, provided you have a good understanding of the particular tileset you are working with. Add the .ARE extension to the filetypes that the duilicator touches etc. The .ARE file only needs one location changed, the actual tileset name instance as in "Tileset [CresRef] = ttr01. I would also recommend changing the area's name stored as the ResRef [CResRef] = test_area_1 to be something new for the new tileset, like test_area_2. The same needs to be done to the tag [CExoString].
The rest would be handled by the duplication process on the tileset in general.
Sooo, it appears SEN is right, the duplicator can handle this, you just have to also use a GFF editor to change the two area name related fields.
[Edit:} Actualy, it appears that the .are only stores the tileset name as in ttr01 in one location, the rest of the data in the .ARE file is tile numbers.
So, edit the .are file, change the name of the Area to a new name, and change the tileset reference to the new prefix, IE tctr05 or whatever it happens to be and it should work, provided the new tileset is now in the hak resources of the mod, or the override folder where it can be found.
It will work, provided the tileset is an exact duplicate. (with the renamed tiles, which tileset duplicator can handle just fine).
All of this depends on the individual tileset, and the naming conventions used in that set.
Many tilesets have tiles from other sets referenced in them too, as in addons to expand a given tileset. Which is what about 90% of tileset related stuff on the vault is... an expansion in some fashion of a bioware set.
The tileset duplicator is set to handle one translation/rename at a time. For several sets on the vault, you will have to run it more than once and adjust the tileset prefix name each time.
In otherwords, you may be able to accomplish this with tileset duplicator, provided you have a good understanding of the particular tileset you are working with. Add the .ARE extension to the filetypes that the duilicator touches etc. The .ARE file only needs one location changed, the actual tileset name instance as in "Tileset [CresRef] = ttr01. I would also recommend changing the area's name stored as the ResRef [CResRef] = test_area_1 to be something new for the new tileset, like test_area_2. The same needs to be done to the tag [CExoString].
The rest would be handled by the duplication process on the tileset in general.
Sooo, it appears SEN is right, the duplicator can handle this, you just have to also use a GFF editor to change the two area name related fields.
Modifié par Bannor Bloodfist, 25 septembre 2011 - 07:50 .
