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
game launching order
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.)
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.)
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.HotWax wrote: A single resource cannot have multiple definitions.
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 ).
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
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.
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.Graf Zahl wrote:Why should it be different?
Dammit, I should know this stuff, I've been practising using it with DeePSea. Tired, so tired... ZZzz...
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.
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
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
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
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.