LWM's Flashlight is Broken 4.2.1

[Enjay]

Years ago, LilWhiteMouse made a flashlight that uses a script to spawn a stream of actors with dynamic lights attached to act as a flashlight. Although other, more modern, flashlights are now available, I still like and still use this one (aside from anything else, it acts independently to the weapons). However, with 4.2.1 it has stopped working. It worked with 4.2.0.

Here it is working in 4.2.0


But it doesn't work in 4.2.1. However, it is just the dynamic lights that are failing. The actors are being spawned.

Here is a screenshot of the map in 4.2.1 with the AM_Cheat active:


I have attached a cut down version of the flashlight that works in 4.2.0. To use it, load the pk3 and type

+uselwmflashlight

at the console.

[Nash]

While I am not dismissing this as a possible bug, why do you not prefer modern spotlight-based flashlights? Not only is it more performance-friendly, as it's only a single light actor, but it would also light things in a more physically accurate way, and lastly, will generate proper shadows if shadowmaps are enabled.

[Enjay]

One stumbling block is that I don't know how to make one that acts independently of the weapons. With this one, I can bind a key to it and the key runs the flashlight regardless of which weapon is selected or whether I'm firing or not. (I have it bound so that I have to hold the flashlight button to keep it on rather than toggling it on/off so I can't just leave it on all the time).

The other thing is that, actually, I simply haven't found a modern flashlight implementation that I like. Dodopod's one is pretty good but when I tried modifying it to work in the same way as I used LWM's one, i just got horribly lost and it didn't look that much better to me anyway.

A simple, clean modern version would, of course, be preferable but it would need to be activated in the same way, would need to illuminate things just as well (IMO of course).


However, the merits of the different types of lights aside, I can't figure out why this isn't working. The actors are spawning, but the lights are not showing. Other actors spawn with lights just fine so I'm not sure what the difference is.

[Enjay]

Aha! Progress!

I have found how to make the light work again.

If I change line 86 in the DECORATE from:

Code: Select all

NONE A 1

to

Code: Select all

NONE A 2

The lights appear. So, for some reason, I guess that in 4.2.1 that actor isn't around long enough for the light to appear. Maybe?

(BTW a sprite called NONEA0.png is included)

[Nash]

Enjay: Maybe Steve's Flashlight Mod is more suitable for you. Works exactly the way you describe it; doesn't depend on weapons, has a bindable key. Much simpler than Dodopod's one. viewtopic.php?f=43&t=59429

Anyway, that said, carry on with the current investigation. Anything that used to work before but now doesn't, is always worth reporting. :)

[Enjay]

Thanks, I'll check out Steve's one.

[Caligari87]

At risk of sounding narcissistic, gonna just plug DarkDoomZ as well. The flashlight is lightly customizable with simple good looking presets, one-key toggle, and the darkening effects are completely optional. Also not to toot my own horn too much but I think it's one of the better-looking implementations; I spent a lot of time tweaking the preset values.

[Nash]

Code: Select all

class LADGunLight : Actor
{
    Default
    {
        +NOINTERACTION
    }

    States
    {
    Spawn:
        TNT1 A 2 Light("Light_GunLight");
        Stop;
    }
}
 

Seems like I ran into this problem, too. This was an actor that gets spawned when I fired my weapon to generate muzzle flash lighting. The light just doesn't appear anymore, even though the actor is spawned correctly.

Changing TNT1 A 2 to TNT1 A 3 - so 1 additional state tic - will "fix" the lighting.

[Graf Zahl]

A few things to note here:

I can of course add a check for a freshly spawned actor to create its lights immediately. That should fix Nash's problem, but in Enjay's case it won't help because that thing comes with an empty dummy state before the relevant one that practically defeats all attempts to fix this.

Nash's problem is caused by spawn tic randomization. For an actor whose first state's length must be fixed, adding the SYNCHRONIZED flag is necessary. In this case the duration got simply truncated to 1 and the light never showed up.

Update: Turns out I was wrong. The entire thing here is caused by some fundamental misconception about what a tic means.
"1 Tic" does not mean to stay around for 1/35th of a second, it really means, "destroy after being ticked once."
So what happens is simply that the actor might create its light when being spawned but then getting removed before it even hits the renderer for the first time, i.e. it is never drawn! The same applies to the light. In the old code it was the light actor that removed itself when its owner was gone - but since STAT_DLIGHT is one of the lower statnums this happens with a one tic delay.

The new light information is just dumb data owned by the actor, so once the actor is gone, so is the light.
I'm sorry but this qualifies as "Can't fix". TBH, I never realized myself before what precisely the behavior of a one-tic-actor really is.

What this boils down to is that setting a light in a terminating state with a one-tic-duration simply cannot work in a system where the actor controls the lifetime of the light.

[Nash]

Alright, noted. I figured things are different now ever since you rewrote the dynamic light code. Thanks for the detailed explanation.

[Enjay]

Update: Turns out I was wrong. The entire thing here is caused by some fundamental misconception about what a tic means.
"1 Tic" does not mean to stay around for 1/35th of a second, it really means, "destroy after being ticked once."

That's useful information. Although I didn't make this flashlight, I certainly had that misconception too. My fundamental misunderstanding can be summed up by me thinking that a tic was simply a unit of time and in Doom it was 1/35 of a second. I suspect many people think similarly.

So, for further clarification, what exactly does "being ticked" mean. Is is something like "the engine has acknowledged this thing exists"?

[Graf Zahl]

"Being ticked" means that the engine runs its ticker once over each actor.
But here's the tricky part: It counts down the current state's duration and if that reaches 0, the actor is destroyed. So far, so good - but for freshly spawned actors the ticking is performed in the same tic it gets spawned. I guess you can do the math from there...

[Enjay]

I'm following what you're saying and I understand what the problem was, but the bit that's still missing for me is - what does the ticker actually do?

i.e. what happens when the engine "runs its ticker once over each actor"? What is the engine/the ticker actually doing at that point?

I've tried googling it but my Google-fu is failing me. I'm mostly getting things about horizontal scrolling LED displays.

[Graf Zahl]

What can I say other than "It's calling the actor's Tick() function"?

[Enjay]

Seems obvious now. Thanks.