PrBoom-Plus, ver. 2.5.1.4

[xepop]

Bug in save/loading routines:
Order of thinkers in thinkercap is not preserved. This leads to possible desyncs as rng depends on them being in correct order.

[fabian]

Afterglow said:

Is there a known issue with neighbouring sector sky heights differing? e.g, sector #1 is 256 and neighbour sector #2 is 384. Raised surfaces visible in sector #2 should be visible from sector #1.

Would you mind telling us which map this is?

[entryway]

xepop said:

Bug in save/loading routines:
Order of thinkers in thinkercap is not preserved. This leads to possible desyncs as rng depends on them being in correct order.

Patch?

[Memfis]

Afterglow, the "see through sky" trick needs a little workaround when you use different brightness levels in the area. I can't say that I fully understand how it works but here is an example of how it can be fixed in some situations. (left area: bugged, right area: fixed)

[Rez]

xepop said:

Bug in save/loading routines:
Order of thinkers in thinkercap is not preserved. This leads to possible desyncs as rng depends on them being in correct order.

Is this an old bug, maybe inherited from BOOM code? Cuz there's a bug way back there that sometimes causes an unsave:

save game
reload
what loads proves to be the previous save, not the one you just made (which is nowhere to be seen)

Also, occasionally a very large DSG will become a partly-blank file which naturally does not work.

Anyway, could your bug the the cause of these as well?

[xepop]

entryway said:

Patch?

I don't have a proper solution yet. Currently my workaround of reordering thinkercap in the end of P_UnArchiveSpecials segfaults on some tics when loading.

Rez said:

Anyway, could your bug the the cause of these as well?

I don't know enough of doom's inner workings to say. I just hack it until it works for my needs.

[Afterglow]

fabian said:

Would you mind telling us which map this is?

An unreleased map of mine. I noticed the same bug in another map in the set. I'll try to cut out a section to put a demo together for you before today is through.

[TimeOfDeath]

Afterglow said:

An unreleased map of mine. I noticed the same bug in another map in the set. I'll try to cut out a section to put a demo together for you before today is through.

Unfortunately it's not a bug, like Memphis said that's how doom.exe handles adjacent skies with different brightnesses + ceiling heights. In your map, you could make the stair sectors 384 ceiling and put triangle sectors along the left walls at 256 height.

[noshutdown]

hello andrey, prboom+ is by far my favorite sourceport, and i would express my thanks to you and others guyz working on the project for your efforts.

i have an idea on an automap feature although i wonder if its been suggested by others in the past years: since glboom+ has textured automap, why not replace all triangle "things"(in iddt cheat mode) on the map with corresponding sprites and make it look like a top-down shooting game?

this may be quite some work, so maybe you can divide it into a few incremental stages:
stage 1: monsters, pickup items and doomguy have standing sprites without facing directions.
stage 2: corpses, decorations, projectiles and explosions have sprites, just like this map on compete-n.
stage 3: monsters and doomguy have standing sprites with facing directions.
stage 4: monsters and doomguy have animated sprites.

do you think this idea worth working on?

[entryway]

noshutdown said:

why not replace all triangle "things"

Do you know about 'icons' mode? It uses separate icons for ammo, armor, health, keys, powerups, weapon, monsters, map marks, probably something else.

[Memfis]

:o
Is that a remake of Icarus in progress? :)

[Doom_user]

I recently noticed that translucency effects for things like BFG attacks and Imp fireballs get disabled if you use one of the vanilla comp levels. Since these effects are visual only and don't affect demo compatibility, perhaps an option could be added to allow them even when using a vanilla comp level.

[Memfis]

It looks like jump in PrBoom-Plus is 8 units higher than in ZDoom. Is this a mistake?

[Linguica]

It's not like there is a canonical jump height...

[Memfis]

True, but if that feature was added for compatibility with jumping wads, it's better not to allow jumping higher than was intended imo. Check out MAP02 of Daniel Level Serie 01 for a good example. In PrBoom-Plus you can immediately jump on to the central platform and get the red key. In ZDoom you need to search for a switch that raises a bridge to the platform first (ok, with a tricky strafejump you can avoid that but clearly that was not intended by the author).

Also it would be cool if there was some way to record with jumping enabled...

[Never_Again]

There is: use Zdoom.

[Memfis]

Why not Legacy then?

[Rez]

Never_Again said:

There is: use Zdoom.

<*ick*>

Why not make max jump height configurable?

[fabian]

The jumping feature has been taken from Hexen, where "jumping" sets vertical momentum to 9 fracunits. I don't think it makes any sense to port the code over in pristine and then change this one value only.

I remember we had this discussion before, maybe in the Crispy Doom thread. I think the consensus was that jumping is considered as cheating anyway, like a one-time IDCLIP, and is only supposed to get you out of a stuck situation. As such, it doesn't make sense to restrict its height to a different arbitrary value.

There is another jumping code path , though, that can be found in Strife. Instead of the jumping code in Hexen, which sets vertical momentum to 9 fracunits, it merely adds 8 fracunits (and has a different check for allowing the next jump). So, standing jump in Strife is less high. My initial patch implemented both code paths and a switch to choose between them, but Andrey eventually removed the Strife path.

Edit: Regarding demo recording, enabling jumping also allows for some in-air movement control that you normally do not have. So, having this feature enabled without actually jumping even once will already cause demos to desync.

[Rez]

Why is that? Cuz jumping doesn't cause desync in its great-uncle Fusion, far as I've noticed.

[fabian]

Most probably because Fusion introduced its own demo format which was incompatible to anything else.

Edit: Right there in G_GAME.C.

static void G_WriteDemoTiccmd(ticcmd_t* cmd)
{
  [...]
  if (demo_version > 203)
    demo_p[4] = cmd->buttons2; // Hakx 8/23/1999 Extended buttons support
  [...]
}

[Rez]

fabian said:

Most probably because Fusion introduced its own demo format which was incompatible to anything else.

Speaking as one of the Fusion team -- feel free to steal it, or anything else. We don't mind. :)

[noshutdown]

entryway said:

Do you know about 'icons' mode? It uses separate icons for ammo, armor, health, keys, powerups, weapon, monsters, map marks, probably something else.

no... i havn't played the 2.5.1.4test version yet, i am still playing previous 2.5.1.3.

[Xaser]

fabian said:

The jumping feature has been taken from Hexen, where "jumping" sets vertical momentum to 9 fracunits. I don't think it makes any sense to port the code over in pristine and then change this one value only.

ZDoom seems to operate on the same scale, judging from the native DECORATE code ("Player.JumpZ" in Hexen's player def is 9; all others including Strife use 8). If the issue was the other way around (jump height good in PrBoom, bad in ZDoom), it'd be easily moddable to match, but alas...

[fabian]

Xaser said:

jump height good in PrBoom, bad in ZDoom

define "good" and "bad"...

Anyway, I don't insist on jumping momentum being 9 fracunits, and I don't think Andrey does, either. If all other source ports supporting jumping have agreed that 8 fracunits is right, then maybe we should adjust that value in PrBoom+ as well (and Crispy doom, FWIW).

Andrey, you should really consider to release to current code snapshot as 2.5.1.4, please. People are still using 2.5.1.3 and there are around 300 SVN commits between this and now.

[dew]

Damn! Generalized door action with "keycard and skullkey are the same" seems screwed up and opens with just red+blue in MBF compatability (complevel 11). Here it's action 15311, but door speed, repeatability and closing the door again don't matter and it affects all those variants. It does not happen at complevel 9! I can't tell you if this happens in vanilla MBF though.

edit: Jesus christ, this shit is actually on the wiki. Never mind. :/ I'm gonna go vomit on a puppy.

[noshutdown]

i wanna know when will the 2.5.1.4test version become an "official" release? and how many new bugs found in recent test versions?
are known demo desyncs being worked on?

[TimeOfDeath]

What known demo desyncs?

[noshutdown]

TimeOfDeath said:

What known demo desyncs?

one reported here:
http://sourceforge.net/p/prboom-plus/bugs/240/
but yeah, such cases have become pretty rare in recent years.

[Linguica]

I think it's high time to polish up the current codebase and release 2.6, if only for the wigglefix (which is really essential for playing software mode in high resolution).