game launching order

adx · Post by **adx** » Mon Oct 13, 2003 11:21 pm

it seems that some wads should be launch in proper order,
ex: zdoom -file 1st.wad 2nd.wad 3rd.wad 4th.wad ....
wrong order cause some bugs in the game,
is there a way to prevent it or force creators to put a batch file
which would serve as a default launch order

Nanami · Post by **Nanami** » Mon Oct 13, 2003 11:24 pm

The order the wads are placed are for a reason. It may cause "bugs" sometimes, but if you have anything that will be overwriting something else, be it sprites, lumps, or whatever, there has to be an order to it, otherwise you'd just get random things happen each time you played.

HotWax · Post by **HotWax** » Tue Oct 14, 2003 1:50 am

Heh, there is no otherwise. A single resource cannot have multiple definitions. The one used is the last loaded. Hence, to use adx's example:

zdoom -file 1st.wad 2nd.wad 3rd.wad 4th.wad

resources in 4th.wad would have complete precedence over duplicates in any of the previous 3. 3rd.wad would have precedence over the first two, and so on. If you want it the other way around (1st.wad has precedence), change the line to this:

zdoom -file 4th.wad 3rd.wad 2nd.wad 1st.wad

This may seem backwards, but just remember that the LAST loaded resource is used and you'll be fine. (If you draw a picture on a chalkboard, erase it, draw another, erase that, and draw a third, is the first picture still there or the last one? Think about it.)

Post by **Enjay** » Tue Oct 14, 2003 5:28 am

HotWax wrote: A single resource cannot have multiple definitions.

Heh, just to be picky, they can (kind of) if they are cumulative resources like the various *info and *def lumps. That is if you consider them as single resources. I suppose you could look on them as potential parts of a whole, or something. And of course, entries modifying the same instruction in different *info/*def lumps will use the last one loaded.

Anyway, what HotWax said holds true for 99.937261% (approx) of resources found in a WAD

Normal service will resume after this post.

Edit: oh yeah, and the new TX support will be different again IIRC (could be wrong there - I forget the specifics, and can't be bothered looking

).

Post by **Graf Zahl** » Tue Oct 14, 2003 5:48 am

Enjay wrote: Edit: oh yeah, and the new TX support will be different again IIRC (could be wrong there - I forget the specifics, and can't be bothered looking ).

Why should it be different? I think it will be the same as flats and sprites. Those resources only override ones of the same kind and cannot be overridden by resources of a different type.

Post by **Enjay** » Tue Oct 14, 2003 6:49 am

Graf Zahl wrote:Why should it be different?

I'm not sure that it is, but I remember a great deal of discussion about same name resources - although I think that was a TEXTURE versus a TX with the same name discussion. I can't remember if a patch with the same name as a TX will get overridden or not. I have a vague recollection that TX's will "stand on their own" but I forget the specifics, and I'm tired.

Dammit, I should know this stuff, I've been practising using it with DeePSea. Tired, so tired... ZZzz...

HotWax · Post by **HotWax** » Tue Oct 14, 2003 9:28 am

The reason the *defs etc are cumulative is because when a second one is encountered, it is appended to the first in memory. There is still only one resource. You can also see flats/sprites/textures as each being in their own namespace. The only other exception I know of is the various lumps that make up a map definition, and they each go in their own map block, basically.

randomlag · Post by **randomlag** » Tue Oct 14, 2003 10:48 am

Right, TX is different despite my best efforts

You can have the (in)famous DUCT1 as a TX that is different from a DUCT1 in PNAMES. IOW duplicate lump names are allowed.

I haven't really thought much about different PWAD having duplicate TX lump and duplicate PNAMES/patch variations. Wait till it happens

Post by **Graf Zahl** » Tue Oct 14, 2003 10:54 am

randomlag wrote:Right, TX is different despite my best efforts

You can have the (in)famous DUCT1 as a TX that is different from a DUCT1 in PNAMES. IOW duplicate lump names are allowed.

So what? DUCT1 as flat or sprite has been possible all the time since Boom without overriding the patch of the same name. Think of a namespace as a separate directory and it all makes sense.

HotWax · Post by **HotWax** » Tue Oct 14, 2003 10:55 am

randomlag wrote:I haven't really thought much about different PWAD having duplicate TX lump and duplicate PNAMES/patch variations. Wait till it happens

The last loaded will overwrite the previous ones, just as it's always worked?