what is the archvile flame supposed to look like?

[40oz]

On some source ports the archvile flame can look flashy or flicker a lot or jump around at various heights.

is it because of the frame rate? Is the ceiling too low for its height? Is the target moving too much? Ideally, what is the correct archvile animation look look like? Is it buggy code? Is it a map-specific thing? Or is it some other common particular circumstance that makes archvile flames look jittery?

[scifista42]

40oz said:

Ideally, what is the correct archvile animation look look like?

You can find it out very easily by standing still and letting an archvile attack you.

According to the (DEHACKED) definition of AV's fire, it tracks its target and the position gets refreshed every 2 tics. So, whenever the player moves within the one "dull" tic (very probable situation), the fire may be off his position for the one moment. This causes the flickering, I believe.

It's also worth noting that while seeking the player, the fire thing actually attempts to place itself a bit in front of the player, so that he can see it.

[Da Werecat]

Sometimes the fire is completely misplaced though. It's a little buggy.

[scifista42]

^That happens in the following situations:

• Archvile changes his target during preparation to his attack. Once the flame starts tracking an entity, it will not change it according to the AV's current target.
  
• Player is not in line of sight of the archvile. Then, the flame's refresh ability doesn't work and the flame stays in the last place where there was a direct sight contact between the player and AV.

[printz]

I've suffered the bug more prominently in PrBoom (probably +?). The fire was completely misplaced, and the volume was now. What I believed was a funny rattling was instead my death. I couldn't see the fire so I got fried.

[Maes]

printz said:

What I believed was a funny rattling was instead my death. I couldn't see the fire so I got fried.

OK, this gave me the idea for a creepy mod where the archvile's fire is invisible, you only get to hear the "death rattle" sound from the Grudge/JuOn movies as a short warning, and suddenly you die. And even the archvile's active sound would just be a short death rattling.

[Doomkid]

I've noticed this too, in some source ports the fire seems to 'double up' almost as if there are 2 flame spirtes atop eachother. I've just booted up doom2.exe, and that's a glitch - the fire is meant to act as scifista described, with no double hieght weirdness going on.

[Deleted_Account]

I think it's supposed to look like fire.

[Quasar]

The arch-vile fire jumping around between different heights is some kind of PrBoomism, AFAIK. It never did that in vanilla, it doesn't do it in MBF, and it sure as hell has never done it in Eternity. I don't understand why it's never been fixed.

[printz]

In vanilla it sometimes moves to another XY coordinate, I think.

[Delet]

Maes said:

OK, this gave me the idea for a creepy mod where the archvile's fire is invisible, you only get to hear the "death rattle" sound from the Grudge/JuOn movies as a short warning, and suddenly you die. And even the archvile's active sound would just be a short death rattling.

Die, and fly up into the air. Hm.. How about having an archvile down a long hallway so it can only see you when you are standing on a "time-bomb" square. Stand on a bomb too long, explode.

[NiuHaka]

I'm not sure that this is exactly what you mean by "flicker a lot" but the flickering is deliberate. It blinks so that the player can still see during the attack. It's been about fifteen years since i've looked at it but if i remember correctly it switches between larger sprites, which cover the players field of vision, and smaller sprites, which are above the players field of vision.

[Maes]

tomocean22 said:

How about having an archvile down a long hallway so it can only see you when you are standing on a "time-bomb" square. Stand on a bomb too long, explode.

This concept -among others- was explored in this map, though this map revolved more around stealth and avoiding shooting while in certain areas, while doing a lot of lateral thinking.

[Linguica]

I've noticed this too in prboom-plus and I was like "I think it must be a bug."

<- prboom-plus

But then I tried it in Chocolate Doom, and it's possible it's Working As Intended? I guess I've forgotten how the fire is supposed to look?

<- chocolate doom

edit: just to be sure I broke out the ole Steam DOSBox and yeah I guess so

<- doom2.exe

[Quasar]

Hmm odd. I don't understand what mechanism is causing that. I guess it's time for some source code archaeology >_>

EDIT: Can't figure it out. I can see why the fire would be at a potentially strange Z coordinate for its first two tics because the A_StartFire pointer does nothing. But after those two tics, every frame calls A_Fire either directly or indirectly, which sets the fire's z position to equal the tracer target's z position. I don't see any mechanism by which it ought to jump up and down between two different heights.

Something deeper than the obvious is behind this, that's for sure.

EDIT 2: Got it. It's a non-obvious side effect of the known glitch that can offset the vile fire's initial spawn position. Since the fire is erroneously spawned at (actor->target->x, actor->target->x), instead of (x,y) as expected (with target here being the Arch-vile's target), the floor z and ceiling z fields of the fire are set to the properties at that point.

Now, since the fire is henceforth only moved manually with use of the P_(Un)SetThingPosition functions, these floorz and ceilingz values are never updated. However, P_MobjThinker will call the function P_ZMovement on any mobj that isn't resting at its floorz, even objects like the Vile fire which have the MF_NOGRAVITY flag.

The function P_ZMovement continually attempts to bound the position of the fire between mo->floorz and mo->ceilingz - mo->height. What you see here is the fire having a [floorz, ceilingz-height] range which the target of the attack lies outside of. Since the z coordinate of the fire is only updated to match its target every two tics, but P_MobjThinker applies every tic, the fire jumps back and forth between the desired and bounded locations every other gametic.

Booya.

[Linguica]

So is this a documented bug, or does it not count as a "different" bug? It's certainly been noticed before, see, e.g., https://www.youtube.com/watch?v=BM0unrUMUvw.

[Quasar]

Linguica said:

So is this a documented bug? It's certainly been noticed before, see, e.g., https://www.youtube.com/watch?v=BM0unrUMUvw.

The x-y plane displacement is documented on the DoomWiki, but there's no mention there of it also causing the jumping z effect. I don't think anybody understood it fully, maybe until now...

It's probably worth noting that it could still happen even with the x-y fix that's in BOOM, too, if the target moves into a sector with different properties than the one the flame started in. You should be able to do that pretty easily in MAP30 just by jumping down the lifts. The fire should get bounded to the floor height of the higher lift you just jumped down from and flicker in the exact same way...

[40oz]

Thank you for bringing this thread to life again linguica. I knew there was something peculiar about it. I was going to post gifs like the ones you posted but I never got around to it.

[Doomkid]

Wow, so it DOES happen in vanilla - With all the times I've played IOS, I'm surprised I'd never noticed it until using source ports.

[bradharding]

So, before this intriguing post gets forgotten about again, what would someone suggest as a solution, code-wise?

[LockeRequiem]

A_StopRaisingTheRoof ?

[Quasar]

bradharding said:

So, before this intriguing post gets forgotten about again, what would someone suggest as a solution, code-wise?

Add code to update mo->floorz and mo->ceilingz when the Arch-vile fire is moved.

[Linguica]

I'm curious why PrBoom et al includes a compatibility flag for this anyway. Is there any actual effect on the gameplay from fixing this bug? It's not like it can desync demos, can it?

I guess it's possible than somebody at some point made a level that expects that archvile flames under certain specific circumstances will blind you less than normal, even if they didn't necessarily understand why?

[Blastfrog]

Linguica said:

Is there any actual effect on the gameplay from fixing this bug? It's not like it can desync demos, can it?

I can imagine that it could if the flame's behavior is significantly altered in DeHacked. That's always something that should be kept into account; that behavior mods may expect old behavior even if the default actors are set up in such a way that you don't have to worry about changing quirks. Not just past and present DeHacked mods, but potential future ones, too.

[kb1]

It is amazing what can desync demos, but I have a feeling that PrBoom is just sticking to it's philosophy that changes to vanilla should be optional.