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?