any tile MUST have a reference to all 4 sides, IE top_left, top_right, bottom_left and bottom_right, NONE of those entries can be blank, they MUST refer to an existing tile/terrain.
You basically can NOT accomplish what you are wanting to do, you can't edit an area created with a larger tileset with a smaller tileset. It flat will NOT work if you have painted any group or features. You COULD do it with plain tiles, IE if all forest and switch to all grass, but any groups also have entries for the 4 sides and are directly referrenced by their individual tilenumber in the .set file, IE tile314 or tile01 etc.
You could accomplish this by renumbering, and moving individual tiles around into a smaller .set file, but you would have to do this manually, by referencing the tile# of each tile in a group, and changing that accordingly.
However, even if you did this, the area created in the toolset, created with the larger.set file, would STILL be referencing the tile number from the larger .set file.
Your only real option here is a two part answer.
1) Create a smaller tileset based off the original, remove whatever you don't need, and renumber, adjust groups etc accordingly.
2) Re-create the area from scratch with the new tileset.
There are various tutorials available on merging/creating a tileset.set file, moving groups around etc, and those truly are your only answer.
as to commenting out some sections and not others on the tile info, well, the three lines you commented out, have a default setting OR are not actually needed. I am surprised that you can comment out the actual mdl name, but the other 2 have no real need. the msb01 doesn't actually exist, and really doesn't matter, it is a left-over from something else Bioware was attempting to accomplish. The Imagemap is for the minimap and the game can run fine without minimaps so it is not required either. There are other lines that can be removed, animloops for example, source lights etc, but NONE of that would help you with load times.
Your load issues are due to the length/size of the entire tileset, and each tile has to have the basic information stored in the .set file. Since it is a .txt file, it takes time to load and process, and it does this for every tile in the set, even if that tile is NOT in a given area. IE, a 2x2 area still has to load all 15000 tiles in a given set. Essentially, you are building a db type table, on the fly, every time you load an area, that table is filled with ALL the possible tiles that might be used from a given set.
CTP found this out the hard way, so have many other tileset authors. 12-1300 is practical max number of tiles to have in a set. If those tiles are animated in ANY way, that max number should be reduced as well. This means tiles that have extra alpha settings, extra animesh, or full animations. Extra source lights etc. Each bit of that increases load times. The higher the avg poly count also greatly affects load times. Falling leaves, moveable meshes (animesh leaves for example) all increase the load times.
The engine CAN be pushed to use higher poly-counts, but you end up trading time for looks.
Your absolute best bet is to create a NEW tileset, extracting what you want from the original, with only the stuff you want. Then build a NEW area using that NEW tileset.
P.S. As a side note, you CAN edit the data in .are files, but they have to be converted to html first, then edited manually to adjust all the tile# entires (no way to automate that as wrting the code would take longer than the doing) then converted back and re-importing the .are, .git etc.
It is NOT worth that amount of effort though, you would be wasting a huge amount of time just finding what tile numbers needed to change, and to what they needed to change to... then finding those entries in the .html and manually making those changes etc. Seriously, if you have already gotten far enough along to have multiple areas built, you would most likely save time by just re-building the areas. That truly can not be that compicated in comparison.
Modifié par Bannor Bloodfist, 10 mars 2012 - 06:42 .
