DDraceNetwork - developer

def-

[ddnet-web:master] 1 new commit

5b30216 Add 10 € donation by Steppenwolf_123 - def-

Jupstar ✪

that's your choice If you rework the hud: the idea generally is to return the quad offset and have member variables named HUDHealthHeartOffset so its nicely readable but yeah i havent done that yet and to answer your question You could argue that its nicer to split it for more modularity, but mathematically and GPU wise its not wrong to reuse the same quad

like this: https://github.com/C0D3D3V/ddnet/commit/d7bbf944223f139bba66697a465de60a5aa9a55c

Small cleanup of HUD + comment on distance calculation at sound · C...

c0d3d3v

like this: https://github.com/C0D3D3V/ddnet/commit/d7bbf944223f139bba66697a465de60a5aa9a55c

yes

What was the intention to allow also the 0.7 quads? Couldn't we commit to one design?

do you mean the ninja bar?

no for the Armor, Ammo and Health display, extra quads were created that are slightly larger, 2 units to be exact. Which are used when using a 0.7 game.png (with the ninja bar)

10:24

I think Chillerdragon introduced that.

ah for the grenade maybe?

See https://github.com/ddnet/ddnet/commit/263fdbd8e17fb589f1d7ae2949a609cc85bfcb48

Use 0.7 gameskin by @Zatline · ddnet/ddnet@263fdbd

https://github.com/teeworlds/teeworlds/commit/a5105264ff9366c3bf5deb8aaa3aba7026640c46 https://github.com/teeworlds/teeworlds/commit/db0823950609859327ee96aea62271877d61d984 https://github.com/teew...

// special case for 0.7 grenade

10:29

rest are just quads for the new stuff in game.png i assume

10:29

implemented for future use xd

Well special case for everything, each of the displays is 2 units larger in width and height. We might as well take the same quads if we agree on a size.

or are they already used?

10:30

well anyway, that's bcs game.png is different for 0.7

They are used when you use a 0.7 game.png.

yes, guess 0.7 changed it a bit

Yes the shields and hearts are one unit on all sides smaller in the PNG so they decided to just make the quads bigger -.- oh man (edited)

10:32

Well, no matter, it's just another compatibility layer...

well vanilla has alot of weird flaws that are annoying xd

Mh I was wrong, only looked at first glance as if they are smaller, actually they are the same size, the reason was this https://github.com/teeworlds/teeworlds/issues/1624 (edited)

Ingame HUD is scaled smaller than on the bitmap · Issue #1624 · tee...

It seems as the tiles get slightly downscaled ingame with a gap inbetween there is definitely something not matching the original scale & spacing of the bitmap. what I suspect is this: how ...

yeah but we still need the compability

10:38

the 0.6 game.png looks too oversized else i think

ok, you are right looks really strange (edited)

def-

[ddnet-web:master] 1 new commit

697ab1e MEX flag - def-

def-

[ddnet/ddnet] Pull request opened: #4837 Fix demo render menu

As reported by bencie on Discord Old: !Screenshot 2022-03-18 at 14 23 53 New: !Screenshot 2022-03-18 at 14 30 44

Checklist

[x] Tested the change ingame
[x] Provided screenshots if it is a visual change
[ ] Tested in combination with possibly related configuration ...

@Robyt3 You once told me to use pointers instead of copying data, wouldn't that apply here as well or do you think there was a reason for that? https://github.com/ddnet/ddnet/blob/971f839c1792563b52fe65bd5d6de4495374cdcd/src/game/client/components/players.cpp#L87-L90 in RenderPlayer() too (edited)

ddnet/players.cpp at 971f839c1792563b52fe65bd5d6de4495374cdcd · ddn...

DDraceNetwork, a cooperative racing mod of Teeworlds - ddnet/players.cpp at 971f839c1792563b52fe65bd5d6de4495374cdcd · ddnet/ddnet

c0d3d3v

@Robyt3 You once told me to use pointers instead of copying data, wouldn't that apply here as well or do you think there was a reason for that? https://github.com/ddnet/ddnet/blob/971f839c1792563b52fe65bd5d6de4495374cdcd/src/game/client/components/players.cpp#L87-L90 in RenderPlayer() too (edited)

I think the copies of the CNetObj_Character objects could be avoided, as the objects are not being modified, but the CTeeRenderInfo is changed so it needs to be a copy

Yea i still occasionally join until i get in a beef with staff and rq. Thats why I was suprised i can not remember you. Its probably the length of your name that is to blame. (@f)

f.

@ChillerDragon you don't no me? i know you

korean.txt

19.08 KB

16:28

I edited the Korean translation file that I posted last time

16:30

Could you developers pull request it?

Thank you, will add it

1

Thankss

def-

[ddnet/ddnet] Pull request opened: #4838 Update Korean language file (by 車魄)

Checklist

[ ] 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--u...

bencie

[ddnet/ddnet] Pull request opened: #4839 Update hungarian.txt

added missing translations, fixed/improved a few old translations.

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...

Is there actually a reason why we no longer predict the gameworld, including character, in a demo playback? I have tried a few demos and see no reason not to predict the world. https://github.com/ddnet/ddnet/blob/940032ef269e6d98772f8d867367e63c1b8bfab7/src/game/client/gameclient.cpp#L1671-L1672 This would be helpful e.g. the plan in the new HUD is to display the available jumps and the information is only available in the predicted characters.

ddnet/gameclient.cpp at 940032ef269e6d98772f8d867367e63c1b8bfab7 · ...

DDraceNetwork, a cooperative racing mod of Teeworlds - ddnet/gameclient.cpp at 940032ef269e6d98772f8d867367e63c1b8bfab7 · ddnet/ddnet

bors[bot]

[ddnet:master] 3 new commits

202402d Update hungarian.txt - bencie aeec707 Update hungarian.txt - bencie 51acc88 Merge #4839 - bors[bot]

18:14

bors[bot]

[ddnet/ddnet] Pull request closed: #4839 Update hungarian.txt

bors[bot]

[ddnet:master] 4 new commits

748fb0e Add contributor - def- 71432bd Fix demo render menu - def- b1c53d6 Update Korean language file (by 車魄) - def- 3fa7edc Merge #4837 #4838 - bors[bot]

18:36

bors[bot]

[ddnet/ddnet] Pull request closed: #4837 Fix demo render menu

18:36

bors[bot]

[ddnet/ddnet] Pull request closed: #4838 Update Korean language file (by 車魄)

c0d3d3v

Is there actually a reason why we no longer predict the gameworld, including character, in a demo playback? I have tried a few demos and see no reason not to predict the world. https://github.com/ddnet/ddnet/blob/940032ef269e6d98772f8d867367e63c1b8bfab7/src/game/client/gameclient.cpp#L1671-L1672 This would be helpful e.g. the plan in the new HUD is to display the available jumps and the information is only available in the predicted characters.

Why do you need to predict something when you have all the data?

def-

[ddnet/ddnet] Pull request opened: #4840 Update Chinese translations (by cheeser0613)

Checklist

[ ] 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--u...

svg assets support when™️?

when there are enough assets for it

19:15

aka all of mapres

19:15

and i do Not want to do tilesets man ;_;

deen

Why do you need to predict something when you have all the data?

Ah only with server demos there is no character data, with client demos is unclear whether the data is complete, I'm still looking, well one takes what one gets

does anybody here know how to enable "true ping"?

20:01

im working on something network related, that seems helpfull

JSaurusRex

does anybody here know how to enable "true ping"?

to explain it better this is what he wants enabled

20:03

the number in the top right

cl_showpred figured it out

bors[bot]

[ddnet:master] 2 new commits

af8d5c8 Update Chinese translations (by cheeser0613) - def- 69d7ea5 Merge #4840 - bors[bot]

20:39

bors[bot]

[ddnet/ddnet] Pull request closed: #4840 Update Chinese translations (by cheeser0613)

deen

Why do you need to predict something when you have all the data?

Since only tees in the own team have a CCharacter, (and also only if they are not solo) these have also only the m_JumpedTotal set. Not even specteated tees get a CCharacter and therefore have no m_JumpedTotal value. How about if we transfer m_JumpedTotal in the CNetObj_DDNetCharacter to the client? Can I just do that?

deen

Why do you need to predict something when you have all the data?

I think it makes sense to have the data (m_JumpedTotal) in the client, I now understand that once you go into spec the whole gameworld is no longer predicted and therefore the values (m_JumpedTotal) are not there for other players. Whether we want the display at the end is another question, I have now watched the jumps display a few hours while debugging and I'm pretty sure some people will find it annoying

but I'm only there to implement the display. The discussion about the new display will come later

Couldn't we keep track of m_JumpedTotal in client?

We would have to execute every gametick in the gameworld for every player (just calculate the tick for CCharacterCore with user input would be enough) that we spectate. And actually we would need to do this before we spectate him, to make the display already correct when we jump into the spectating view. We do not do that at the moment. Are so edge cases that are then messy. If you want to see the HUD with the jump display of other teems, you would also have to calculate their ticks. These are all unnecessary calculations that are then only used to display the jumps xD I think to send the information to the client is more useful, for the own player I would get the jumps from the Predicted GameWorld, which then also looks in sync at high ping and for all others from the transmitted infromation in CNetObj_DDNetCharacter, if you are in spectating then the world is not predicted anyway and then that is also in sync.

Alternative would be to make no jump display and only show how many jumps you have in total, and not show how many of them you have used up. This information is already sent in CNetObj_DDNetCharacter. (edited)

yeah, that sounds like the easiest solution for now

srdante

[ddnet/ddnet] Pull request opened: #4841 Fix player death effect color

Fixes #4836

Checklist

[ ] 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-add...