r3305 (etc) PROP_TOTALLYFROZEN does not block crouch toggle

[Enjay]

Not sure if this is a bug or not but it feels wrong.

If the player has been set to be totally frozen via ACS but uses the crouch button to toggle crouch whilst in that state the player will not duck (ie expected behaviour). However, as soon as a script unfreezes the player, he will duck down into the crouch position.

Presumably this happens because, unlike most other functions, crouch toggle is not an instant action that is simply blocked but is a toggle where its value is remembered. If it is possible, I suggest that blocking crouch input while the player is frozen would be more intuitive.

I'd be surprised if a demo map was needed but if it is, just let me know.

[amv2k9]

Just for clarification, does this happen when using the crouch type that requires you to press & hold the assigned button as well, or just the toggle?

[Enjay]

Well, I suspect that is kind of different but:

a) if you press and release the momentary crouch button while frozen, you do not crouch (even temporarily) when you are unfrozen (or during the freeze, obviously).

b) if you press and hold momentary crouch until you are unfrozen, as soon as you are unfrozen you will move into the crouched position but when you release the crouch button you stand up.

The above seems a logical and natural way for things to happen but the crouch toggle waiting for you to become unfrozen and then crouching the player may seem OK from a certain POV (ie you can store up your crouch to automatically duck when the freeze is removed) but illogical from another POV (ie you are not supposed to be able to do anything except press [use] when totally frozen).

In my particular case, it kind of ruins an effect at the start of a level. I have the player start in a small hole to bring his eye line down near to the floor, simulating him waking up from unconsciousness - which is how the previous level finished. The player is frozen whilst the view fades in and out from black a couple of times and then the floor of the hole is raised to simulate the player getting up from the ground. It works pretty well. However, if the player presses crouch-toggle before he is unfrozen, he seems to rise up to the standing position and them immediately duck back down to his unconscious position when the freeze is released. This looks weird.

For a bit of additional information, if you are frozen and press crouch-toggle twice (which in a non frozen state would crouch you and then uncrouch you) the second press does not seem to take effect and you will duck when you are unfrozen but not then unduck (new word?). Perhaps this is because uncrouching requires you to to actually be crouched before it will take effect and this never happens in the frozen condition?

[NeuralStunner]

unduck (new word?)

Zombie ducks! ("Graaaaaaainsssssss...")

It almost makes sense to me the way it is, if you consider the crouch toggle as alternately sending +crouch/-crouch commands (not to imply this is what it does), which if you entered manually would have the same effect. A second hit not registering for a de-toggle does sound like a bug to me, though.

As far as your opening scene goes, seems the best you can do is use "honor system" - If a player is trying to control during a "cutscene", then I think any glitches are kind of their own fault.

[Enjay]

Yes, it may not be a bug but I'm kind of hoping it is because it would fix my cutscene.

And, as the wiki says:

4 — PROP_TOTALLYFROZEN — Same as PROP_FROZEN, but does not allow the player to look around or shoot. (In fact, the only control they can still use is the “+use” key)

When, in fact, they can also use the crouch toggle key to toggle the crouch condition, wait for the cutscene to finish and automatically duck as soon as it does . Although, I accept the wiki is not always fully correct.

As far as your opening scene goes, seems the best you can do is use "honor system" - If a player is trying to control during a "cutscene", then I think any glitches are kind of their own fault.

I would tend to agree with you but some cutscenes, and I would include my one in this, make it natural for the player to feel he might be able, or even required, to do something during the scene. As I said, my one similates the player waking up lying on the floor and in that situation I could understand a player wiggling the mouse or mashing the keyboard to see if it wakes them up quicker (even though the cutscene only lasts a few seconds).

Zombie ducks.

[FDARI]

Related to your work, not the bug: You could establish some visual or auditory cue for all passive cutscenes. Perhaps briefly spirit the player away and look through a camera instead; that would hide the weapon, and perhaps some other game play indicators.

[Enjay]

Thanks for the input. I take your point, there is more than one way to skin a cat (how did that expression arise?). Before I went with the current method (which feels more solid and fully ZDoom-ish) I was using FraggleScript to lower the viewheight and raise it at the start of the level. It was a nice enough effect but I kept accidentally overwriting the FraggleScript and it never felt as "solid" to me. Realistically though, and practically, I'm happy with my cutscene as it is and I'll just live with the risk of a player hitting crouch toggle and making the end look a little weird. As for the weapon being hidden, the player is ambushed in the previous level and wakes up in a cell with no weapons any way.


My main motivation for posting was not merely to fix my cutscene (though that would be nice) but rather to report something that seems to be against how a feature (Prop_TotallyFrozen) was introduced to work. IIRC, it was originally added because, for certain uses, Prop_Frozen was seen to be inadequate because it still allowed the player to perform some actions (eg firing). TotallyFrozen was added as a way to make it so that the player can do nothing other than press +use. So, given that the player can also press crouch-toggle to "store up a crouch" until the freeze is removed, it seems to be against the original intention of the feature. As for whether it will be considered a bug to be fixed or not, I can't really say.

[NeuralStunner]

there is more than one way to skin a cat (how did that expression arise?).

The Unducks thought it up.

[Zippy]

In my particular case, it kind of ruins an effect at the start of a level. I have the player start in a small hole to bring his eye line down near to the floor, simulating him waking up from unconsciousness - which is how the previous level finished.

Not particularly relevant to the actual feature suggestion but... I've done this kind of thing before by having a lowered sector whose sound sequence for moving the floor has been completely silenced, and using transfer heights to make a false floor that matches the surrounding floor. That way, when the player is in the sector their eyes appear close to the ground, and when the sector's real floor raises (silently due to the sound sequence) it gives the appearance the player is getting up, because the false floor is stationary and doesn't appear to move.

[Enjay]

Yup, that's exactly how I have done it.

I originally didn't have the player totally frozen, merely hemmed in by blocking lines, but in that case, he can duck and see below the fake floor.

[randi]

Fixed.