ZDoom

I know this has been suggested and rejected in the past, but circumstances change over the times and recently Graf has kindly added the TimeFreezer powerup from Skulltag into ZDoom.

However, as described in this thread, the TimeFreezer can be used for more than just a powerup.

However, the method I tried is a hacky workaround, and at the end of that thread, you can see why it just won't work for what I want.

So I propose an ACS function that's more flexible than the powerup/inventory hack.
state would be on or off, and time would be the time it takes for the freeze to gradually wind back to normal speed.

Why not something more like:if state is TRUE, freezetime would be used to determine how long the freeze lasts, with 0 meaning it lasts forever until it's toggled off with state = FALSE; slowtime would determine how long the "slow effect" (that matrix'y effect when the time powerup is wearing off) lasts and would add onto freezetime. If freezetime is negative and slowtime is 0, the slow effect lasts until state = FALSE.

Somewhat more complicated, but a LOT more flexible that way. But then again, the perfect solution for this would be to have something like:Like Unreal has, where the game speed is set directly, with 1.0 being normal, 0.5 being half, 2.0 being double, etc. If you wanted to freeze the game, you'd just call Game_Speed (FALSE).

How about something more flexible and generalized like this?
If state is TRUE, the game's current speed (not necessarily the normal speed) slows down/speeds up over a period of transition1 seconds, until reaching the minimum/maximum speed limit (0 being a complete halt and 1 being the normal speed, though not a ceiling). It will remain at this speed over a period of duration seconds (-1 being forever until state is FALSE), then return to the initial speed over a period of transition2 seconds.

This way, you could make neat tricks like different sectors where things gradually slow down/speed up across each one.

I'd find just Freeze(On/off) more useful to be honest.

You're right, come to think of it. Having a simple on/off function is much better.

But what if you want to just slow down or speed up objects rather than freeze them completely? Besides, the time it takes for objects to enter or leave a frozen state should be configurable.

Remember, the more you want the less likely you are to get it. Adding a means to set freeze mode from ACS is easy. I'd just add another option to SetPlayerPropertx for this (but on the other hand, that'd create no less code than doing with Give/TakeInventory.) But when it comes to configurability this will get much more complicated and far less likely to be done.

Haha, double post!
/ban

Argh. I hit the wrong button. I only wanted to edit my post - but since I can delete the redundant one I just did that!

How difficult would it be to implement a Game_Speed (fixed speed) function like Kate mentioned?

Well if you’re going to add that, you might as well add PlayerGame_Speed (fixed speed, actor tid).
A cookie to who can find out what it does

You could "slow" the game down by constantly turning freeze on and off. That's why I said earlier that it would be best to just have an on/off feature.

Dont you think thats a tad bit hacky for you cutman?

Or...


'no'ing this. If you think about it, there really isn't much that would be gained by adding another method to do something that can be done easily with the features at hand so I really don't see the need to waste time on it.

But Graf, removing the TimeFreezer from the player doesn't immediately cancel the effect which isn't ideal for what I intend to use this for.

Any other suggestions?