game launching order

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

game launching order

Postby 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 :arrow:
User avatar
adx
No Custom Title.
 
Joined: 01 Aug 2003

Postby 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.
User avatar
Nanami
Natdhipytadd
 
Joined: 15 Jul 2003
Location: That little island pritch created.

Postby 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.)
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby 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 :P ).
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Postby 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 :P ).



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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby 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...
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Postby 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.
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby randomlag » Tue Oct 14, 2003 10:48 am

Right, TX is different despite my best efforts :D

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

I haven't really thought much about different PWAD having duplicate TX lump and duplicate PNAMES/patch variations. Wait till it happens :roll:
User avatar
randomlag
 
Joined: 17 Jul 2003

Postby Graf Zahl » Tue Oct 14, 2003 10:54 am

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

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



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. :P
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby 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 :roll:


The last loaded will overwrite the previous ones, just as it's always worked?
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID


Return to General

Who is online

Users browsing this forum: No registered users and 9 guests