16 réponses à ce sujet

[s e n]

this something that has been on my mind, flying like a nasty bug for a long time

we all know, especially the tileset creators which like quantity, that area loading time increases with the increase of tilecount (the overall number of tiles available in a set file), they directly linked, and this can even cause issues like crash or sreen freeze in the client. from my experience:
1-500 tiles: excellent
501-1000 tiles: good
1001-1500 tiles: average
1501-2000 tiles: bad
2001-2500 tiles: very bad
2500+ tiles: epicly bad

so, here is the idea: create an utility that creates, given an area created with a full tileset (lets say 10000 tiles, for sure there will be issues in the toolset, im not even sure if the engine can suppurt such huge amount, but thats not the point, the point is the tileset has a HUGE amount of tiles, giving almost infinite variations and a ****load of groups), the util should create a new set file wich has in its list ONLY the tiles that are used in the area.

of course, every single area will need its dedicated set file, and the util should be able to revert the process, so to say to switch back the area to the original set file, so it can be re-editable in the toolset for modifications.
basically we'd be able to use the full tileset when building in the toolset but, while playing, we'd get really small dedicated set files so to drastically reduce area loading times.

im no programmer so i just give this idea that should be veeeery useful for pws, not even aware if there is some engine limit that will make this just a non-sense

[Rolo Kipp]

 <Adding his voice...>

+1 Here =)

<...to the whirlwind>

[Bannor Bloodfist]

You realize that the .ARE file lists the tiles by their number in the .set.... that number is specific to the actual location in the .set. IE, tile number 845, would be referenced in the .ARE as tile 845.

So, that means that the .set would always require the full list of tiles up to the highest tile used in a particular area. So, say you painted a group, and that group contained a tile referenced in the original .SET as tile 10,001. You would need a duplicated .set that STILL contained that many tiles.

Basically, a complete waste of time and effort.

You could, theoretically, re-edit the new .SET to lower the tile count, but then you would have to do a search and replace on all the changed tile number references from original .set to the new .set.

Once that is done, you would have to keep a list of what was changed, so that you could revert the .are file to the original settings just so that you could re-edit the area with the full tileset.

All of that considered, makes this an idea with no real usage.

[Shadooow]

I think it could be done from the programming point of view, not sure how the game would handle special tileset (did I understood that right?) for each area however. From idea point of view, personally use because of this issue rather default tilesets with NWNCQ then these heavy tilesets. And there are still good tilesets without too many features so this is actually only issue for those combos which I try to avoid.

[s e n]

aye i meant modify also the are file to match the new set entry, and the util store the info it changed to allow switch back, of course its a batch process thats why i suggested an utility!!

1-create areas in toolset, save the module
2-run the util on the module: it automatically extracts and processes the are files, modifies them and creates dedicated set for each area (maybe using tag or blueprint info), stores the stuff that changes so to make the process revertible!! updates the module and stores the freshly created set files into a dedicated hak.

all this is possible, the problem may be if the game engine allows only a certain amount of set files in game (in toolset its not important since we'd be always using the mother one)

[Rolo Kipp]

<sets his...>

Ouch. That's disappointing.

So a utility that streamlined the .are and the .set (and the haks - basically "compiling" the add-on content of a mod so that players need only download what is actually used), would be a great deal of trouble for little or no gain. :-/

Well, it's not the first turkey I tried to teach to fly. :-P

<...stiff upper lip>

[henesua]

You are limited to 50 HAKs. So this utility would have to combine all of these SET files into a single hak to make it useful.

That said however... smaller tilesets with an aesthetic focus are better. The hak doesn't fill up your hard drive. The area loads more quickly. The aesthetics tend to be better. Wildwoods for example is a very nice tileset for more reasons than just aesthetics. Its relatively small and doesn't try to be anything but a forest.

Modifié par henesua, 09 octobre 2011 - 12:09 .

[s e n]

im not sure if the client needs the set files, since if it does, that wont explaine the increase of area loading time (since i think its caused by the server sending it to the client)

[Shadooow]

you need set file, otherwise client crashes at loading that area, i just have tested this

[s e n]

shadow, can you test this thing and see what happens when the client uses a different version of the set file of the server?

[Rolo Kipp]

<smiling happily...>

henesua wrote...
...Wildwoods for example is a very nice tileset for more reasons than just aesthetics. Its relatively small and doesn't try to be anything but a forest.

I love Wildwoods :-)

<...til he remembers something unpleasant>

[Shadooow]

s e n wrote...

shadow, can you test this thing and see what happens when the client uses a different version of the set file of the server?

already tested time ago, if you write into your set file that tile 2 is empty tile then you see empty tile

the walkmesh is however server-side so you cant luckily use this in order to move through walls

but I suspect that if even single file in set file would be missing it will crash client

[Bannor Bloodfist]

s e n wrote...

shadow, can you test this thing and see what happens when the client uses a different version of the set file of the server?

Depends on what the differences actually are.

Anything NEW on client side would be ok, but anything NEW on server side would crash it.

By new, I mean additions to exisiting.set, NOT a renumbered version, ie a version where a specific tile's location is different that what the server has.

It's too bad that the .ARE doesn't use/save tile NAME instead of it's numbered reference point in the .set file.  I think the design reason was that they originally intended the .SET to be a 2da type of file with column data instead of grouped row data.  

Any tileset that is over 12-1500 is way too large.  There really is no way to save area load time as the server must search the entire .set to find the tiles referenced, then pull the .wok file from that huge hak and ship that off to the client, that along with all the placeable, trigger, and creature data.  The biggest slow down on large .sets is searching for, and sending the .wok data. (Client doesn't need a wok, it is built from the tile mdl file while loading for sp, and in MP mode, it is sent byt the server REGARDLESS of client side hak contents.)

By the by, patch 1.69 raised the maximum TOTAL allowed tilesets to 100.

[Lightfoot8]

Bannor Bloodfist wrote...

By the by, patch 1.69 raised the maximum TOTAL allowed tilesets to 100.

ahh, I thought it was still 50,   But  even at 100 If you had a .set file per area you wuold be limited to 50 areas.

[Shadooow]

still its usefull idea for that group that wanted to rewrite nwn engine if they still working on it

[Just a ghost]

Couldn't you turn this idea around and make multiple set files all referencing the same common batch of tiles?

Say... you want to work with the DOA rural/city stuff with all it's expansions, but you don't need the city tiles for a certain area. And you just need city and fields (and not forest, swamp, and coast) for another area. You could make three SET files. One with everything in it, one without the city tiles, and one without the forest, swamp, and coast stuff.

As far as I remember tiles are referenced by their file name in the SET file, so I don't see why that couldn't work. No programming involved, although you could ask yourself if the task of making the separate SETs is worth the gain...

[Bannor Bloodfist]

Just a ghost wrote...

Couldn't you turn this idea around and make multiple set files all referencing the same common batch of tiles?

Say... you want to work with the DOA rural/city stuff with all it's expansions, but you don't need the city tiles for a certain area. And you just need city and fields (and not forest, swamp, and coast) for another area. You could make three SET files. One with everything in it, one without the city tiles, and one without the forest, swamp, and coast stuff.

As far as I remember tiles are referenced by their file name in the SET file, so I don't see why that couldn't work. No programming involved, although you could ask yourself if the task of making the separate SETs is worth the gain...

Right and wrong at the same time.

a .set file is scanned (read by the engine) by number first, then finds the tilename located at that number.  So, renumbering doesn't work.  You can't build the area with a tile that is physically the same tile name but in a different location (number) in the .set file wihtout crashing the toolset and game.  (Note, that you CAN reference the same tile name in more than one location, so it can have a different number and work, BUT, if you are adding new numbers to an already overly large tileset, you are defeating the stated purpose)  So, if you make the set smaller, by removing tiles, then they are renumbered to match their new locations in the .set file.  Once that occurs, you can't switch back and forth between the two different .set files.

Your idea is the exact thing he asked.  The answer remains the same.  The game engine can only use a MAXIMUM of 100 .SET files, regardless of the tiles used in those sets.  When you consider that NWN by default provides 26 .SET files as part of the main game resources, you are left with 74 expansion sets that you can use.  Why would you want to waste those on re-using the same basic tileset over and over again? 

Your better option would just be to build with smaller sets to begin with.  A huge tileset, with over 1200 tiles, is just a waste.  Most especially for a PW.  Since by engine constraints, you are better off with 16x16 areas or smaller, having to choose between 2000+ tiles for a maximum paint of 256 of those, you are obviously wasting by a factor of 8-10 already.  Granted, in a large tileset, a large number of tiles are not "chosen" by group/feature choice, but are needed to make the various terrains work together (terrains and crosser combinations etc), you still have a large number of groups/features that never, or seldom get used anyway.

Having a very large tileset only serves one real purpose, and that is to reduce the total number of haks required to get the tiles in use.  But, since you can combine multiple tilesets into the same .hak file, then it truly serves no real purpose and having a single .set file with 2000+ tiles only slows the engine down.  The HAK size doesn't make that much of a difference, as the game resources come in huge .BIF files anyway.  The issue occurs when reading the .set to find the tile(s) referenced in the area, then finding the associated .WOK file (server side) to send to the client.  This was a special request made by server admins, to prevent folks from having custom haks on their own pc's that would allow folks to walk through walls, doors, etc, by having a custom tlle with it's own locally loaded .wok that would allow such behaviour.  It has plusses in that it prevents folks from corrupting a walkable/non-walkable area, but it does require that the server spend a lot of time searching for, then sending, the wok data to the client.

Servers are the ONLY reason to have a separate .WOK file, as a SP mod, doesn't neeed the .wok file, it can actually build the wok on the fly when it loads the tile mdl file.  It will read a .WOK if it exists(this will override the one included in the mdl, but downside is that there is no way to compile a wok, so it actually has to load the mdl (complete with compiled built in wok, then read a txt file wok and compile it which is another slowdown), but it can also build it on the fly, EXCEPT in a client/server instance.  For that, the server MUST send the wok to the client.