How about an Unreal-like package system? That would make it a lot easier to use add-on data without having to load all the wad's manually; You could just store something like this in the linedef data:<br><br>tDoom.TEXTURE1.BIGDOOR2<br><br>In this case, when the texture is needed, it could load a package named tDoom.dtx and look for the sub-package TEXTURE1 and finally load the entry BIGDOOR2. <br><br>And the reference to the patch in BIGDOOR2 would tell the following:<br><br>pat=pDoom.DOOR2_4 x=0 y=0<br><br>Then the game would load package pDoom.dpt, look for the entry DOOR2_4 and place it at x/y coordinates 0:0.<br><br>Consider the packages as OO virtual file systems. They can have any extension, contain any type of file, and thus can have packages within them. Extensions could be used for the user to determine what the package mostly contains. The types of the files could be determined by the ``package compiler'' and stored in the package. Files that cannot be recognized as supported files would have the type name ``Other''.<br><br>This is my idea of possible extensions:<br><br>.d (Doom) .h (Heretic) .e (HeXeN) .2 (Doom 2, including Final Doom): Packages that contain a mix of many types of files, or only progs or something like that.<br><br>Next, i will only mention the Doom extensions. It's obvious how the other game's extensions will look.<br><br>.dtx: Textures.<br>.dpt: Patches.<br>.dm: Maps.<br>.dg: All graphics except patches and sprites.<br>.dms: Music.<br>.dsp: Sprites.<br>.dtp: Tables and palettes.<br>.ds: Sounds.<br><br>Also, this would have the advantage that you'll only have to load a level/main script of the game and then it would load all packages _when they are needed_. And the packages could be considered as ``garbage'' when they are not needed anymore by any other loaded package and deleted from memory. This would save loads of memory and processor time, i think.<br><br>What do you think of it?

I can't change formats of the levels, textures and flats, because there won't be an editor understanding this format. Also I don't see a point why packages are better than wad files, since wad lumps are loaded when needed and freed when not needed anymore. It also uses a caching system. OTOH some of the package-style ideas possibly will be implemented.

The only thing you would have to change is to make the flats/texture name fields bigger. WadAuthor's sidedef/sector structures for example can be adapted just by making a new config file and changing the required values.

You mean each map having it's own texture / flat script with mappings of the texture/flat names to the actual names. Actually a good idea. What others think about this?

If it's done in a way even stoopies like me will be able to use it, why not? <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) --> In case no custom mappings are provided, the system should fall back to the default ones from the original game.