its very defined just as every single generator of random numbers out there. i know that no real luck can be coded,
but for a single boolean query (able to save input after short unfreeze or not) in a few seconds im pretty sure this function will give good quality random numbers. if you do not consider that luck you can neither do in any program.
for me its enough to call it luck if noone can predict what will happen, and thats exactly the situation for unfreeze in freezetiles.

i didnt know how its coded before, now i see that it requires a different approach to fix my first example. but to adress the second and your example:
right now there are two different outcomes of the situation (unfreeze in freeze): either you are able to save your input, or not. what i suggest is basically nothing but to force the first one. at least that should change nothing at actual gameplay, since its just a special case of what can already happen now. so there shouldnt be any compatibility issues like your example, though i agree that my initial approach may have caused the problem you discriped. besides im still im not sure why your example works in current ddrace as tees do stop immadietly (not sure but feels so, even at high speeds) on ground if no movement, is it just because you do execute that 1 more input after freeze?

to summarize my current suggestion:
do not care for jump after freeze as seen in my first example, its fix may cause other problems and anyway there is nothing less important.
focus on fixing the luck issue which only applies after unfreeze in freezetiles, here is a way that should work:
since hammer has an effect on the hammered tee, you should go there. maybe you can just force apply there. or check if current input will be applied, if not overwrite next one. if im right the case that nothing happens after unfreeze is if you get unfreezed between step 1 and 2 (which must be the longest period from what i feel ingame).

1. tee falls on ground with 1 layer of freeze tiles, no doublejump left. if pressing jump right time and being lucky with the current looptimer you can perform a normal jump from the ground, which is BELOW the freezetiles. itll freeze you but you can perform that jump if lucky, which is weird.

I agree with your second point, I have to say something to your first post however.

Teeworlds ticks 50 times a second. The important parts of a DDRace tick are as follows:

1. Save input. This means, jump, and direction keys are saved.
2. Freeze if on a freeze tile.
3. Apply input. Even if frozen.

So in my opinion, this can't be counted as luck, as it is very defined behavior. Also, you would break some maps if you remove this kind of "feature", consider for example this:

OF
X

O - the tee
F - a freeze tile
X - a collision tile

Currently the behavior is: If you press right, you'll be able to fall down. If we change the behavior as you suggest, you'd be stuck on the right side of the collision tile. This should just be a simple example on what this change would break, I'm sure that there are a lot of other things where this behavior is required too.

1. tee falls on ground with 1 layer of freeze tiles, no doublejump left. if pressing jump right time and being lucky with the current looptimer you can perform a normal jump from the ground, which is BELOW the freezetiles. itll freeze you but you can perform that jump if lucky, which is weird.
2. quite normal, imagine a tee in freeze top, another one bottom, between them 1 layer of collision tiles. the bottom tee now hammers through this collision tiles and hit the other one. now there are different results that can happen based on where this looptimer is right now: either nothing, or the tee is able to perform a short action like moving left a bit. Since you can never figure out this timer its basically luck.

I may be wrong with my analysis, but if not i strongly recommend to fix it. if you think the way i do you would never want luckdepended unpredictable features in this game.
its a better way to make freeze work instantly like killtiles (not same size ofc) or maybe teleporters (really dont know if they do), but instead add a instant unfreeze+freeze immunity for x (or a bit less) seconds.
that should fix it without changing the gameplay except for removing that luck, every hammer/laser now gives the possibility to move a bit left, and bugs like the first issue arnt possible anymore.

if(m_HookedPlayer == -1 && distance(m_HookPos, m_Pos) > 46.0f)

That means, in natural language: If we don't hook a player, the distance between you and your hook must be at least 46 for the hook to take effect (A tile's size is 32).

If anybody need it :
https://github.com/cris272/ddrace-records-converter
You have to set correct variable for host, dbname, user, password, prefix and dirRecords.
Then write "php convert-records.php"

https://downloads.teeworlds.com/solidfi … r_114a_x64

DDRace Client and Server 1.14a for Windows x32

https://downloads.teeworlds.com/solidfi … _1.14a.rar

http://www.youtube.com/watch?v=yHRQU5Y1CQA