implement tuning values for elasticity

[AssassinTee]

implements ground_elasticity_x and ground_elasticity_y

Similar to https://github.com/teeworlds/teeworlds/pull/3136

~closes #5124~ implements the player bouncing part of this. Doesn't effect projectiles!

can be followed up by #5313 with a "slimey block", see here

Checklist

• [x] Tested the change ingame
• [ ] ~Provided screenshots if it is a visual change~ NO VISUALS
• [x] Tested in combination with possibly related configuration options
• [ ] Written a unit test if it works standalone, system.c especially
• [x] Considered possible null pointers and out of bounds array indexing
• [x] Changed no physics that affect existing maps
• [ ] Tested the change with ASan+UBSan or valgrind's memcheck (optional)

[def-]

Cool, looks like we're getting fancy new physics :)

[C0D3D3V]

new tunings should be added to the end of the list, or you fix the code where we use hard coded tuning indexes.

[C0D3D3V]

I think we should also add a version check in CGameContext::SendTuningParams (similar to the other version checks). Deen will hopefully clarify what the next version will be :) (or you break out of the pattern and check for the current version)

[AssassinTee]

I think we should also add a version check in CGameContext::SendTuningParams (similar to the other version checks). Deen will hopefully clarify what the next version will be :) (or you break out of the pattern and check for the current version)

Can you elaborate? I would set a paramter like VERSION_DDNET_ELASTICITY_TUNE = 17000 (to a yet not existing new version of DDNet)

[C0D3D3V]

@def- Do you want to release 16.2 or jump to 17? I would be fine with 16.2, to consider is that we have some major changes like the changed input handling...

@AssassinTee yes that would be the way... the question is only if you should use 16020 or 17000

[AssassinTee]

@C0D3D3V older clients can't handle elasticity at all, they would get prediction errors. I suggest doing a major break to 17000 for this

[AssassinTee]

@C0D3D3V do I need to upgrade the Client Version in this PR, too?

[C0D3D3V]

No deen releases new versions.

[def-]

16.2 is fine.

[def-]

bors r+

[heinrich5991]

bors r-

[bors[bot]]

Canceled.

[C0D3D3V]

@heinrich5991 I forgot why we canceled the merge. Do you remember? What is missing?

Ah I think it was because of the missing clamp for the valid elasticity range. But that was added, so I think it is ready for another review.

[AssassinTee]

@C0D3D3V @heinrich5991 I noticed one problem with this but this may be out of scope: you don't always get your doublejump back, this is inconsistent! The reason is that you are only touching the ground in a subtick and not in the tick before or after the touch. I would say, that this is out of scope for this issue and also changing this would change physics.

The workaround would be adding a flag to MoveBox and setting the jump values accordingly

[C0D3D3V]

If a mapper would like to force refill of dj, he could add a jump refill tile.

[heinrich5991]

Ah, I'd actually like to make this in-scope, so that we don't have a physics change due to this later on.

[heinrich5991]

What do others think?

[Chairn]

Fine by me.

[C0D3D3V]

Do we even want that the dj refills? I guess that way you could increase your jump hight with every bounce? I did not test yet the physic...

But on the other hand side, if you do not want to refill the jump you could also give the player 0 jumps

[heinrich5991]

Do we even want that the dj refills? I guess that way you could increase your jump hight with every bounce? I did not test yet the physic...

If we don't want them, it should be consistent that we don't get it.

[heinrich5991]

Status: There's still an unaddressed review comment.

[AssassinTee]

Status: There's still an unaddressed review comment.

I somehow missed this reviews, I already got the code for this, it just needs to be integrated! :) One side note: The sub-tick refill is only for slime blocks, since you can touch normal blocks in a subtick between ticks without getting your jump back and this is standard behaviour. In race we call this an edge-bug. My goal is not changing default physics at all

[heinrich5991]

Status: There's still an unaddressed review comment. Do you still want to work on this? @AssassinTee

[AssassinTee]

If we don't want them, it should be consistent that we don't get it.

I discussed this issue with heinrich a bit more in detail in discord, but here are the keynotes: You get the jump back based on ticks, but you can skip a ground-touch in a subtick by bouncing off of the block between two ticks, so I added a check, if you hit the ground in between in order to give the jump back (default behavior). You can't accelerate in stupid ways with it, because if you jump your speed is set to the ground or airjump speed (it's not additive).

Why do you only give the jump back, if the elasiticy > 0? Because I want to keep the subtick bug that is present in the current version.

[heinrich5991]

Thanks for your persistence!