PrBoom-Plus, ver. 2.5.1.4

Maybe someone familiar with prboom's source can make you a fork? But there's no way imo that an option like that will be added.

Nah. It was me just venting about how absurd random damage spread really is and always has been.

I want to be able to entirely mathematically determine how many shots it will take to kill enemies, or how much damage a shot will do so I can easily determine whether or not I want to dodge attacks. You can almost do that now, but the stupid mechanic gets in the way and it's exacerbated during a tyson segment.

If you changed the rules of the PRNG table, it would no longer be a valid tyson run.

I agree that the damage spread for a berserk punch is pretty silly. 20 to 200? It can take anywhere from 1 to 4 punches to kill a demon??

Edward850 said:

If you changed the rules of the PRNG table, it would no longer be a valid tyson run.

I know, and I wasn't talking about a Tyson run. I was simply using a tyson segment as an example of how dumb the mechanic is.

2 fist a caco but died and had to restart the demo

2nd attempt: Everything is going as optimally as it can until RNG decides to make the caco require 6 fists to kill and make him do his most possible damage. Run is ruined because the game randomly decided so. GG.

Eh. You seem to be the only person who has ever complained (aside from Zandronum users, strangely enough, but that hardly counts). Nobody has complained about it with deathmatch duels at least, and considering how that likes to shake up player spawns...

While the berserk has a strangely dramatic range of damage, I was under the impression that most runners could reasonably manipulate the vanilla PRNG table by now?

Edward850 said:

While the berserk has a strangely dramatic range of damage, I was under the impression that most runners could reasonably manipulate the vanilla PRNG table by now?

Heh. Maybe TASers, but manipulating prng in a legit run? Very unlikely. I will say that I find the zerk randomness strangely charming, despite its tendency to screw you over with bad luck. When the RNG gods finally bestow their blessing on you, it feels so sweet... to fuck it up with something unrelated and restart once again.

Fuck berserk. Placing it to maps should be a bannable offense. I can't think of many things as irritating as serious optimisation effort on berserk maps.

Linguica said:

I agree that the damage spread for a berserk punch is pretty silly. 20 to 200? It can take anywhere from 1 to 4 punches to kill a demon??

In the "rare kills" demo thread there is a demo where it takes 7 punches to kill a demon, followed by a demo where I kill six spectres in 7 punches.

By the way, is this considered polite behavior? A guy asks how to remove randomness, gets a bunch of nerds explaining why he shouldn't do it instead. Thanks?
(and yes, I behaved like that myself)

In other rare kills, according to George Whasisface's stats, the odds of killing a revenant with a single SSG blast are 1 in 5 million.

I've managed this feat five times in 20 years. (I'd have one in a demo, but an early alpha of BOOM ate it.) I take this to mean that I've killed 25 million hellspawn (which sounds about right :P )

Anyway, I personally like the damage randomness. I could see having it switchable for our exceedingly rare folks, and set to enabled-only for demos, but how long would it be before someone came up with a cheat?

What might be interesting, tho, are high-medium-low settings... personally I would like to have more-random monster movement.

Rez said:

personally I would like to have more-random monster movement.

Yes, sometimes that x-y axis logic of following the player is too apparent, especially in big open spaces. You can kite the enemies to get hit by projectiles.

Memfis said:

By the way, is this considered polite behavior? A guy asks how to remove randomness, gets a bunch of nerds explaining why he shouldn't do it instead.

I don't see anything impolite in the replies but I'd like to point out that TM's question would have been perfectly fine in another thread, not in one dedicated to a classic port.

To me, impolite is dropping posts all over the place and never acknowledging the replies. Guess who I am talking about.

VGA said:

Yes, sometimes that x-y axis logic of following the player is too apparent, especially in big open spaces. You can kite the enemies to get hit by projectiles.

Where it bugs me is typically indoors, where every bloody time I play a given map, when some monsters first wake up they always go the same direction, even when they have room to go elsewhere -- why can't they go some other direction for a change??

Rez said:

Where it bugs me is typically indoors, where every bloody time I play a given map, when some monsters first wake up they always go the same direction, even when they have room to go elsewhere -- why can't they go some other direction for a change??

Don't the enemies try to go for the player in a straight line regardless of obstacles? If I understand correctly there is no pathfinding.

VGA said:

Don't the enemies try to go for the player in a straight line regardless of obstacles? If I understand correctly there is no pathfinding.

It might be that they can only go one direction when first they wake up? Dunno, can't think of examples offhand.

I went through and transcribed the enemy movement logic into pseudocode:

=====

for all the below unless otherwise noted, when the enemy tries to move, it will refuse to do so if the movement would result in turning a 180 from the direction it was previously moving.

until i say otherwise, only consider a direction if the player is at least 10 units away in the cardinal component of that direction. so for instance, if a player is less than 10 units east or west of the enemy, the enemy won't try and move any direction with an easterly or westerly component. (this can also be thought of as meaning that if an enemy is almost exactly aligned with the player on a cardinal axis, it will first only attempt to move along that cardinal axis.)

first, if the enemy is willing to consider it, try to move in an ordinal direction towards player (i.e., southwest, southeast, etc)

if that didn't work:

if the player is almost directly along the same axis as the enemy, try moving on that axis towards them.

otherwise, if the player is primarily north/south of the enemy, try moving directly north/south towards the player

otherwise, if the player is primarily east/west of the enemy, try moving directly east/west towards the player 4/5 of the time. 1/5 of the time, try moving north/south anyways.

if that doesn't work:

try moving the other cardinal direction towards the player instead.

if that doesn't work, finally lift the 10-unit-minimum restriction and:

try moving the old direction you were before.

if that doesn't work:

start by pointing east-southeast, and then randomly go around either clockwise or counterclockwise, and try to move towards each of the 8 compass points in turn until you succeed with one (except for the direction that would make you turn a 180, of course)

if that STILL doesn't work:

finally try turning a 180 and moving that way.

and finally, if all else fails:

give up and sit there.

=====

so from this you can see why http://doomwiki.org/wiki/Monsters_fleeing happens sometimes-- if you're in a narrow corridor along one of the compass points, once the monster starts running away from you, it will never be able to turn around because the game refuses to let monsters do a 180 as long as there's any other possible option. and the monster can always keep running further away until it hits a far wall.

Ah. I'll bet that explains the "always move the same way" thing with monsters that have just woke up, and why it's mostly indoors -- fewer directions to go.

Is there a known stability issue with the 2.5.1.4 test versions? I've tried the older test version released in December and now the latest version updated January 31st, and in both I'm virtually guaranteed a crash within 20 minutes of playing. The game either crashes with an "Exiting on signal: signal 11" message or just bombs out completely with the generic Windows error dialog. This crash doesn't show any relation to the WADs I have loaded (has occurred in Going Down, Resurgence, and Valiant) nor if I'm even playing as I've encountered a crash just seconds into Doom 2's beginning MAP11 demo. This also means the crash is not reliably reproducible as I've let the MAP11 demo run through many times since without issue.

I reverted back to 2.5.1.3 and haven't encountered a single crash since then. Of course, now I'm missing the new fixes and so forth.

Here's the log in an instance that ended with the signal 11 crash:
https://drive.google.com/file/d/0B4X6_GM5D7D_a2QwUzRaaDdiV0U/view?usp=sharing

And two logs that ended with the Windows error crash, although they don't show much:
https://drive.google.com/file/d/0B4X6_GM5D7D_ak9iX1RBcVdSZzg/view?usp=sharing
https://drive.google.com/file/d/0B4X6_GM5D7D_bjU1NE03SXJhMDQ/view?usp=sharing

I'm running Windows 7 Pro 64-bit. Not sure of the rest of my specs would be helpful.

I'm getting a very strange graphical error in the latest 2.5.1.4 beta: http://www.doomworld.com/vb/post/1343045

It doesn't seem to happen in 2.5.1.3.

Linguica said:

I'm getting a very strange graphical error in the latest 2.5.1.4 beta: http://www.doomworld.com/vb/post/1343045

It doesn't seem to happen in 2.5.1.3.

This happens because of R_FixWiggle

Changing the first value of scale_values[] array from {2048 * FRACUNIT, 12} to {512 * FRACUNIT, 12} fixes the issue

Sector height is only 144 there.

int32 overflow at sprtopscreen calculation, because of too high spryscale, because of too high max_rwscale, because of wiggle fix

This patch fixes the issue
http://pastebin.com/4FXJpnLM

Is it ok?

Revenant100 said:

Is there a known stability issue with the 2.5.1.4 test versions

I'll try to play in software mode. Never use it, so probably it's unstable.

entryway said:

int32 overflow at sprtopscreen calculation, because of too high spryscale, because of too high max_rwscale, because of wiggle fix

This patch fixes the issue
http://pastebin.com/4FXJpnLM

Is it ok?

Once the patch is applied, r_things.h needs to be updated to match r_things.c (from "extern fixed_t sprtopscreen;" to "extern int_64_t sprtopscreen;"), then it compiles and the problem seems to be fixed! I'm keeping my fingers crossed. :)

entryway said:

int32 overflow at sprtopscreen calculation, because of too high spryscale, because of too high max_rwscale, because of wiggle fix

This patch fixes the issue
http://pastebin.com/4FXJpnLM

Is it ok?

Should not be possible to overflow. I haven't done any testing yet, but, if it was wrong, it should have been causing problems all along. Are you sure some other change is not affecting those values? Long wall fix, maybe? Going 64 bit everywhere might make it go away, but I am not yet convinced that it is necessary.

kb1 said:

Should not be possible to overflow. I haven't done any testing yet

http://pastebin.com/bVQGcuui

How did we mess that up? We checked every possible scenario, I thought. I see your numbers, but I can't get my head around the issue yet. I'll do some testing this weekend. This is very frustrating!

How do I get rid of the sprite filtering completely? It makes the enemies seem blurry. Also, why does the zombieman's foot clip through the steps? The image is taken in glboom-plus, I have neither of these two issues in software mode.

VGA said:

How do I get rid of the sprite filtering completely? It makes the enemies seem blurry.

Spritre Filter Mode NONE in settings or gl_sprite_filter 0 in cfg

Ah, ok, thanks. but then what do the other filtering options do in that previous page? (point/linear/rounded) Confusing.

EDIT: Also, how do I disable that demo autorunning each time and RAAAAAAAAGING in the background while I'm trying to check out the options?

Feature request: choose complevel in the prboom-plus launcher

When you play many different maps, I think it would be faster to choose complevel from the launcher instead of changing the cfg file or a bat file.