Defining a new enhanced source port standard (Boom+/MBF+)

7 hours ago, Da Werecat said:

I should probably clarify how I see this working.

 

I don't think that any command line parameters should be needed to activate the new features. They must all be available by default. But they should be disabled in existing complevels for emulation accuracy.

 

Since there are conscious exceptions even now (like sky transfers), some of the new features may still be allowed to work in cl9, cl2, et cetera, provided they don't wreck demo compatibility with emulated engines.

 

As for the potential "-complevel 20" or the like - this shouldn't be needed unless the changes are gonna be rolled out in several phases. New phase = old default behavior is compleveled for compatibility. Technically, this is gonna be emulation of an old engine.

 

Even if there's gonna be only one official phase, the current default behavior of PrBoom+ should be preserved, probably.

This is what I meant. Sorry if I've confused things. The current behaviour of prb+ has a complevel and cl(-1), or no cl specified at all, runs this current/default feature set. I figure that moving to a new complevel for implementing the new features would make it easier for other ports to see what is intended as the extensions to Boom and not a prb+ specific feature - but I do appreciate this is likely unaware of what devs would consider best, both to implement and to replicate in other ports :)

Share this post


Link to post
8 hours ago, kb1 said:

@traversd: Interesting ideas! This is good stuff. But, instead of fixing existing linedefs with a complevel, creating a new linedef special that has different/fixed behavior solves the issue, without adding to the dizzying number of complevels.

Complevels are there to support differences in ports that are no longer maintained. Can you imagine the confusion that can be caused by having a "original Boom 2.02" complevel, and a "Boom 2.02 + Boom Phase 1" complevel, etc.? You'd be half-way through an hour-long map, only to have a sector not operate - this is a nightmare.

I intend on having a clear separation of duties, between demo version indicators, complevels, and the modification of any existing data structure, functionality, etc. Using PrBoom+ as a base instills an awesome sense of responsibility, to avoid disrupting the demo sync apparatus, the gameplay feel, etc.

Yep. Don't fix anything existing if it relates to in-game mechanics. Draw a line in the sand so to speak by moving to a single new "boom+" complevel that does everything cl9 does (even the broken stuff) and add the new stuff. Ie: what is currently coded as "if cl9" would become "if cl9 or cl20" and the additions would be "if cl20"

 

This (hopefully) allows the new standard to work with all the old levels/demos. But also other ports can then focus on the additions indicated by the cl20 references in the code? (And of course some documentation specifying what is considered the new standard).

Share this post


Link to post

To be honest, we already have things that should be functionally identical, but work differently between complevels. Boom is not just a superset of vanilla Doom, there are differences in behavior.

 

So I'd prefer some bugfixes to be included. Although this is really more about PrBoom+ in particular, it has little to do with the new mapping/modding standart.

Share this post


Link to post

The conversation around complevels got me thinking: am I right in presuming that UMAPINFO, if implemented well, could work correctly even at PRBoom complevel 1 or 2?  

 

Theoretically it shouldn't change anything physical about a map, merely the map's metadata if you will, so I'd personally like to see that supported by whatever this new fork of PRBoom will be called regardless of complevel defined.

Share this post


Link to post

Level transitions are very important for continuous demos.

Share this post


Link to post

PrBoom-Plus may be the obvious place to start building a new standard on... but its netcode is horrendous. @Graf Zahl think you can fix the netcode for your UMAPINFO fork? I'm pretty sure a new standard would require the base port to be capable of recording multiplayer demos.

Share this post


Link to post

Sorry, but the netcode is not something I'd want to touch.

6 hours ago, Bauul said:

The conversation around complevels got me thinking: am I right in presuming that UMAPINFO, if implemented well, could work correctly even at PRBoom complevel 1 or 2?  

At the moment UMAPINFO is independent of complevels, instead there's a separate command line switch -nomapinfo to disable it in case it is needed.

Unlike many other features, not loading the intended UMAPINFO with a map set can break stuff a lot more than playing on the wrong complevel, so I am not sure what's the best approach here. But I do not like the idea of not being able to play such mapsets on a lower complevel. Imagine stuff like BTSX that's nominally vanilla compatible maps. If that came with customized level progression it should still play correctly on complevel 3, right?

 

Share this post


Link to post

Heck to me it'd make sense that you could use UMAPINFO to give a complevel to your level. So BTSX would get a UMAPINFO telling to use complevel 2 (vanilla Doom II), whereas Valiant would get a UMAPINFO telling to use complevel 11 (MBF).

1 person likes this

Share this post


Link to post

I think it's against the spirit of complevels, unless it's not really a complevel you're setting, but rather a number of options associated with it.

Share this post


Link to post

@Danfun64 Changing netcode/demo recording feels more like port features, not an editing/game data standard.

3 hours ago, Graf Zahl said:

Unlike many other features, not loading the intended UMAPINFO with a map set can break stuff a lot more than playing on the wrong complevel, so I am not sure what's the best approach here

It could, but then so can loading (or not loading) a DEH/BEX patch. The aspects it is controlling are all elements of the Vanilla EXE so UMAPINFO being digested regardless of complevel sounds OK. How would/does it handle UMAPINFO lumps in multiple resource files?

 

@Gez complevel key/value sounds OK too :)

Share this post


Link to post

It loads all UMAPINFO lumps and uses the last record it finds for any given map

Share this post


Link to post

As a mapper, I'd really love to be able to never-ever think about complevels again.

 

Also, maybe I should've dropped my "KaBoom" port name suggestion in this thread instead. :P

1 person likes this

Share this post


Link to post
1 minute ago, Xaser said:

As a mapper, I'd really love to be able to never-ever think about complevels again.

Which is why I want a port like PrBoom+ to have defaults that are as polished as possible without breaking everything.

 

Although I feel that some of the things that annoy me to no end (like clipping glitches aka wallrunning) will be defended by the majority. You can't fix everything and stay conservative at the same time.

Share this post


Link to post

I'm torn on having complevels defined in UMAPINFO itself. On the one hand, there's a certain purity to a UMAPINFO design that doesn't impact how an individual map is played in any way. So if you ran the map in a port that didn't support the new format, you'd get the wrong name, sky and music, but the map itself would still work exactly the same way. Also, we'd be going down the route of including a variable that was source-port specific, and that also seems against the notion of a universal MAPINFO.

 

On the flip side, ensuring the player loaded the map with the right complevel every time does seem quite appealing. One less thing the player can get wrong is never a bad thing.

 

Do any other ports support PRBoom's complevels, or is it strictly a PRBoom thing?

Share this post


Link to post

The idea to write "complevel 2" in UMAPINFO feels wrong. If you're targeting source ports with UMAPINFO support, you're not making a wad for vanilla Doom.

 

But there might be some sense to future-proof the wad by specifying that it was tested against a certain version of this new PrBoom++. However, this would call for the current default complevel to be assigned its own number (rather than -1) right away.

 

Maybe it'd be better to "simply" apply extra care when implementing new things, so that they don't break anything. But screw-ups happen.

 

Share this post


Link to post

You also cannot assume that the presence of a UMAPINFO implies usage of the new complevel. Some mappers may just use it to set custom skies or intermission text changes but otherwise want it to work on lesser ports, too, with  some known restrictions. I agree that forcing a complevel through the lump is dead wrong. That should be the end user's choice, not the mapper's.

 

1 person likes this

Share this post


Link to post
9 minutes ago, Graf Zahl said:

You also cannot assume that the presence of a UMAPINFO implies usage of the new complevel. Some mappers may just use it to set custom skies or intermission text changes but otherwise want it to work on lesser ports, too, with  some known restrictions. I agree that forcing a complevel through the lump is dead wrong. That should be the end user's choice, not the mapper's.

 

Allowing a user-specified complevel to override it is fine, but mappers should be able to set the proper compatibility mode themselves to ensure that their map plays as intended out-of-the-box. ZDoom's mapinfo and Eternity's options lump both allow compatibility flags to be forced on or off, which is the only reliable way to keep maps from being unintentionally broken or cheesed due to the wrong settings being used (for instance, the raise-by-texture-height behavior that breaks AV map07, or the incorrectly projectile-blocking torches and wrong invisibility behavior in ZDoom).

Share this post


Link to post

Correct, but don't forget that complevels imply a lot more changes than flipping some compatibility options. It should be able to set those options, but I do not think it's correct that the map can force how weapon switching works.

 

And if set, those compatibility options should be obeyed independently of complevel.

 

Share this post


Link to post
19 hours ago, Graf Zahl said:

I guess whatever you do, some person will always do the odd thing and create something broken.

Like this mod for Doom1 containing a chaingunner in one level...

No need to guide every far out eventuality with a safety check. Sometimes you have to accept that what's broken may not work as intended.

 

I'm not really sure that this may accomplish anything. Right now there's two distinct numbering schemes that exist: Legacy/ZDoom/EDGE (which steered clear of each other's numbers unless implementing them themselves) and Eternity. And if you look closer there's very little in the extended numbers that may be backportable to a basic standard. Even more importantly, the only maps using these linedefs are so port specific that there's no point trying to make them work. If a Boom+ standard materialized it should simply exclude all of this and use a number range that's free of conflicts.

Concerning ZDoom, it defines complete translation tables to map Doom format linedefs to Hexen format, but none of that is helpful here because it does not remap some clashing numbers but does a full translation into a different format.

 

Good info. Yeah, don't worry about those fields yet. Currently they are of no use, but I want to establish a way of identifying map types and versions for the future. We've been using 'tricks' to know how to load maps for a long time, and it gets more difficult with every new version of every port. Being able to tell the editor, or the engine "Here is how to interpret this map", is going to be part of the infrastructure that supports wide compatibility in the future. But, it must be defined exactly - what a particular Map Type or Version means, must be explicitly defined, on a web page somewhere that is in support of this effort. I'm working on that slowly.

7 hours ago, Gez said:

Heck to me it'd make sense that you could use UMAPINFO to give a complevel to your level. So BTSX would get a UMAPINFO telling to use complevel 2 (vanilla Doom II), whereas Valiant would get a UMAPINFO telling to use complevel 11 (MBF).

 

6 minutes ago, Graf Zahl said:

You also cannot assume that the presence of a UMAPINFO implies usage of the new complevel. Some mappers may just use it to set custom skies or intermission text changes but otherwise want it to work on lesser ports, too, with  some known restrictions. I agree that forcing a complevel through the lump is dead wrong. That should be the end user's choice, not the mapper's.

 

Please hold off on the complevel ideas. As Graf states, complevel has a specific purpose: To allow the engine to play demos from unmaintained (dead) ports. I know it seems like a convenient way to set a bunch of settings (which is essentially what it does), but once you start "dual-purposing" variables, you lock yourself into  a situation where artificial dependencies become a real problem. I agree that there needs to be a way to state that "I want to my current game to act and feel like Boom, or Final Doom". This has nothing to do with the format of the specific map, or the way a demo plays. A system where multiple settings can be grouped together would be a nice feature. But, it really needs to be separate from complevel.

 

The only reason you need complevel is that the demo, and the map does not specify which game it is for.

 

I made that sentence bold and underlined because it is an important concept.

 

@Graf: This is why I want to be able to specify MapType, Version, etc., in the UMAPINFO lump. We need a way to explicitly define exactly the format the mapper was going for when he/she made the map. Demos also need to store this info, somehow. I know we've gotten along pretty well without it so far. But, in fact, we haven't - instead, we've been struggling. Complevel is only for PrBoom, and, honestly, it's a hack to tell the engine how to interpret the map and gameplay. With a specific set of identifiers, placed into the maps by the map author, we can move forward with accurate, robust compatibility capabilities. I would like to see UMAPINFO, along with these specific identifiers, become requirements for new maps. This should be easy: Today, you have to specify "Boom", "Doom in Hexen Format", etc., when you go to make a new map in Doom Builder, for example. Doom Builder could have a UMAPINFO page that automatically sets some sort of map identifier. And, Doom Builder could read this value when loading a map, for example.

 

But, again, I want to do some extensive research before defining exactly what identifiers we should add. Moving forward for future maps, it is easy to identify maps, but I wish to see if proper definition of Map Type, etc., will provide some support for older port-specific feature compatibility, allowing multiple ports to load some port-specific maps with some fidelity. It may be wasted effort, it may not. I'll keep you (and everyone else) informed.

 

I do not worry about the fact that something is not yet in an editor. That should not prevent forward progress in this standard. And, this should be an easy screen to whip up in DB. I am starting to think big about this standard. We have a real chance to solve a lot of these 20+ year old compatibility issues. I've realized that, back when ports were being developed, it simply was not possible to define much more than the Boom standard back then. But, today, we know what new features are available.

 

One thing I can say with confidence: There is no excuse for having to set a complevel on a new map in 2017. My focus is to solve such issues with this new standard.

 

@Network code: KBDoom has excellent peer-to-peer LAN code. And PrBoom+ has a server/client component. I intend on porting my netcode over, and, eventually working on WAN/Internet support w/client prediction, if I can make it work smooth enough to my satisfaction. I just need some time.

 

Thanks, everyone for the ideas, and the interest.

Share this post


Link to post
8 hours ago, Gez said:

Heck to me it'd make sense that you could use UMAPINFO to give a complevel to your level. So BTSX would get a UMAPINFO telling to use complevel 2 (vanilla Doom II), whereas Valiant would get a UMAPINFO telling to use complevel 11 (MBF).

Having re-read what you typed, I see: You want to alter the BTSX.wad to add something that tells the engine to apply "complevel 2", without having to add that to the command-line. I am strongly considering how to accomplish something like this. I make a fix for this in KBDoom - I don't know how it will be universally received. Let me describe:

 

In KBDoom, when you load BTSX.wad, it automatically searches the paths for a file named BTSX.GFO ("GameInfo"). Yes, I wrote this code before ZDoom added its GAMEINFO lump, which really kinda messed me up...

 

Anyway, if found, the .GFO file is in a simple name/value pair format that allows all manners of modifications to the game data and logic, including the definition of new actors, sounds, effects, etc. This could easily serve to set options, like a complevel, and, then best part of it is that you don't need to modify any original WAD files. I wanted all my WADs to stay 100% exact, as they were in their ZIP files, so this provided me a way to modify WADs without modifying them, so to speak.

 

Maybe this approach could be applied to other ports as a standard feature. There could even be a file with many wads definied in it, with WAD name, an MD5 hash, and a list of options, such as complevel. By the way, I suggested this in 2011, in the form of a downloadable online database, but we all argued about the format of fields, and got totally distracted from the wonderful benefits it could provide the community. I think this is the ultimate solution - you don't have to alter your WADs, and everyone can help build the data.

 

People might notice that I've been preaching about these same issues for a long time now :)

 

EDIT: I noticed that in that thread I argued against using hashes. I now think that was a bad idea - the hash makes it specific to one exact file, without mistakes. Otherwise, I think it's a good idea. Something like a SINGLE downloadable file, with each line looking like this:

 

Filename<TAB>Hash<TAB>Options:

BTSX.WAD<TAB>3C062889423218BC<tab> (options...)

 

Edited by kb1

Posted (edited)

Share this post


Link to post

... I can't help but feel like you've never heard of the existence of av20.wad, because it feels like that or something similar would've given you an idea on how to do something like that without being so awkward and probe-y.

 

Namely, having the GAMEINFO stuff be, y'know, a wad lump, and making those fixes by making another WAD that just contains the GAMEINFO stuff that you can load after everything else.

Share this post


Link to post
3 hours ago, Da Werecat said:

The idea to write "complevel 2" in UMAPINFO feels wrong. If you're targeting source ports with UMAPINFO support, you're not making a wad for vanilla Doom.

So I guess BTSX isn't a wad for vanilla Doom, because it targets source ports with ZMAPINFO and EMAPINFO support.

 

Of course at the moment there are no ports in existence that support both ZMAPINFO and EMAPINFO, so here we have it folks, nobody can play BTSX.

 

4 hours ago, Bauul said:

On the one hand, there's a certain purity to a UMAPINFO design that doesn't impact how an individual map is played in any way.

Too late! Map-specific behavior such as which level you go to when you reach the exit and boss death events are already in.

 

If you make a map that is exited when you kill all cyberdemons, and you play it without UMAPINFO, you'll notice a very important difference after you kill the last cyberdemon...

 

4 hours ago, Bauul said:

Also, we'd be going down the route of including a variable that was source-port specific, and that also seems against the notion of a universal MAPINFO.

Sorry but addressing how to add in port-specific features is an absolute necessity if you want it to be universal.

 

Otherwise, well. Let's imagine three ports which we'll call ADoom, BDoom, and CDoom. (No relationships with any existing ADoom, BDoom, or CDoom.) All three ports implement their own MAPINFO format (AMAPINFO, BMAPINFO, CMAPINFO) and also UMAPINFO.

 

There is a map that needs option foo set in ADoom, option bar set in BDoom, and option flubalapo set in CDoom. UMAPINFO, in its wise decision to be universal, does not allow to specify these port-specific options. Result:

 

The map is shipped with a AMAPINFO lump, a BMAPINFO lump, and a CMAPINFO lump. UMAPINFO is not included because either it'd be ignored in favor of the port-specific MAPINFO lump, or it'd result in the port-specific MAPINFO lump, with its absolutely essential and vital option set, to be ignored and that would completely break the map.

 

Conclusion: port-specific options are an absolute necessity to integrate in anything calling itself a universal MAPINFO format! You absolutely need them!

 

Which means that we need to establish the standard for how port-specific options are set. Personally I see three possible approaches:

  1. Port sub-blocks. If you are the target port, read options in the sub-block, if you aren't, ignore the entire sub-block.
  2. Port prefix, e.g. prboom_complevel instead of complevel. If an option is prefixed with your name, read it, otherwise ignore it. To make parsing simpler, universal options need never to have prefixes.
  3. No special attempt made at filtering options by ports, so just ignore keys you don't recognize and parse those that you do. What happens if two different ports add an option with the same name but different semantics is anybody's guess, which is why I am 100% in favor of option #1 or #2 instead of #3.

 

Share this post


Link to post

To be honest, this entire thing is close to derailing. Instead of thinking up *realistic* things that could be made part of a new standard, some elaborate ideas get tossed around which will only result in the whole thing getting discussed to death.

 

All I have seen so far that is reasonable is:

 

- 16 angle rotations (from the looks of it already supported by PrBoom+, definitely supported in ZDoom and I believe also in Eternity)

- a well defined way to make hires replacement (definitely present in PrBoom+ and ZDoom, haven't checked Eternity for it)

- some easier ways to define wall animations. (all groundwork already done in Boom.)

- Strife's animated doors. (can be taken from ZDoom.)

- DECORATE lite (which can easily be based on ZDoom 2.0.63's parser and reduced to a feature set that is compatible with more basic engines.)

 

 

The most important thing has already been stated by kb1 in the first post:

 

"Start small"!

 

Considering that, this should really be contained things that actually help mappers, and preferably stuff where some implementation already exists. These complicated metadata things will fail for the sole reason that ports are different and thus have different needs to handle this stuff.

 

Share this post


Link to post
1 hour ago, Gez said:

So I guess BTSX isn't a wad for vanilla Doom, because it targets source ports with ZMAPINFO and EMAPINFO support.

Of course it is a vanilla wad. With small additions realized through port-specific lumps.

 

The whole purpose of UMAPINFO is to allow the usage of major features (like altered level progression) without breaking compatibility with any popular source ports. Not vanilla features, or small tweaks like tall skies.

 

1 hour ago, Gez said:

Of course at the moment there are no ports in existence that support both ZMAPINFO and EMAPINFO, so here we have it folks, nobody can play BTSX.

Uh-huh.

 

32 minutes ago, Da Werecat said:

The whole purpose of UMAPINFO is this, not that.

In case that sounded too strict: yeah, I guess I see the point of using UMAPINFO for the sole purpose of storing the complevel for the user's convenience. Just, I dunno, feels small somehow?

 

But not exactly pointless.

Edited by Da Werecat

Posted (edited)

Share this post


Link to post
4 hours ago, Gez said:

Too late! Map-specific behavior such as which level you go to when you reach the exit and boss death events are already in.

 

If you make a map that is exited when you kill all cyberdemons, and you play it without UMAPINFO, you'll notice a very important difference after you kill the last cyberdemon...

Well, to my point, where you go after you finish a level is not within the scope of how an individual map is played, because the change happens after a map is finished.

 

Also, I would be extremely hesitant to include "boss death" features as part of UMAPINFO.  That's port specific behavior, and if it is used, should be something contained in the map information itself.  

 

Quote

Sorry but addressing how to add in port-specific features is an absolute necessity if you want it to be universal.

Honestly, I think this is making UMAPINFO far too complex.  I'd argue that it shouldn't contain anything that isn't effectively a vanilla feature.  Things like music, sky, next-level-progression, name, intermission screens etc. are all things that exist in the vanilla game, they're simply hard to manipulate.  The purpose of UMAPINFO is to make these elements easy to manipulate, and that's all.  It shouldn't be a way to add any kind of additional, port-specific behavior into the game.

 

Port-specific lumps, which of course already exist for those that support them, should continue to exist for port-specific features.  

 

Edit: Arguably this is derailing the thread slightly.  Let's continue the UMAPINFO discussion over at its thread

Edited by Bauul

Posted (edited)

Share this post


Link to post

Boss death settings have to be included in mapinfo because, like skies and music tracks, they're hardcoded to mapslots in the vanilla game. If they're not freed up to be used on different slots than e1m8, map07, etc, mapinfo is randomly missing a basic feature of defining a map.

1 person likes this

Share this post


Link to post
6 hours ago, Arctangent said:

... I can't help but feel like you've never heard of the existence of av20.wad, because it feels like that or something similar would've given you an idea on how to do something like that without being so awkward and probe-y.

 

Namely, having the GAMEINFO stuff be, y'know, a wad lump, and making those fixes by making another WAD that just contains the GAMEINFO stuff that you can load after everything else.

GAMEINFO is a known WAD lump in KBDoom, and it works exactly as you describe. But you cannot create a GAMEINFO wad for av20.wad, and call it av20.wad :)

 

Now, yes you could do something like AV20-GAMEINFO.wad. You could also call it AV20.lmp, which would contain the data without the WAD header. But that looks like a demo file. So I decided to change the file extension instead. I wanted my engine to try to load it automatically, without having to add "-file AV20.lmp" to the command-line. It's kinda cool, actually, and it works really well and seamless. It's automatic, and my WADs stay original, and play well with a few little "fixes" here and there - heh. Here's an excerpt from my documentation (it looks better with its original formatting, but, whatever):

Spoiler

GAMEINFO lumps must be loaded by the game engine to be utilized. For convenience, there are various ways to apply GAMEINFO definitions to a game, however, the choice of method used only affects the order in which multiple GAMEINFOs are evaluated, not the way they are evaluated. Here's a list of the various ways to apply GAMEINFO:

Standard embedded GAMEINFO lumps - The game engine requires KBDoom.wad to be loaded, directly after loading the selected IWAD (the main game file, supplied by id Software, such as doom2.wad). KBDoom.wad contains an embedded GAMEINFO file, which defines the default GAMEINFO set, and typically should not be modified. Furthermore, if present, the KBDoomFX.wad redefines some things previously defined in KBDoom.wad, and adds some new definitions. If KBDoomFX.wad is present, the game engine will load it (and its GAMEINFO definitions) immediately after KBDoom.wad's GAMEINFO, before adding custom GAMEINFO files. This allows KBDoomFX to enhance KBDoom, and allows custom games to enhance or change KBDoom and KBDoomFX definitions.

 

  • A lump embedded in a loaded wad, named "GAMEINFO" - This method best hides the implementation details from the game player. These lumps are evaluated immediately after the wad is loaded. So, for multiple wads, the order the wads are loaded determines the order in which the GAMEINFO lumps are loaded, so each wad can alter the previous wad's definitions. When distributing a custom wad, embedding the GAMEINFO lump within it is usually the best way to go.
  • A .gfa file with the same base filename as a loaded wad - By default, when a wad file is loaded, the engine looks down the search path for a file with the the same base filename as the wad file, but with a ".gfa" extension. (Note that this is different than a ".gfo" extension). If found, the engine automatically loads the file as a GAMEINFO definition. This allows wad-specific GAMEINFO definitions to be loaded without altering the wad itself, and without needing to list the GAMEINFO file on the command-line. This is especially useful to convert a wad's port-specific features to KBDoom, without modifying the original wad file. Regardless of whether or not the wad file path was specified, the engine looks for a .gfa file down the search path defined with the "-path" switch. Therefore, a folder could be created to contain all .gfa files, and, if that folder is added in a "-path" switch, all .gfa files can be organized in one place. Finally, a "-noautogfa" switch can be used to prevent the engine from attempting to find .gfa files. This switch prevents the game from loading ANY .gfa files, however. NOTE: This mechanism also works for IWADs as well as KBDoom.wad and KBDoomFX.wad.
  • On the command-line, in a "-gameinfo" switch - In this case, the file loaded is simply a text file, typically with a ".gfo" extension, containing GAMEINFO sections. These GAMEINFOs are the last definitions loaded, before the game starts, so they have "final say" on the internal GAMEINFO data structures. In other words, loading a GAMEINFO file this way ensures that it's definitions will not be redefined by another GAMEINFO lump. Multiple GAMEINFO files can be listed after the switch. Also, if a file path is not provided, the engine will search for the file down the search path defined with the "-path" switch. When using the "-gameinfo" switch, all files are assumed to be GAMEINFO files, so the ".gfo" extension is not necessarily required. Note that ".gfa" files are supported too, but this is not recommended, because the game already attempts to load these automatically.
  • On the command-line, in a "-file" switch - GAMEINFO definition files added in a "-file" switch are loaded in the order listed in the "-file" switch. That rule applies to embedded GAMEINFO lumps in wad files listed in the "-file" switch as well. NOTE: The GAMEINFO files MUST HAVE a ".gfo" or ".gfa" extension to distinguish them from wads and "single lump" files. These files are simply text files with a ".gfo" or ".gfa" extension, containing GAMEINFO sections. As with other filetypes in the "-file" switch, multiple GAMEINFO files can be listed. If a file path is not provided, the engine will search for the file down the search path defined with the "-path" switch. Note that it is not recommended to use .gfa files in this manner, because the game already attempts to load these automatically.
  • Dragged-and-dropped onto the game's executable. - This method has the same rules and effects as when using a "-file" switch. However, it's also possible to drag and drop onto a shortcut to KBDoom, which could also contain a "-file" switch. In this case, all of the dragged files are evaluated before the "-file" switch.
  • As switches in a response file - As with any other command-line switch, any of the above methods that use a command-line switch can be placed within a response file, and loaded that way.

 

Order of Evaluation

The order in which GAMEINFO definitions are parsed becomes critical when GAMEINFO definitions are to modify previous definitions. Following is a list of GAMEINFO sources, sorted in first-to-last order of evaluation:

  1. Read all GAMEINFO lumps embedded within the IWAD, in order of appearance.
  2. Read [IWAD name].gfa
  3. Read all GAMEINFO lumps embedded within KBDoom.WAD, in order of appearance.
  4. Read KBDoom.gfa
  5. Read all GAMEINFO lumps embedded within KBDoomFX.WAD, if it exists, in order of appearance.
  6. Read KBDoomFX.gfa, if KBDoomFX was loaded.

 

 

 

6 hours ago, Graf Zahl said:

To be honest, this entire thing is close to derailing. Instead of thinking up *realistic* things that could be made part of a new standard, some elaborate ideas get tossed around which will only result in the whole thing getting discussed to death.

 

All I have seen so far that is reasonable is:

 

- 16 angle rotations (from the looks of it already supported by PrBoom+, definitely supported in ZDoom and I believe also in Eternity)

- a well defined way to make hires replacement (definitely present in PrBoom+ and ZDoom, haven't checked Eternity for it)

- some easier ways to define wall animations. (all groundwork already done in Boom.)

- Strife's animated doors. (can be taken from ZDoom.)

- DECORATE lite (which can easily be based on ZDoom 2.0.63's parser and reduced to a feature set that is compatible with more basic engines.)

 

 

The most important thing has already been stated by kb1 in the first post:

 

"Start small"!

 

Considering that, this should really be contained things that actually help mappers, and preferably stuff where some implementation already exists. These complicated metadata things will fail for the sole reason that ports are different and thus have different needs to handle this stuff.

 

Nah, we're ok. I asked for ideas, after all. Most of them don't fit into a Phase 1-type standard, but it makes for a good reference for what we can do later.

 

But, let me ask this of everyone:

Please do not get caught up in details, and please try to submit simple ideas. It will be miraculous if we are able to define a bare-minimum enhanced standard, and it get picked up by the major ports! The new ideas are neat, but probably will need to be pushed back a bit, just to get the standard accepted, and live within the major ports. I do appreciate all the ideas and the interest. We will try to do our very best for this first rollout. Of course, we're going to be posting some rough drafts of the specs, before much actual implementation takes place.

 

@Gez Good ideas - they will all be discussed and considered (hopefully in that thread :)

Edited by kb1

Posted (edited)

Share this post


Link to post

I could post whole essays on this topic (and already did speak the half of one in IRC a bit ago) but there are some holes in the BOOM feature set itself that I think we could always go back in and try to plug. There were a number of things the BOOM team itself meant to do that got put off for "Phase 2" which as you know never happened. One of those things was adding more generalized linedef types, including for stuff such as lighting which was entirely neglected in the 2.02 standard. EE considers all linedef special numbers starting at 8192 to be reserved for use by the generalized linedef type system; I am curious how much "namespace" is still available between there and the max of 65535 and how it could be put to use, even if such use is somewhat redundant to the Hexen map format - the point of this is that old school mappers who still can't envision moving to Hexen format would get new toys to play with, and, adding support for such to a PrBoom-Plus fork would certainly be faster - a lower hanging fruit - than the Hexen map format (methinks it forgotten just how much work adding that into the base Doom code is, w/o obliterating Doom format support in the process particularly).

2 people like this

Share this post


Link to post

If an extended Boom feature set is developed, please consider making sane versions of the line scrollers. The ones Boom comes with are truly baffling, and all but useless in most situations. The line-vector scrollers are based on relative angle, so it's literally impossible to synchronize scrolling of different-angled lines, and the offset-based scroller can't be controlled via a tagged line, so it's impossible to use texture alignment with it.

2 people like this

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now