invictius Posted May 15, 2015 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? 0 Share this post Link to post
scifista42 Posted May 15, 2015 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. 0 Share this post Link to post
LogicDeLuxe Posted May 15, 2015 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. 0 Share this post Link to post
Maes Posted May 15, 2015 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. 0 Share this post Link to post
Memfis Posted May 15, 2015 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. 0 Share this post Link to post
Gez Posted May 15, 2015 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. 0 Share this post Link to post
fraggle Posted May 15, 2015 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. 0 Share this post Link to post
hex11 Posted May 15, 2015 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... 0 Share this post Link to post
DaniJ Posted May 15, 2015 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. 0 Share this post Link to post
DaniJ Posted May 15, 2015 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? 0 Share this post Link to post
Cynical Posted May 15, 2015 I'm fairly certain that when you consider various "ZDoom-isms" that this is just the halting problem, and therefore is impossible. 0 Share this post Link to post
kb1 Posted May 15, 2015 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. 0 Share this post Link to post
LogicDeLuxe Posted May 15, 2015 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) 0 Share this post Link to post
Marnetmar Posted May 16, 2015 Why not just take Esselfortium's idea about a map editor generating a metadata lump and have it include the map format? 0 Share this post Link to post
40oz Posted May 16, 2015 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. 0 Share this post Link to post
WadArchive Posted May 16, 2015 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 0 Share this post Link to post
VGamingJunkie Posted May 16, 2015 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. 0 Share this post Link to post
Bloodshedder Posted May 16, 2015 Is Bayesian inference possible in this application? 0 Share this post Link to post
Gez Posted May 16, 2015 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. 0 Share this post Link to post