ZDoom

Prior to 2.3.0, I had this script going that allowed a player to fly similar in fashion to how Tails flies in Sonic 3. The difference is that it is push and hold, instead of tap like mad. It worked okay, though the player was capable of flying pretty high pretty quickly. I used this little deficiency to my advantage for a little bit.
Now, it's a bit fucked up. Here's how:
Jump in the air, and start flying while you still have upward motion. You'll fly higher as per normal.
Let go for a bit until you have downward momentum. Previously, you can recover and rise again. Now, it only stops descent, preventing you from rising again until you fall and land.

When messing with the wad, set sv_aircontrol to 0.2.

Flight code:

Spoiler:

---

Code: Select all

global int 63:fallow; // In the test wad, the scripts have been slightly adjusted so that you can fly at any time.

Script 920 (void) // Vertical Thrust
{
if (CheckInventory ("Health") > 0 && fallow == 1)
{
FloatHeight = (GetActorZ(0) - GetActorFloorZ(0));
ACS_Terminate(921, 0);
if (CheckInventory("Stam") > 0 && FloatHeight > 0)
{
if (flew == 0)
flew++;
ThrustThingZ(0, 5, 0, 1);
TakeInventory("Stam", 1);
ACS_Execute(923, 0);
delay(1);
restart;
}
if (CheckInventory("Stam") == 0 && FloatHeight > 0)
{
if (flew == 0)
flew++;
ThrustThingZ(0, 3, 0, 1);
ACS_Execute(924, 0);
delay(1);
restart;
}
}
if (CheckInventory ("Health") > 0 && fallow == 0)
hudmessage (s:"You can't do that here!"; 2, 38, CR_RED, 0.5, 0.3, 1.0, 0.00, 0.0);
}

Script 921 (void)
{
FloatHeight = (GetActorZ(0) - GetActorFloorZ(0));
ACS_Terminate(920, 0);
if (FloatHeight > 0 && flew == 1)
{
if (CheckInventory("Stam") > 0)
TakeInventory("Stam", 1);
ThrustThingZ(0, 3, 0, 1);
}
if (flew == 1 && CheckInventory("Stam") > 0)
ACS_Execute(923, 0);
if (flew == 1 && CheckInventory("Stam") == 0)
ACS_Execute(924, 0);
delay(1);
restart;
}

Script 922 ENTER // The player regains his strength when not flying.
{
while(CheckInventory("Health") > 0)
{
FloatHeight = (GetActorZ(0) - GetActorFloorZ(0));
if ((FloatHeight == 0 || flew == 0) && CheckInventory("Stam") != 300)
GiveInventory("Stam", 1);
if (FloatHeight == 0)
flew = 0;
delay(1);
}}

script 923 (void) // Flying...
{
ActivatorSound("flying/putput", 127);
delay(9);
}

script 924 (void) // Worn out...
{
ActivatorSound("flying/pudpud", 127);
delay(9);
}

Perhaps you could boost the thrust if downward momentum is too high?

XutaWoo wrote:Perhaps you could boost the thrust if downward momentum is too high?

I tried this, actually, then it went to a half-broke state. Sometimes, it did the same thing, and sometimes, the player shoots out like a cannon in the air -- not what I want to do, either.

So, I was wondering, why should it be considered a "bug" for gravity to be consistent? I always thought it was screwy that Doom doubled gravity if your current vertical velocity happened to be one specific value, once I found out it did that. Hence, the reason I changed it in the first place. I think that restoring the quirky Doom behaviour should have been done as a compatibility flag rather than as an "always on" thing, but I couldn't think of any specific counterexamples for why that was bad. Until now.

Gotta love what gimmicks can prove, eh Randy?

randy wrote:So, I was wondering, why should it be considered a "bug" for gravity to be consistent? I always thought it was screwy that Doom doubled gravity if your current vertical velocity happened to be one specific value, once I found out it did that. Hence, the reason I changed it in the first place. I think that restoring the quirky Doom behaviour should have been done as a compatibility flag rather than as an "always on" thing, but I couldn't think of any specific counterexamples for why that was bad. Until now.

Huzzah! I have beaten the system!

randy wrote:So, I was wondering, why should it be considered a "bug" for gravity to be consistent? I always thought it was screwy that Doom doubled gravity if your current vertical velocity happened to be one specific value, once I found out it did that. Hence, the reason I changed it in the first place. I think that restoring the quirky Doom behaviour should have been done as a compatibility flag rather than as an "always on" thing, but I couldn't think of any specific counterexamples for why that was bad. Until now.

I don't want to sound harsh - but changes like this one is what gives ZDoom a somewhat questionable reputation in certain circles - and I can fully understand why these people think like that.

I didn't add a compatibility option because I really didn't expect hacky scripts like this one. All I noticed was that in several Doom maps with the altered formula it was possible to jump over gaps you were not supposed to jump over and then finally a map was posted at Doomworld that just happened to work while it didn't on any other port.

But yes, if it really affects existing mods it needs to be compatibility optioned.

Graf Zahl wrote:I don't want to sound harsh - but changes like this one is what gives ZDoom a somewhat questionable reputation in certain circles - and I can fully understand why these people think like that.

I didn't add a compatibility option because I really didn't expect hacky scripts like this one. All I noticed was that in several Doom maps with the altered formula it was possible to jump over gaps you were not supposed to jump over and then finally a map was posted at Doomworld that just happened to work while it didn't on any other port.

But yes, if it really affects existing mods it needs to be compatibility optioned.

So if this script is so "hacky" (given that the gravity seems like a bit of a hack in the first place), do you have any other alternatives to what I am trying to achieve?

ON second thought, maybe a different approach is better: The original double gravity when there's zero vertical momentum only gets applied when the last tic before this one the actor was standing on solid ground. That would solve the problem with being able to run over wide gaps but wouldn't interfere with flying or jumping or other gravity related actions - and it would avoid yet another compatibility option while preserving proper gravity in most cases.

Graf Zahl wrote:I don't want to sound harsh - but changes like this one is what gives ZDoom a somewhat questionable reputation in certain circles - and I can fully understand why these people think like that.

Be that as it may, I still want to know what they were thinking when they wrote that. So a player arrives at a particular height one tic earlier than they otherwise would have while falling. What's the point?

Graf Zahl wrote:ON second thought, maybe a different approach is better: The original double gravity when there's zero vertical momentum only gets applied when the last tic before this one the actor was standing on solid ground.

That would probably be satisfactory. Alternatively, it would probably be sufficient and easier to subtract the speed of gravity from a player's stepheight when they're falling. The end result of preventing players from running across gaps ought to be the same. (Rather than "losing" a tic of falling time at the start of the fall, you "lose" it when stepping onto something instead.)

What will this do to maps that have been built around the idea that you're supposed to run over these wider gaps?

Not that I can name one off the top of my head, mind you, but something is bound to come up.

Xaser wrote:What will this do to maps that have been built around the idea that you're supposed to run over these wider gaps?

Not that I can name one off the top of my head, mind you, but something is bound to come up.

Doom Raider.
Of course none of this is actually helping the (relatively new) problem of how hacky the script even is -- at least, in Graf's own words. There has to be a better way than continually thrusting a player in the air in such a delicate fashion.

randy wrote:

Graf Zahl wrote:I don't want to sound harsh - but changes like this one is what gives ZDoom a somewhat questionable reputation in certain circles - and I can fully understand why these people think like that.

Be that as it may, I still want to know what they were thinking when they wrote that. So a player arrives at a particular height one tic earlier than they otherwise would have while falling. What's the point?

No idea. Of course the original code was written without jumping in mind. So it was probably just a minor tweak to shorten the distance the player could cross when running through the air.

Graf Zahl wrote:ON second thought, maybe a different approach is better: The original double gravity when there's zero vertical momentum only gets applied when the last tic before this one the actor was standing on solid ground.

That would probably be satisfactory. Alternatively, it would probably be sufficient and easier to subtract the speed of gravity from a player's stepheight when they're falling. The end result of preventing players from running across gaps ought to be the same. (Rather than "losing" a tic of falling time at the start of the fall, you "lose" it when stepping onto something instead.)

Actually not because the added gravity gets applied per tic so if the actor falls for 10 tics it means a difference of 10 map units, not 1.

If this is being looked at, can the other problem that has raised its head a number of times relating to jumping be looked at with it? ie the timing of the jump. To recap:

In most games, provided you haven't actually started falling off something, you can still jump. In Zdoom, if your centre point has passed off the edge of a platform, you cannot jump but you haven't actually fallen off the platform yet. This makes it very difficult to time jumps properly sometimes (when running towards the edge of a platform) and, as often as not, you just end up falling off the edge of the platform - despite pressing jump before you start dropping.

It has been bothering me, too but so far I never found the motivation to look at it. It's indeed a very annoying problem...