Program to tell what ports a wad is compatible with?

[invictius]

A lot of wads these days come without a text file (ones from here on mediafire, from zdaemon servers, etc) and it's difficult to remember which ports support full acs, hexen maps, have full Boom support, etc. Is there such a thing as a program I can point to a wad and get a summary of which ports will work fine?

[scifista42]

Nothing I know of, but I'm pretty sure that there is no program to detect mandatory jumping or crouching, or to detect linedefs with a special action placed right in front of press-use-activated linedefs, which prevents them from being pressed in Boom and lower ports / vanilla.

[LogicDeLuxe]

I guess, a program could scan for certain resources and list possible ports. But it could never tell exactly, since you never know which glitch of a certain port and/or version it might be relying on. It couldn't tell if it is for single/deathmatch/coop either, since starts are there in most maps anyway.

The upload template is there for a reason, and really should be part of every upload anywhere. An older version is even part of the Official Doom FAQ.

[Maes]

At most it could signal some obvious giveaways (e.g. the existence of port-specific lumps such as DECORATE, ACS, BEX, LEAFS, GL Nodes etc.) and maybe infer a bit from the size and linedefs/tags used in the levels themselve, but there would be too much room for error and overlap.

Something with no obvious "advanced" lumps and which looks totally vanilla could be playable on nothing but the lates GZDoom for reason XYZ, while a totally fucked up, weird-lumps-laden PWAD with levels containing gross errors and unknown objects might be 100% vanilla compatible.

[Memfis]

LogicDeLuxe said:

The upload template is there for a reason, and really should be part of every upload anywhere.

It's too damn long. Hard to overcome laziness and fill it.

[Gez]

invictius said:

A lot of wads these days come without a text file (ones from here on mediafire, from zdaemon servers, etc) and it's difficult to remember which ports support full acs, hexen maps, have full Boom support, etc. Is there such a thing as a program I can point to a wad and get a summary of which ports will work fine?

Well, you could have some heuristics, but none of them are fool-proof.

Suppose you look for DECORATE lumps, and if you find one you mark the wad as "requiring ZDoom, GZDoom, or Zandronum". It'd make sense, right? Now, look at Valiant; it has a DECORATE lump and it runs just fine in PrBoom+. And now, look at the Vaporware demo: it has a DECORATE lump and it doesn't run on ZDoom or derivative at all! The DECORATE lump is a dummy to get Doom Builder 2 to add the custom monsters to its actor palette, but they have no real coding, it only works fine in Eternity!

The other problem is that ports evolve constantly. They could get new features, they could suddenly become compatible with features from other ports, etc.

[fraggle]

Maes said:

At most it could signal some obvious giveaways (e.g. the existence of port-specific lumps such as DECORATE, ACS, BEX, LEAFS, GL Nodes etc.)

However, the lumps to check for should be carefully chosen. For example, some of Freedoom's levels include compiled GL nodes just because people built their levels using a node builder that generated them. Similarly, FreeDM is Vanilla-compatible, but includes both DEHACKED and MAPINFO lumps that provide optional enhancements.

[hex11]

Memfis said:

It's too damn long. Hard to overcome laziness and fill it.

But it only takes like 30 seconds, compared to hours for making a map...

[DaniJ]

While I do understand the benefit of such a program from a user perspective, the practicalities of A) writing it and, B) maintaining it in the future, pretty much prevent it from being all that useful.

As pointed out, the only way to deduce which sourceports will support a given mod is to perform heuristic analyses of the mod data and then match it against a set of data patterns for each sourceport. Problem is that most active sourceports are under continual development and consequently, maintaining these patterns for such a tool would practically require sourceport authors to do so themselves.

Although such a tool is not beyond the realms of possibility it doesn't seem all that feasible/practical, to me at least.

[DaniJ]

I decided to spend a few minutes thinking about whether such a tool could actually be produced and how to ensure it remains useful in the long term.

Obviously there are many variables here. From technical concerns such as the platforms supported by a given sourceport, the language(s) they are implemented in, the types of data that must be tested... the list goes on and on.

It occurs to me that the only practical method of developing a tool according to the original premise is to divide the work up into more manageable pieces.

The proper high-level architecture these requirements seem to suggest is that of a Test framework, and a Test driven development model.

The final tool should be a framework that runs a series of "conformance" tests on the supplied data. Each test should be a largely independent application/script which checks a much simpler condition, such as "Does WAD contain DECORATE?". More complex tests can be built by combining lower-level tests to build up to a more high-level understanding of a mod's contents.

With such an architecture in place it then becomes feasible to divide up the work while also providing a "centralized" and standardized means of conformance testing of mod support.

Each sourceport's development team can then be responsible for their own conformance tests. This not only provides the user with useful metrics, it provides the sourceport authors with a concrete set of regression tests.

Thoughts?

[Cynical]

I'm fairly certain that when you consider various "ZDoom-isms" that this is just the halting problem, and therefore is impossible.

[kb1]

I spend some significant time trying to make such a tool. The best approach I could come up with was a set of confidence levels. As ports become more and more complex, they start to support conflicting features (linedef types, for one). Also, newer ports strive to be able to play maps designed for other ports.

Because of this, tests are rarely definitive in isolation. So I created a set of confidence levels, and a feature grid:

The grid has ports, by version, vertically, and horizontally, features are listed:

(Features)
Extra player starts/DM starts
Non-MIDI music
Hexen format maps
Doom format maps
3d architexture
swimmable water
Boom/MBF linedefs
DECORATE
etc, etc.

Then you test for a slew of features present in the WAD and in the maps. Finally, you test those feautes against known support in the ports, and you calculate a confidence level that that port can handle the maps. Each feature has a certain weight assoicated with it. For example, Vanilla will never handle a Hexen-formatted map, but it can survive having non-MIDI music prsent in the WAD.

Since vanilla cannot handle a Hexen map, the presence of such a map seriously affects the confidence level for Vanilla, but the non-MIDI music only reduces confidence by a small amount.

Those weights require careful balancing and tweaking. So you end up with an educated guess. Stated differently, the confidence level describes how confident the computer is, that this map/wad can be played in Port X. And, if you're really cool, your program lists the reasoning behind the confidence level.

[LogicDeLuxe]

Also worth analyzing:
PNG textures
3D models
voxels
maps in text format
demo lump version
endoom and endboom screen
dehacked in bex format
ddf
deutex signature (most likely a 90's wad)
multiple player starts (most likely a voodoo doll script, but can be a vanilla effect too)
are there nodes lumps?
are there glnodes lumps?
sounds not in voc format and/or other than 8bit mono
map names other than ExMx or MAPxx.
medusa textures
transparent flats
non vanilla flat sizes
self referencing sectors (most likely designed for software renderer)

[Marnetmar]

Why not just take Esselfortium's idea about a map editor generating a metadata lump and have it include the map format?

[40oz]

Am I misunderstanding something, or would it not be easier to instead check for certain things that are not compatible with certain source ports, and indicate what source ports definitely wouldn't work under such circumstances, and then return what source ports didn't fail the tests to the player? I'm no programmer, which might be obvious by this post, but from what I've read, it seems like a backwards and in turn, a very strenuous way to test everything a source port is capable of. E.g., zdoom will just about run anything without crashing, so id imagine in my scenario, the parameters for that would be very short.

[WadArchive]

For Wad Archive I use the java library https://github.com/BlackRookSoftware/Doom that has some functions to guess which port a wad would work with. It isn't 100% accurate but combining it with parsing the associated read me and a few other things improves the guess

[VGamingJunkie]

The only thing I can think of is to gut the engines of all source ports into the program and have it try to run with all of them, making a note of which ones crash. Not exactly the most efficient method, of course.

[Bloodshedder]

Is Bayesian inference possible in this application?

[Gez]

LogicDeLuxe said:

sounds not in voc format and/or other than 8bit mono

The VOC format is different from the Doom sound format. :)

Marnetmar said:

Why not just take Esselfortium's idea about a map editor generating a metadata lump and have it include the map format?

I don't see how it'd help for this purpose. Any analysis and "reasoning" the map editor could do to generate the metadata can also be done by the "map oracle" program.

I suppose the map editor could store in that metadata the name of the config that was last used to edit maps (should probably make one config entry per map, rather than for the whole file). That could help a bit but wouldn't necessarily be foolproof either.

MetroidJunkie said:

The only thing I can think of is to gut the engines of all source ports into the program and have it try to run with all of them, making a note of which ones crash. Not exactly the most efficient method, of course.

Many things don't provoke a crash at load-time. Suppose you have a level with unknown sector types: vanilla will only crash when the player enters these sectors. As long as the player stays out, no crash. Unknown line types are entirely ignored, so they won't crash either.