Grazza

Press F5? No - as Andrey has stressed, all these optional features are without losing compatibility, since it is an absolute priority for this port. It is just a visual effect, interpolating as many frames as it can in between the "real" ones. The engine still calculates the positions and states of everything at 1/35 second intervals.

I imagine you're referring to this.

Philip "ultdoomer" Kiska has sent in a demo on that "amazing" wad N_Mariko. TAS UV Speed in 2:05. It's Doom2.exe format (recorded with prb+) and he used automated permanent strafe-50 (including during turns), slow-motion and joining.

In case anyone is trying unsuccessfully to download NDCP, this has been removed from the archive pending an official release. There's still bug-fixing going on. http://www.gamers.org/pub/idgames/REJECTS http://forums.newdoom.com/showthread.php?t=29513&page=3 Random other comments: Jägermörder 2 also works in Risen3D (tested OK all the way through without monsters, at least). ic2005 is great!

Belial: "Doom Marine" is the guy to contact about this, and I'm sure that if you give him a nice clear list of what the issues are, he'll be happy to amend them and rerelease. It might also be worth mentioning this to hawkwind (or hawkwind2 as he is known at Newdoom). He's a map/compatibility tester for Risen3D, which should also be able to play maps of this size (it handles dmdjm02 OK). However, there is an issue with the nodebuilding which is possibly solvable, but may require some changes in the map. I agree that if there is just one linedef that requires Boom compatibility, then it should be amended. This means you can dispense with the annoying "live monsters can be knocked off ledges" behaviour (very annoying in some Maxes), and also that it should work in jDoom (if/when the appropriate limits are extended). <font color=#ff0000>Edit:</font> There's also this issue mentioned by entryway (a texture with an empty name instead of '-') that is certainly worth fixing. entryway: So, -complevel 7 will only play back demos that have the same binary format as demos that were recorded with Boom. I had been presuming that it would also be able to play Doom2.exe format demos but apply Boom's "compatibility" behaviour to them (like the original Boom 2.02 did). OK then, so it is working correctly, but just not in such a wide range of situations as I had expected.

All the compet-n Max times for Ultimate Doom are under 5 minutes, so if there are any, they don't open up secrets or release monsters, and they are not necessary to exit the map. Edit: actually, the logic there isn't quite solid, are there are maps where the compet-n rules allow <100% for a valid Max. However, for Ultimate Doom at least all these appear to be due to other issues. Possibly it's a feature id had thought they might use but didn't find a use for, or decided against it. Does anyone know in which version this sector type first appeared, or if it was used in any of the alphas/betas?

tycp_08: You need to stop being so rude, stop making pointless bumps of old threads, and generally read what other people are saying to you more. Otherwise bad things will happen. Consider yourself warned.

The regular Prboom 2.2.6 always tries to play ic28uv.lmp with Doom2.exe compatibility (and it desyncs - this demo desyncs in Doom2.exe too). As I understand it, in 2.2.6, putting a complevel in the command line for demo playback has no effect. Prboom 2.02 plays ic28uv.lmp using the closest thing it has got to Doom2.exe compatibility - its "Doom compatibility" mode. This plays it back OK. My basic point is that if Prboom 2.02 can play back a demo, then Prboom-plus should also be able to play back that demo using either -complevel 7 or -complevel 9. That makes sense, doesn't it? I now notice that when using glboom icarus ic28uv.lmp -complevel 7 the demo doesn't even desync in the same way each time. Does this suggest that -complevel 7 is not being understood at all, and leading to the program getting some random data from somewhere? Edit (based on a bit more testing): It seems that if -complevel 7 is used when attempting to play back a Doom2.exe-format demo, the behaviour is to some extent random.

Does -complevel for playback only work for 2, 3, 4, 5 and 6? I was testing this with some demos that ought to play back with -complevel 7 ("boom compatibility" compatibility): the ones in icuvlmps.zip that are described as not playing back with Doom2.exe, but playing back with Boom 2.02 (ic22uv.lmp, ic25uv.lmp, ic27uv.lmp, ic28uv.lmp, ic31uv.lmp). They play back fine with Prboom 2.02. So logically, these demos should play back with -complevel 7: glboom icarus ic28uv.lmp -complevel 7 However, they don't. For instance, ic28uv.lmp desyncs at the start. The following appears in stdout.txt:G_DoPlayDemo: playing demo with "boom compatibility" compatibilitySo the program claims to be using the right compatibility mode. However, it clearly isn't. [And yes, I am aware that these demos play back with -complevel 5; my aim here is to test that the other -complevels are working correctly.]

Note the bit where Romero said about rounding the time off before adding 30 seconds. Presumably he rounded it down to the nearest quarter-minute. He also wasn't too clear in that interview about how the par times for Doom2 were arrived at. But if the same method had been used, Doom2 map01's par time would clearly have been 30 seconds.

Probably. Though some of the par times have been beaten in Max demos.

http://5years.doomworld.com/interviews/johnromero/page3.shtml He didn't mention a skill level:

It's funny, those political compass things tended to put me very close to Charles Kennedy. However, of the main British political leaders, he is the one with whom I've actually tended to agree with least.

I imagine the problem is that the save you're trying to load is for a different complevel.

It has been noticed, especially by those who try to record a demo on such a map and find it won't play back even with the exe that was used to record it. Fenris is an example of such a map. I've put an initial (desynching) test run I recorded here. Rebuilding the reject solved the problem - I could record as normal and the demo plays back with everything you would expect it to. There are quite a few other examples though. Most of the maps in the original Akce Korian, for instance. Prboom(+)'s current behaviour in such cases is to have the monsters unable to see or target the player. And prb+ displays its reject overflow message, if you have it enabled.

The changes in prb+ relating to (or that have an impact on) demo compatibility are described reasonably clearly in the changelog (and the code is commented - check for "e6y"), which should make them easier to track down. Here are the ones I am aware of that Eternity doesn't have:Emulation of Doom2.exe's behaviour if it is used to record on a map with Boom specials [2.2.6.22] Fix regarding MF_JUSTHIT behaviour (incompatibility introduced in MBF, and relevant to Hacx, where some demos desync without this fix - reasons not entirely clear, but presumably related to the dehacked patch) [2.2.6.22] Added dehacked support for Monsters infight (Monsters Infight = 221 means that monsters of the same type will infight whenever provoked) [2.2.6.23] spechits overflow detection and attemped emulation [2.2.6.22/24] REJECT overflow detection and emulation when possible [2.2.6.25] Complevels added for Dosdoom and Tasdoom (including code to unscramble the tasdoom demo format) [2.2.6.25] The ability to force a particular one of the vanilla complevels (Doom2, Ultimate Doom or Final Doom), rather than the engine choosing one based on the iwad in use [2.2.6.25] Compatibility option added to fix a bug in Boom's dehacked support in the processing of Max Health, so that it applies only to health potions [2.2.6.25]I'm pretty familiar with the demos for which these are relevant, so if you'd like some testing done if you apply any or all of these, just ask. The source code for all the relevant versions is available at sourceforge. Edit: Might as well list the stuff that addresses Prboom-specific issues too (just quoting from the changelog verbatim):[-] PRBoom issues: prboom uses monster_avoid_hazards setting from the cfg file when you are using -complevel 0 or -complevel 1. If you have this option set to 1 in your cfg, then you are at risk of getting desyncs in demos that feature crushers. (Dashiva) [2.2.6.11] [+] Added switch to force monster_avoid_hazards: -force_monster_avoid_hazards. It is meaningful for viewing doom-compatible demos recorded with "monster_avoid_hazards 1" in config (in cases of desyncs). [2.2.6.21] [-] PrBoom dehacked support: wrong processing of Bits parameter if its value is equal to zero. No more desync on HACX demos. [2.2.6.21]

No, you're not. You're meant to have the normal running speed. As far as I know, this issue only occurs in Zdoom and Zdoom-based ports. (I mentioned this issue both in the separate text-file and in the review.) It is due to the following appearing in the dehacked patch:Thing 1 (Player) Reaction time = 8 Pain chance = 100 Speed = 5In dehacked, the player's properties can't be changed in this way, so it should have no effect on the player's speed. However, Zdoom interprets this differently.

If it helps you track it down, Zdoom 2.0.96x is the same as GZdoom 0.9.22 in this respect. I recall the limit used to work in earlier Zdoom versions, but don't know exactly where it changed. However, it was always out by one (and this is again the case in 2.0.98): i.e. PEs would not produce a lost soul if there were already 20 or more in the map. The original behaviour was that they would not produce a lost soul if there were already more than 20 in the map. BTW, there are other maps where the limit is pretty important too. Some where it just gets silly if there is no limit, and, for instance, the start of HR map19 makes deliberate use of the limit for a little set piece.

Not in Singapore.

Normally, but I also tested in prboom.exe (and missed this, for the reason described). Also some things in wotdoom3 (water effects) don't currently look quite right with glboom.exe, which provides another reason why one might want to use software mode for this wad.

Oops, sorry for not catching that when I was testing wotdoom3 prior to uploading it. I just never sit through these intermission texts. I'll be aware of it in future though.

Ah yes, there's that one. The one I had in mind was Flames of Revenge though. The classic of the genre is surely the one in Equinox. It's gonna take something really special to top that.

Hobbs: note the new compat levels in the latest prb+ (2 for Doom2.exe, 3 for Ultimate Doom). And with the latest version, it actually has slightly better demo compatibility (see the changelog) with vanilla than Chocolate-Doom does (though I presume fraggle will add the relevant new code to chocdoom soon enough). Graf: If you use the cfgs provided with prb+, then these have all the MBF stuff turned off, so the "straight out of the box" settings are quite vanilla-like (not full demo compat, but close enough for most purposes). I'd prefer it if the engine defaults (i.e. what it chooses if it finds no cfg) were also the non-MBF options, but at least now unsuspecting users who just extract all the stuff from the zip and don't adjust the settings won't have the modified monster behaviour. BTW, talking of compat options, the lost soul limit seems to be gone in recent (G)Zdooms. (Doom2 map09 is the easiest place to test the behaviour: with the limit, on HMP they should be able to produce 3 lost souls before hitting the limit, and on UV they shouldn't be able to produce any until 13 lost souls have been killed.)

To assist you, here is a checklist of the tag problems that were still in "canfix": Linedefs with invalid tags (tag missing): map02: 1024, 1327 (two short ones either side of the blue key door) map05: 426, 429 (you will definitely have noticed these ones!) In map05, linedef 72 isn't tagged to anything (no sector has tag 11). If you did mean this to trigger a crusher somewhere, you'll need to give the relevant sector that tag.