4095: [Concept] Add new mouse state (ingame mouse) r=def- a=Jupeyy
This would remove ui_mousesense and use the desktop cursor position instead for menus and editor
This would also fix the editor cursor to not move faster than in menus.
That's probably how most games would handle menus, instead of using relative mouse mode
And this would work for touch inputs.
The normal gameplay relative mouse is ofc NOT affected by any kind
Opinions?
Missing:
- [x] m_MouseSlow in menus
- [x] Make desktop cursor invisible
- [x] Some components that use ui mouse
- [x] Remove focus in/out relative mouse state changes, fixed with next SDL version
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
4176: Entity switch prediction r=def- a=trml
Adds the prediction for pickups and projectiles (based on #4108)
For blinking entities (deactivated by switch) I also used the extended info to make the blinking effect happen client-side. So instead of the server omitting the projectile/pickup from the snapshot every N ticks (which prevented some things like explosive bullets from being predicted correctly), the server will keep sending the item and let the client decide how to show it.
Added doors as well, and changed how they are sent (and rendered) in a similar way (by always sending both endpoints and using a fixed m_StartTick instead of updating it every tick).
An idea was that this could potentially reduce network traffic a bit (in addition to helping with prediction), especially for stationary items that are rarely/never have to be updated (doors and pickups).
This makes CItems::OnRender a bit more complex, and it could perhaps be cleaned up some way (either using something like CProjectileData, or by moving more of the logic into RenderProjectile/Laser/Pickup).
Some things missing:
- Add more entities (draggers, light, gun)
- Entities are not correctly shown when in super (e.g. doors are shown as closed, and should be open)
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [ ] 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](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: Jupeyy <jupjopjap@gmail.com>
Co-authored-by: trml <trml@users.noreply.github.com>
3077: UI Elements r=def- a=Jupeyy
Build will fail bcs of clang-format,
i'll update this comment to explain.
Co-authored-by: Jupeyy <jupjopjap@gmail.com>
Purely automatic change. In case of conflict with this change, apply the
other change and rerun the formatting to restore it:
$ python scripts/fix_style.py
To allow server to set any x_ prefixed skin and client won't filter it
out. As requested by Pure_luck for his mod to show players as tanks,
walls, etc. Won't be enabled on DDNet-Servers, thus such skins can be
added where a server modification wants to fine-control what skins are
allowed and can enforce such skins.
- Fix a use-after-free when there are no new snapshots for the cl_dummy tee after the switch.
- When one of the tees is hooked, cycling through them will no longer show phantom hook for the other tee.
- Dummy switch might happen a bit quicker since it doesn't depend on receiving new snapshots.
- Simplified code: m_LastDummy2 is no more.
This gets rid of the problem that we don't know whether we should send
full snapshots to clients because they haven't told us about them being
DDNet yet.
1904: Add tune zone prediction r=heinrich5991 a=trml
Is enabled with cl_predict_ddrace 1.
This will predict tunings loaded from the map the first time tunezones are entered, but will also update the tunes after you receive new tunes while in a tunezone, since it's possible to change them in rcon.
Co-authored-by: trml <trml@users.noreply.github.com>
Edgar
ChillerDrgon
