Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
entryway

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

kb1 said:

But, why all the hatred for this setting? (Just curious).

One really annoying side effect of being able to push monsters over the side is than in recording UV-max demos, knocking a monster off of a ledge into a pit can really cost you in time or even make it impossible to get 100% kills. On some maps with a lot of enemies and infighting (Sunder MAP05 comes to mind) it's possible for one enemy to knock another off a ledge without killing it, and then your run is over just because you got unlucky.

Share this post


Link to post
scifista42 said:

"Stuck in mid-air" of course means "stuck on the edge of a ledge", or "stuck on a sufficiently steep staircase", etc. Imagine that you view the map from top-down perspective, and see the monster's collision box as a square. From all points inside this square, pick the point with the highest floor height, and then pick the point with the lowest floor height. If the height difference between them is greater than 24 units, and the monster can't move out of such a position* within a single call of A_Chase, the monster becomes stuck.

*So that in the new position, the height difference between the lowest and highest floor under the monster's collision area would be lesser or equal to 24.

But then the torque code applies, but maybe just for corpses.

plums said:

One really annoying side effect of being able to push monsters over the side is than in recording UV-max demos, knocking a monster off of a ledge into a pit can really cost you in time or even make it impossible to get 100% kills. On some maps with a lot of enemies and infighting (Sunder MAP05 comes to mind) it's possible for one enemy to knock another off a ledge without killing it, and then your run is over just because you got unlucky.

Now that does make perfect sense. It's neat to see it happen, as it adds some variant, pseudo-realistic behavior, but yeah, that's a show-stopper.

Share this post


Link to post

Is something wrong with GLBoom+? Everything is good in GLBoom 2.5.0.
PrBoom+ 2.5.1.5 (SihR2.wad MAP14):

Spoiler


GLBoom+ 2.5.1.5, 2.5.1.4, 2.5.1.3 (same):
Spoiler


Share this post


Link to post

I see it appears in the changelog as an addition for 2514, but I wonder why it was added. Would that form of sr50 be detectable when looking through demo data? How would you do that sr50 in vanilla in both directions (setting a turn direction and 'strafe on' to the same key means you still have to drag the mouse for the other direction)?

Share this post


Link to post

ooh right, so that was it! heh, less than a year ago and I completely forgot about that somehow -.-, post-patch it didn't register that I could stop with the turning component

Share this post


Link to post

Chex Quest desyncs (I think?):

IWAD: chex.wad
MD5: 25485721882b050afa96a56e5758dd52
DEH: chex.deh
MD5: 7bfff72473ec527b684622d8f87688bd
DEMO: demo1

I compiled with debugging enabled but, that shouldn't matter right? Doom 2's demos playback OK.

Share this post


Link to post

This demo probably desyncs in Chocolate Doom 2.2.1 too. So I don't think that this is PrBoom-Plus problem.

Share this post


Link to post
38_ViTa_38 said:

This demo probably desyncs in Chocolate Doom 2.2.1 too. So I don't think that this is PrBoom-Plus problem.

That's entirely beside the point though?

Share this post


Link to post

It plays back OK in Odamex, as far as I can tell. D2K does it OK too.

EDIT:

Nevermind, I'm a damn idiot. D2K desyncs later, and Odamex even later.

EDIT (again):

Hmm, I wonder if my WADs are bad; Odamex desyncs on all 3 demos. I might be an even bigger idiot, let me mess around.

EDIT (final):

OK I was using a... bad version of Chex Quest? The good MD5 is 4433fc2dee1dd6ddc21a69df5efbb0b9. No desyncs on demo1 anymore, probably the other ones are alright too. Sorry for the confusion :)

Share this post


Link to post

I just tried the newest version of 2.5.1.5 and I noticed some problems with the -viddump feature which weren't there before if I remember correctly. I think this is related to the switch to the new SDL version.

trying to record in windowed mode in a resolution higher than the desktop one results in a video with the correct resolution but the actual picture content has the size of the resized application window.

and if one records in fullscreen and tab out of prboom to do some other things, the last rendered frame before tabbing out will be repeated for the rest of the dumped video.

btw.. is there a history archive for all the different buids? on the changelog page you can only find a download to the most recent version and on sourceforge are only stable builds.

Share this post


Link to post

Now I remember.

How far along is it with its goal? How many people use it?

Don't some of you guys think this goal is insane?

Share this post


Link to post
Sp00kyFox said:

and if one records in fullscreen and tab out of prboom to do some other things, the last rendered frame before tabbing out will be repeated for the rest of the dumped video.

It has been like this for a while. Happens only in OpenGL from what I understand.

Share this post


Link to post
Danfun64 said:

Now I remember.

How far along is it with its goal? How many people use it?

Don't some of you guys think this goal is insane?

Well, if I'm getting this right, he wants to externalize the entire game logic, like in the later id engines?

I think it's an interesting idea, because it would mean that a feature-rich source port could finally coexist with an "emulator" source port under a single framework without dragging each other down. You could make any module you want, and it wouldn't affect other modules. I don't know about insane, but it seems to be a very ambitious undertaking that would require a lot of devotion.

Share this post


Link to post

If it does end up succeeding, I hope it doesn't take the Quake 2/Quake 4/Doom 3 "compiled into dll instead of scripting language or virtual machine" approach.

Share this post


Link to post
kuchitsu said:

It has been like this for a while. Happens only in OpenGL from what I understand.

I was using the glboom executable but with the software renderer.

Share this post


Link to post

POTENTIAL DEMO DESYNC ERROR in PrBoom+

See the code in p_floor.c in MBF:
https://github.com/fragglet/mbf/blob/master/p_floor.c#L129

The most important part is this:

if (demo_version < 203 || comp[comp_floors]) // killough 10/98
Demo_version, or an equivalent of it, is not checked in the PrBoom+ equivalent source location:
              if (comp[comp_floors]) {
This means that (-complevel <= 9) demos will be wrong if they don't have comp[comp_floors] set! An example is Vanguard D2ALL demo, MAP11.

Share this post


Link to post




If you start a new game, and then start another new game while the first level is buffering and then do it again and then choose the menu while the second new game is buffering then the menu will be HOM-like or you'll be under the floor, unless you exit the menu. You have do some special timing for this.

Share this post


Link to post
rdwpa said:

Is there a way to simply remove a particular keybind in prBoom+, without going into the config file? Not change, remove.

The closest I've found is changing the pertinent key_<command> line in prboom-plus.cfg/glboom-plus.cfg to 0x0. This results in the key being assigned to JUNK in the key setup menu.

I don't think there's a way without editing the config.

Share this post


Link to post

Is there a way to have ammo information organized sort-of like this with the alternative hud?

I am toying with the idea of playing with it but when you are running between rockets and would like to avoid wasting ammo boxes you could take later, having all the data at a glance would be useful imho.

Share this post


Link to post

I don't think so. The closest is that you pay attention to the weapon number colours, which give you at least some indication of available ammo. Not ideal.

I actually was just playing around with making custom HUDs in PrBoom+ and was disappointed about the lack of a counter for all ammo.

Share this post


Link to post

Thought so. Well, it's not that important as I still like the original HUD. Thanks!

Share this post


Link to post

How to make a bat file for watching demos that will create stdout.txt? I tried

C:\Andrey\dm\prb-plus\prboom-plus -width 320 -height 200 -fullscreen > stdout.txt -playdemo %1

but no luck.
Why do I even need to do this? In 2.5.1.4 prboom-plus would always create stdout.txt without me telling it to do so...

Share this post


Link to post

Did you get that working Memfis? If not try

C:\Andrey\dm\prb-plus\prboom-plus -width 320 -height 200 -fullscreen -playdemo %1 > stdout.txt 
The redirect should always be at the end.

Anyhow, I posted another thread about midi data resetting but on further investigation it seems that PrBoom+ is the only port I have that doesn't reset midi info on new music, and only with PortMIDI. This would be great if it could get fixed.

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
×