ChebSkies: Extermination Day perfected and maxable, works with BDv22test3

[chebmaster]

Yet ANOTHER detour.

What part of hell is unnaturally indestructible...?

Trees. The dry trees.

While that could have been overlooked if they were simply decorations, they are so everywhere they create perfect cover where there should be none. Most notorious case is the end-map cyberdemon in map 26. Caged helplessly between two rows of invulnerable trees his missiles could not penetrate.

That won't be the case when I finally finish with this update.

 

So I went to make a small fix...

Remember some of you compared me to a relentless machine...? Well, I'm sorry to disappoint you but I am *nothing* next to Sergeant Mark IV.

Three trees. Three simple unassuming plants, and they sucked up so much of my energy. There was coding, and debugging, and retouching the sprites and wall-banging why doesn't this fraggin shit work and more coding.

Now compare that to the enormity that is Brutal Doom.

Yeah.

 

Well, their burning looks a bit unnatural, but it is lightweight performance-wise, they catch fire with some probability (about 20%) if hit by fire or plasma, they burn much faster if you keep flaming them, they could be destroyed by other means while they are still burning or after they had burned out into carbonized husks.

 

 

Edited June 7, 2024 by chebmaster
moar screenshots

[chebmaster]

Done June 07, 2024:
    - general: this is an emergency bugfix update
    - map 242: fixed not being passable with high probability on difficulties below Ultra Violence: when the red key was deployed, the script swapping the blue and yellow keys failed due to the blue key teleport destination only existing on Ultra Violence

[chebmaster]

After... Creating another monstrosity... (a stronger spider mastermind armed with Unmaker and BFG9000 instead of his measly heavy machinegun) I finally made effort to look into the code of BD 22...

 

And then I realized there is an isurmountable gap in performance between BD 21 and BD 22. Because as I started testing a monster-heavy map, my FPS dropped into 30s.

Ran that with BD 22, which I dislike for several reasons...

Solid 70s.

 

The culprit? Clear as day. The headshot hitbox handling.

In BD 21, every monster spams a new short-lived head hitbox every animation frame. With game engine flooded with object creation and destruction.

In BD 22, every monster creates his head hitbox once - which then keeps teleporting after the body in an endless loop. And this, turns out, is magnitudes more efficient than shitting transient hitboxes all over the map.

 

Do you know what this mechanics resembles?

Enemy tanks in BD 21!

Their turret warping in an endless loop after the chassis! Where the chassis does the wandering around and the turret can look around but cannot move by itself.

 

Shame on me. Shame. I am the coder by trade here. And I haven't even thought in that direction after figuring out how tanks worked. A simple A_Warp(AAPTR_MASTER,... ! What could be simpler and more robust?

 

Do you know what that means?

You may, just may, see my upcoming update in the autumn.

Because I am so going to backport this feature into my build of BD 21. I will then call it Franken-BD21.5 and shout "it is alive!"

 

 

[chebmaster]

P.S. No! Bad Cheb! Priorities!
Will focus on finishing the update BUT make the horde difficulties BD 22 only for now.

AFTER that, work on Franken-BD 21.5. After. Not until the update is out.

 

Because, frankly, Zandronum crashed trying to save a hordes game with BDv21che. Not just randomly, but reliably without fail. Monsters wake up, Zandronum crashes.

Edited June 8, 2024 by chebmaster

[chebmaster]

To think of it, this could be the beginning of something BEAUTIFUL. While BD 22 improves performance by light years, it changes headshots balance and mechanics rather radically. At least it feels less glass cannon-y and more bullet spong-y to me

 

If I manage not a backport but an imitation (technically, the solution is one-hundred-lines-of-code simple, it's applying it everywhere without introducing new bugs that requires lots of work) and bring BD 21's performance up while keeping its balance and headshot mechanics...

There ought to be people around who dislike the changes and would like to keep playing 21.

 

Take me, for example -- I still prefer Windows 7 even as I use Windows 10 for making this (I had no choice: UDB couldn't run on my old laptop due to its GPU being too ancient)

[chebmaster]

Well... Coding the underlying mechanism took about two hours, and unlike BD22's it is adjustable, it uses the same hitbox for all animation just moving it around  (you call a script like

TNT1 A 0 ACS_NamedExecuteAlways("FrankenHeadAdjustPosition", 0, 12, 0, 31)

before animation frames with non-standard head position -- like, imps ducking their heads after being headshot with one bullet -- it supports forward-back as well as left-right offsets...

 

AND THERE IS A SHIT-TON OF WORK to be done on the imp alone before his headbox matches *all* his animation frames (take, for example, imps kicked and flying -- the hitbox doesn't go anywhere so it should dip down to match their head. And so on and so forth, without end :(... )
 

 

Remember: the implementation is by the great and brilliant me, but the underlying idea is Sergeant Mark IV's, this Cheb is ashamed to admit of never thinking in that direction.

[chebmaster]

P.S. Toldja it was an ONE hundred lines of code solution.

Here:

// Zandronum can do it!
// here KYDB H, I are my debugging sprites for visualizing the process

actor FrankenHeadshotTarget
{
	
	var int user_x_org; // forward
	var int user_y_org; // right
	var int user_z_org; // up 
	// where A_SpawnItemEx is (x, y, z ,
	//       A_SpawnItem is   (x, z, 0)
	
	...
	
	States
	{
		Spawn:
			XXXX A 0 A_NoBlocking
			XXXX A 0 A_FaceTarget
			KYDB H 2 A_Warp(AAPTR_Master,user_x_org,user_y_org,user_z_org,0,WARPF_NOCHECKPOSITION|WARPF_INTERPOLATE)
			Loop
		Reset:
			// a bit like those invulnerability frames in platformer games
			TNT1 A 0
			TNT1 A 0 A_ChangeFlag("SHOOTABLE", 0)
			TNT1 A 0 A_ChangeFlag("THRUACTORS", 1)
			TNT1 A 0 A_ChangeFlag("NOPAIN", 1)
			KYDB I 3 HealThing(2300, 2300)
			TNT1 A 0 A_ChangeFlag("SHOOTABLE", 1)
			TNT1 A 0 A_ChangeFlag("NOPAIN", 0)
			Goto Spawn	
		Pain10:
			TNT1 A 0
			XDT3 A 0 A_Explode(10,15, 0, 0, 15)//hs
			Goto Reset
		Death:
			TNT1 A 0
			TNT1 A 1 A_NoBlocking
			Stop

	...

ACTOR Imp Replaces DoomImp
{
	var int user_head_tid;
				
	...
	
	States {
		Spawn:
			TROS A 1
			TNT1 A 0 ACS_NamedExecuteAlways("BDCHeckClassicMonsters", 0, 0, 0, 0)//Check if Vanilla Mode is activated
			
			TNT1 A 0 ACS_NamedExecuteAlways("FrankenHeadSpawn", 0, 18, 0, 48)	
			
			...

		Pain.Head:
		Pain.Shrapnel:	
			TNT1 A 0 A_TakeInventory("SKImp", 1)
			TNT1 A 0 A_FaceTarget
			//TNT1 A 0 A_SpawnItem ("HeadshotTarget4", 0, 40,0)
			TNT1 A 0 ACS_NamedExecuteAlways("FrankenHeadAdjustPosition", 0, 0, 0, 40)
			TROH Q 3 A_Pain
			TROH R 3 A_FaceTarget
			//TNT1 A 0 A_SpawnItem ("HeadshotTarget20", 12, 31,0)
			TNT1 A 0 ACS_NamedExecuteAlways("FrankenHeadAdjustPosition", 0, 12, 0, 31)
			TROH S 20
			//TNT1 A 0 A_SpawnItem ("HeadshotTarget20", 12, 31,0)
			TROH S 20
			TNT1 A 0 ACS_NamedExecuteAlways("FrankenHeadAdjustPosition", 0, 18, 0, 48)
			Goto SeeContinue


	...
	
#library "FRANHEAD"
#include "zcommon.acs"

// headshot hitboxes are serverside-only entities

SCRIPT "FrankenHeadAdjustPosition" (int x_org, int y_org, int z_org) NET {
	
	// assumes it is called by the head's master 
	// who has user_head_tid already set
	int htid = GetUserVariable(0, "user_head_tid");
	SetUserVariable(htid, "user_x_org", x_org);
	SetUserVariable(htid, "user_y_org", y_org);
	SetUserVariable(htid, "user_z_org", z_org);
}

SCRIPT "FrankenHeadSpawn" (int x_org, int y_org, int z_org) NET {
	
	// assumes the caller has user_head_tid defined
	int htid = UniqueTID();
	SetUserVariable(0, "user_head_tid", htid);
	while(!Spawn("FrankenHeadshotTarget", GetActorX(0), GetActorY(0), GetActorZ(0) + 24.0, htid)) {
		delay(3);
	}
	delay(3);
	
	SetUserVariable(htid, "user_x_org", x_org);
	SetUserVariable(htid, "user_y_org", y_org);
	SetUserVariable(htid, "user_z_org", z_org);
	
	int myoldtid = ActivatorTID();
	int mytemporarytid = UniqueTID();
	Thing_ChangeTID(0, mytemporarytid); // assign the caller a temporary TID
	SetActivator(htid); // now the script is operating from the frankenhead, 
	// we lost access to the original caller except by its temporary TID
	SetPointer(AAPTR_MASTER, mytemporarytid); // ONLY works on the script's activator, hence we had to switch it
	Thing_ChangeTID(mytemporarytid, myoldtid); // restore the caller's TID
}

That is all.

Now spam FrankenHeadAdjustPosition calls, debug, adjust, debug, adjust, catch edge cases where it working wrong, debug, adjust, debug, adjust...
Then repeat for every frakking monster class there is. >:(

 

[chebmaster]

Whelp, that was FAST.

The imp is done, the headbox follows the head more or less accurately... It lags for up to 2 tics, the sprites weren't designed for this so they look taller from the front so you headshot the imp from behind by hitting the air just above his head, there is a small desync when the kicked imp is flying...

Well, so what? This is an imperfect world.

 

Why not already include this improved hedshot imp in my next update?

 

A fun fact: if you kick a monster who is fighting someone else, your kick propels him not away from you but away from his current adversary. May be sideways, may be back at you...

Because kicking implemented via 100% flinch chance, monster turning to face target then propelling himself backwards. Assuming the target and the one who kicked are one and the same.

 

P.S. OHCRAP forgot to take my hard drive order from the shop!!! Awayyyyy----

[chebmaster]

P.S. The video for youtube, the stress test on a 1000-imp map to gauge the efficiency, the (in case efficiency proves adequate) proposal for Mark-sensei to merge this technique into BD 22...

LATER.

Because I ran myself into the ground as of lately. Which cannot be good for health in my old age.

[chebmaster]

A quick coding before breakfast: imitating BD22's slaughtermap optimizations.

Mine is even better, because the slaughtercheck is ran when the monsters first see you (and gradually while they walk, to avoid a big freeze, and a guaranteed check before firing, if haven't done it yet) instead of on spawn as in BD22 -- which triggers on my advanced teleporting monster closets, packed tightly of course!

 

Slaughtercheck: a monster gives all other monsters in a radius of 500 a +1 SlaughterCounter. If that SlaughterCounter is higher than 50, the monster uses slaughtermap optimizations:

1. No leg target spamming -- those imps don't have leg hitboxes so a leg shot off won't happen

2. removed small flames sfx when readying a fireball

3. fire a grossly dumbed down fireball (no dynamic light, no flame trails, no smoke trail, no underwater bubbles, no scorch mark on walls, no flaming particles nor smoke effects on hit)

4. not using a special attack if the target is a tank

 

 

(mind that this is Intel integrated graphics on a ThinkPad)

 

The old brutalv21che: Framerate Died. 4..6 fps.

 

 

The upcoming frankenBD21.5che: playable almost 30, matching BD22!

 

 

The eidolon to compare to, brutalv22test3: playable almost 30

 

 

 

 

 

 

[chebmaster]

My server for downloading is up again, the maintenance on the power line is over.

[chebmaster]

My questing for a solid beam

 

The simpler, shorter variants are easy. Inherit from FastProjectile, set a trail actor class, voila.

 

There’s a tiny snag, though. Fast projectiles spawn exactly 8 trail actors per movement they do in one tic. So you either get something visibly slow moving (like original BD mastermind’s shots) or a horribly stretched string on beads that only has a resemblance to a beam if viewed more or less head on.

 

My first idea was to use another, slower fast projectile as the beam’s trail actor. Nope, did not spawn. Had to use intermediary actors that, in turn, fire those secondary fast projectiles…

 

After a crapton of debugging, swearing and correcting I ended up with a 5-stage matroshka with the main projectile’s speed being over 5000 per tic - an insta-hit, solid laser beam.

 

..and then it fell apart in Zandronum, because unlike GZdoom, the fast projectile’s trails do not inherit its pitch, only the angle, and there is no way around that.

 

All right, all that hard work wasted I went and redone beam drawing in an ACS script, a child’s play to draw a line of sprites from point A to point B.

 

Aaaand… Nothing.

 

Guess what? With ACS’s asynchronous nature, by the time that script begins executing the fast projectile had already hit something on the other end of the map. The script cannot get the beam’s origin, it begins with the point B.

 

Shucks.

 

Of course I then tried all sorts of tricks with user variables --- but, either their assigning from DECORATE doesn’t work or there is some trick I am unaware of. Got all sorst of glitches, mostly involving the beam drawn from the map’s origin, not from the mastermind.

Tried firing a slow fast projective and accelerate it mid-flight using A ChangeVelocity. Glitched craptacularly, bogus beams flickering all over the place.

 

In the end, after hours of painful debugging, I settled on this variant:

 

The origin is stored in mastermind’s user variables. Each time he fires a laser, he actually fires two projectiles: a zero-speed origin finder -- which immediately launches an ACS script that reads that projectile’s coordinates and stores them in mastermind’s variables -- and the actual laser with speed of 2000, which launches the beam drawing script when it hits something -- reading the origin from the mastermind. Because, in ACS, projectile has easy access to the monster who fired it via SetActivatorToTarget(0) (projectile's target, counter-intuitively, is the one who fired it. The actual target goes by "tracer" and is only set for homing missiles, like revenant's)

 

A cheating of sorts because at very long distances the laser may take several tics to hit but the beam is then drawn all at once, as if it was an insta-hit hitscan.

 

But I fragging’ did it! A solid beam! Working in Zandronum!

 

 

 

 

[chebmaster]

Ha. There was a sleeper bug in my new code, resulted in Zandronum crashing if you tried saving the game while playing map 12.

On the plus side, I had optimized the living daylights out of that map, improved it a lot (while still thinking it was the map that was broken).

I know for sure that is a problem with my modifications to BD21 because that map runs just fine with BD22 and crashes the same with frankenBD21.5che, no matter if I use the latest Zandronum 3.1, the alpha build of Zandronum 3.2 or the 32-bit Zandronum 3.0 from 2019. The crash is the same - with amazing consistency.

 

On the downside, I have not a slightest idea what exactly went wrong (it's a crash-to-desktop, the application just terminates without further clues) -- so I will probably spend many days investigating and trying to single the cause out.

Another downside, the hordes adaptation stalled: cannot edit further until I play-test many maps already prepared for it.

 

P.S. Tried Okuplok with my frankenBD21.5 and with BD22. Both die ignobly (one frame in several seconds) when the first megahordes see you, but BD22 causes a giant freeze at the map start while mine does not (that's the power of lazy on-demand initialization!)

Will likely never be able to run it, but sparked ideas for some extra slaughter optimizations.

Edited June 12, 2024 by chebmaster

[chebmaster]

GOTCHA, BITCH ["Doomguy found a BFG" face].

 

It was the hack I added hoping EDAY would break less with third party mods that replace monsters with losing their TIDs.

The advanced teleporting monster closets had additional triggers that ran backup flag-assigning scripts when monster hit floor -- while monsters were set to spawn in the air, to fall down and guarantee triggering that.

 

It worked with UV number of monsters, but the added herdful of cacoes made something in the game engine snap. Some sort of buffer overrun, probably.

Will file a Zandronum bug later. Such bugs are notoriously hard to catch.

 

You know, what?

*#$% third-party mods. I'm taking those hacks out.

 

P.S. The above means the obstacle to me continuing with the hordes adaptation is gone and I can move forward.
Because that crap wasn't just causing crashes at saving, it was adversely affecting the framerate as well.

 

P.P.S. The physics engine is really powerful. 4000 imps fighting 1000 mancubi...? If you look the other way, it runs at a passable framerate. Even with all my headshot hitbox scripts running on all the imps, matching headbox to animation all the time.

It is the rendering of all those sprites that cause a problem.
I wish they implemented dither-based OIT(order-independent transparency) in the engine with grouping sprites by texture. That would have sped rendering tremendously.

(taht was what I was planning for my game engine before it got shelved indefinitely due to me getting obsessed with improving EDAY).

 

P.P.P.S. Changed the initialization routine, the hitbox only gets spawned the first time the monster tries adjusting it. Meaning, mostly, when the line of sight to a player appears.

Still a few snags: hitboxes sometimes linger after the imp dying, hanging over his corpse, totally immortal. Also, plasma projectiles fly straight through.

 

Edited June 12, 2024 by chebmaster

[chebmaster]

So, the power grid maintenance season is far from over it seems, had another outage this morning: the city was hit with torrential downpours, the power cables are mostly underground -- I keep meeting tractors digging holes in the sidewalk, chunks of armored cables laying nearby.

Also, my server is set up to off after a power loss. I have to log in and bring Apache up manually every time:

 

I *will* upload to ModDB as soon as I am satisfied with the quality. Probably after 1.25 is out and platinum.

Edited June 13, 2024 by chebmaster

[chebmaster]

Annoyingly, another day of downtime is coming: June 14, 2024 08:00 to 17:00(5pm) MSK (UTC +3). They keep putting up power outage notices and working in the transformer room. After a decade of uninterrupted power -- why now :(

 

Also, two reasons why I am an idiot:

1. Left my umbrella home. Had to get creative, wear a grocery store bag over my bag with this same laptop with this project on it (the last backup, when? Can't remember)

2. Was testing slaughtermap optimizations performance on a laptop with integrated graphics.

What is the most used resource in these situations? RAM bandwidth. Which is meh in any laptop, i7 10510U nothwithstanding.

What else hogs the memory bandwidth under load...?

Right, the integrated graphics. The CPU and the GPU fight over it and neither gets enough.

 

Conclusion? No more trying to run Okuplok on this Thinkpad. There is a gaming PC for that.

 

Also, the mancubi in Okuplok started falling off the cliffs... Making me realize I forgot fix the "monsters falling off ledges" BD21 bug for them. Knights, barons and revenants fixed. Mancubi... Wait for the upcoming update.

[chebmaster]

I, *finally*, added debugging (made all existing BD21 headboxes show as squares).
Now I know why it was so hard to headshot barons.

THERE IS SO MUCH MISALIGNMENT! :(

It's even worse with fast monsters like archviles. You can never headshot a moving archvile from the side because his headboxes trail far behind his head like breadcrumbs.

Upgraded Mancubus to my new frankenheads, it became so easy to headshot him! Often dies in 3 well placed shotgun shots. NOT super shotgun, though, because that, counterintuitively, requires more shots by some reason (probably blocked by his thicc hitbox before reaching the headbox). Will investigate later.

You can headshot with plasma (sadly, imps only take 69 damage so no one-shotting them).  Can headshot mancubi with the rocket launcher (one hit kill).

 

 

P.S. Will bring my server up tomorrow: want to use this occasion to upgrade it first. In goes iron wolf, out goes the traitorous wd red. Who could have thought a hard disk would be subject to planned obsolescence...? An almost new hdd (only 8 years 8 months uptime) has zero bad sectors, passes all self-tests -- but since its "power on hours" s.ma.r.t. parameter dropped down to 1 it refuses to write. It simply became read-only. Meh, it served me well. Some barracudas couldn't even last 7 years.

Edited June 14, 2024 by chebmaster

[Firedust]

Damn, you been doing the lord's work for a good while now. Still gonna wait till you implement all the QoL changes you got planned :)

[Serathis]

I swear all the work you put into this is Cacoworthy

[chebmaster]

:)

 

I'm just a rabid fan trying to preserve what I love (the overall feel and balance of BD21)

 

I uploaded the partially done pre_Alpha_BD21.5che-15-06-2024.pk3 which displays headboxes as little squares -- so you can check how headboxes actually behave.

magenta (imp and mancubus) are my handiwork.

yellow are existing BD21 headboxes that were there since the beginning (zombies and knights are good, barons and revenants misaligned, archviles terrible and cyberdemon hides his head inside his chest where his heart should be.

cyan are invulnerability frames on either (a bit like your character blinking in platformers)

 

Don't try this one in combination with chebskies, just unleash it on standard doom2 maps at your leisure.

 

Un-frakking-fortunately, I'll have to take the server down *again* tomorrow because the new hard drive shows THE SAME symptoms (DMA errors galore, impossible to write), which makes me suspect it was not the drive at fault but either the power cable, the SATA cable, the SATA RAID controller, or the PSU being on its last legs.

Oh joy.

[chebmaster]

In six hours, SMART parameter Seek_Error_Rate dropped from full nearly to the failure threshold.

I am taking my server down before the disk registers self a s failed. Either it is dead or has insufficient power.

[chebmaster]

P.S. Was caused by insufficient power. Brought it back up by disconnecting another disk with trash I won't miss, will fix at a later date by installing a new PSU.

[chebmaster]

The state of slaughtermap affairs so far: the big daddy runs at 10 fps, which is not survivable...

 

(fyi: Okuplok is a slaughtermap with over 23 thousand monsters)

 

 

[chebmaster]

Face, meet palm. Forgot to start apache2 after turning the server on.
Should work now.

[chebmaster]

Progress report: while many maps are adapted, only the actually play tested ones count -- and I only tested up to and including map 13, which makes it 14 out of 40.

Because, ridiculously, I am still encountering bugs! Like minor HOM cracks in the ground (I strongly suspect these were smoothed over by Zandronum 3.0 I was testing it in the previous time - a normal doom behavior of rendering far side's flat instead of a missing wall texture -- this is how the ambushing monster pits are made, after all). But it seems Zandronum 3.1 only renders actual monster pits that way - i.e. all the walls of a sector must have no texture for the effect to work.

But sometimes, it's more serious stuff. For example, the surprise crates in map 13 are set up incorrectly (was like that from the beginning, the cause is their trigger is duplicated twice for some reason making the monster closets open twice, which result in a tiny but deep slit in the ground -- which monsters avoid considering it a sheer cliff and never come out).

Also, the GZDoom Builder (bugfix) did not draw textured automap in the automap highlight mode, which resulted in me managing that side blindly in the dark, and missing a lot of stuff that should not be visible on the textured automap. Like some secrets, for example: the lines are hidden, but the textured sectors are not.

UDB lets me see it all and fix it all.

 

P.S. Also, at a closer look at the code, too many imp deaths leave a corpse that is not considered a corpse as far as archviles are concerned -- resulting in much less raising than should be. Will be fixed as well.

 

P.P.S. My bad, 15 out of 40 because I had already playtested map 312

Edited June 17, 2024 by chebmaster

[chebmaster]

Aha! My debugging visualization was not taking *derivative* headboxes into account, and those can vary in size!

Will upload a corrected version showing the *real* state of affairs later this day.

 

[JustAthel]

What do you mean by derivative hit boxes?

[chebmaster]

Classes inheriting from HeadshotTarget*** and then only changing the radius and height.

My visualization worked by displaying sprite that matches in size the original HeadshotTargetBase (radius 7, height 18).

With

actor CybersHitBox: HeadshotTarget8
{
  Radius 24
  Height 44
  damagefactor "Explosive", 0.7
  +DONTRIP
}

it failed because it inherits its states, and sprite with its size, from HeadshotTargetBase - and displays headbox incorrectly.

I will fix that with scaling the sprite for each such headbox, like

actor CybersHitBox: HeadshotTarget8
{
  Radius 24
  Height 44
  damagefactor "Explosive", 0.7
  +DONTRIP

  //for debugging
  XScale 3.43
  YScale 2.44
}

to display the correct proportions.

 

P.S. And we can also see that cyberdemon only takes 140% damage from a rocket to the face, as opposed to 200% from other damage types.

Edited June 18, 2024 by chebmaster

[chebmaster]

After reviewing the *actual* headbox situation, without bias introduced by my former incorrect visualization, I conclude:

Zombies, shotgunners, changunners and knights will do for the time being, relegate reworking their heads to the next update.

Barons really have misaligned headboxes -- will fix.

Revenants and archviles move too frakkin' fast, the existing headboxes are just inadequate for the task (unless you spawn them every two tics, which is simply not viable) -- will fix.

Imps, mancubi and cyberdemons -- already done.

Cacoes, arachnotrons, ancient arachnotrons, masterminds, pain elementals, lost souls, aracnorbs, EDAY final boss -- do not have, pass.

Volcabi - haven't tested yet. A rare monster, I only use him in the final bosses' minion lists on higher difficulties.

Juggernauts - haven't looked into their code yet. Suspect they do not have.

Belphegors - probably will have to fix.

EDAY-only monsters (dukes, mummies) - will have to, especially as dukes are derived from barons and thus require complex dances around BD22 compatibility.

EDAY great bosses -  do not have. Should I add?

[chebmaster]

I have uploaded two versions with correctly displaying headboxes: before cyberdemon conversion and after.

there is a question: in BD21, the headshot damage is not *exactly* double, it is a lookup table with some rather strange edge cases:

1..4 -> 20
5..9 -> 10
10 -> 20
11..12 -> 22
13 -> 26
14 -> 28
15 -> 30
16..19 -> 32
20..24 -> 40
25..49 -> 50
50..74 -> 100
75..99 -> 150
100..115 -> 200
116..124 -> 234
125..149 -> 250
150..174 -> 300
175..199 -> 350
200..224 -> 400
225..249 -> 450
250..274 -> 500
275..299 -> 550
300..499 -> 600
500..2299 -> 1200
2300+ -> no damage, headbox fails and disappears for ever resulting in a broken dullahan monster (but nothing in the game can inflict that much damage)

 

As you can see, railgun headshot does 600, not 800. If you ever manage a hit for 500 or more (but with what?), the damage suddenly ramps up to 1200... And stays there, capped to 1200.

 

And, I am unsure: should I preserve this behavior as part of the BD21 charm I want to preserve, or replace it with simple doubled damage (very simple, one line of code) or, better use a hybrid approach: use "2 * damage on the headbox" for the range of 1..299 but for 600+ preserve the two-caps behavior of the lookup table

 

What do you think?

 

P.S. My bad, there is a leftover code from BD20b and the damage for 1..4 is 20.

Seems like a conversion bug to me.

 

P.P.S. The same lookup table from BD20b looks more fascinating:

0..7 -> 20
8..11 -> 25
12..24 -> 35 // a very non-linear beginning
25..49 -> 50 // then the same discretized more-or-less 2x
50..74 -> 100
75..99 -> 150
100..115 -> 200
116..124 -> 234
125..149 -> 250
150..174 -> 300
175..199 -> 350
200..224 -> 400
225..249 -> 450
250..274 -> 500
275..399 -> 550 // a wide range capped at 550
400+ -> 1200 //railgun headshot is death

 

P.P.P.S BD19.1 used a completely different system with thresholds for different damage types and headshots conveying that damage type.

For the minigun, it was

0..34 -> 70

35+ -> 150

 

And, BD22 is back to something akin used in 19.1 but even more extreme: fixed values for various damage types completely disregarding the actual damage inflicted. I am not sure I like that approach.
At least, railgun headshot is 1200 again.

Edited June 18, 2024 by chebmaster