Grimrock

Can someone help me with this:

I am making a dungeon with the dmcbs_pack tileset, deep dungeon tileset and the normal ingame tilesets. My dungeon has 23 levels and the mod_assets are 431 mb. If I export the dungeon I get a .dat file that is aprox 283mb in size.

Questions:
1. is this too large a size for it to be viable / playable (it works so far, but I am wondering if I will bump in to trouble when finishing building on this dungeon)
2. what is a normal .dat size (and how for can you take it - how many mb's) I would like to know if mine is too large or a normal size for dungeon projects?

3. I have tried to add "--"infront of the standard assets script file for the tomb tileset, beach, forest, swamp .. but after exporting nothing changes in the .dat filesize it still stays 283mb -- what am I doing wrong here?

4. is there any other way to reduce the .dat size ? Tips are welcome

1. The size of the .dat file alone does not tell if it will work. There are a lot more factors to consider like number of floors and objects placed and what custom made stuff is included. Without knowing anything about your mod it's pretty much impossible to tell from a story or content point of view if it will work.
Yet i guess you want to know more about your mod being loadable and stable. IMO there's an easy check on that without debugging: export your mod from time to time, create a new game with this fresh export and check in task manager how large grimrock2.exe got after loading is finished. I'd say as long as you end up with 1.2 gb or less the game has a good amount of memory to work with and you're good.

2. Your number of levels seems quite reasonable to me for a decent mod.

3. The .dat file contains all custom assets you added: tilesets, textures, sounds, scripts and so on. For example exporting the Artifacts of Might demo dungeon made by minmay that comes with the LoG2 version of Germanny's tileset has "only" 8 levels but the resulting .dat file is 186mb due to the number and size of assets present in the tileset.

4. To reduce the file size you need to remove custom assets i.e. parts of the added custom packages you are not going to use.

The .dat file is compressed with zlib. The uncompressed size of your mod folder is a usable approximation of how much memory is going to be used by textures, sounds, etc. but not how much will be used by objects and saving (you need to examine the objects/components in your dungeon for that). The size of the .dat file is not really useful for approximating memory usage.

kelly1111 wrote:3. I have tried to add "--"infront of the standard assets script file for the tomb tileset, beach, forest, swamp .. but after exporting nothing changes in the .dat filesize it still stays 283mb -- what am I doing wrong here?

Why would that change the size? The standard assets are already in grimrock2.dat, that's what makes them standard. When you refer to standard assets in your mod, they are loaded from grimrock2.dat. It would be completely pointless for the editor to include them in your custom dungeon's .dat file.

Excluding standard assets DOES reduce memory usage; if you never define a material using a texture, that texture will never be loaded, and the same goes for sounds etc. Perhaps you should read the README included with the Dungeon Master Resource, because it covers exactly this - and includes an example!

kelly1111 wrote:2. what is a normal .dat size (and how for can you take it - how many mb's) I would like to know if mine is too large or a normal size for dungeon projects?

Well, there's a popular Grimrock 1 mod with a 627MB dat file, so this size is fine as long as you remember not to go over the effective limits on in-game memory usage. As a 32-bit Windows application, Grimrock 2 is limited to 2 GiB of address space, and it keeps copies of texture data etc. in system memory (not just on the video card) (blame DirectX 9 for this), and DirectX itself claims a big part of the address space*, leaving you with an effective limit of about 1.3-1.4 GiB of memory usage, which will INCLUDE TEXTURES, to be safe (remember that memory gets fragmented so the exact point at which you "run out" is going to vary). Naturally, every object/component/etc you add to the dungeon is going to make it use a little more memory when played. In fact, Isle of Nex comes very close to this limit already.

Note that the biggest memory balloon in Grimrock 2 comes from saving the game, because it has to serialize every object in the entire dungeon, concatenate them, and then compress the result. This is why proper usage of the minimalSaveState property is necessary. I wrote more about this here and here.

If your dungeon is using too much memory, you'll see these symptoms appear in order, almost always upon saving the game (because again, that's the biggest memory balloon):
1. Keyboard controls breaking - the game doesn't respond to keypresses, or treats a keypress the same as the previous one, etc. For some reason this seems to be the earliest visible problem that occurs. This should be considered a fatal bug in your mod.
2. Texture corruption - diffuse/normal/specular maps or GUI elements suddenly turn black or worse. This is definitely a fatal bug in your mod because it is just a tiny bit of bad luck away from crashing entirely.
3. Crashing with "out of memory".

kelly1111 wrote:deep dungeon tileset

The deep dungeon tileset is completely broken and you will need to make several changes to it before your mod will be releasable:
- adding OccluderComponents to the walls, floors, ceilings
- adding minimalSaveState to almost everything

*to be fair, OpenGL does this too