15:45 < bridge> [teeworlds] is there way to get a player's ip + port in the gamecontext? like GetClientAddr() which seemingly only returns the IP 15:46 < bridge> [teeworlds] without modifying the source. 16:34 < bridge> [teeworlds] without modifying probably not 16:35 < bridge> [teeworlds] but using econ you can sneak it 16:35 < bridge> [teeworlds] as econ has access to status command and/or can check the logs, and in the join leave msgs you get the full ip 16:35 < bridge> [teeworlds] + port 16:49 < bridge> [teeworlds] "in the gamecontext" sounds like not modifying source other than gamecontext.cpp 17:15 < bridge> [teeworlds] yeah, but seemingly adding an optional parameter to GetClientAddr() that's default to false is the only not hacky way 17:28 < bridge> [teeworlds] @ChillerDragon https://github.com/teeworlds/teeworlds/issues/2475 any feedback in regard to the patch? 17:28 < bridge> [teeworlds] that's in the comment 17:49 < bridge> [teeworlds] #development 17:49 < bridge> [teeworlds] ah the patch sry didnt read 17:51 < bridge> [teeworlds] im not too sure tbh 17:51 < bridge> [teeworlds] i like to complain about the logging but im still agianst changing it :/ 17:51 < bridge> [teeworlds] its just a mess to maintain two versions of logging then to support older versions 17:52 < bridge> [teeworlds] also multiple logs might give you insight on errors when a client disconnects during connection in which stage it happend or similar cases 17:54 < bridge> [teeworlds] well, the patch only removes one specific line when joining by adding a player name and the disconnect messages were added that contain 17:55 < bridge> [teeworlds] nick, id, ip, port 17:55 < bridge> [teeworlds] https://github.com/teeworlds/teeworlds/issues/2475#issuecomment-590090413 17:56 < bridge> [teeworlds] ye i red the patch 17:57 < bridge> [teeworlds] the granularity more or less stays 17:57 < bridge> [teeworlds] still every logparser has to be rewritten 17:58 < bridge> [teeworlds] and every logparser that wants to support the olg version as well has to maintain duplicated code 17:58 < bridge> [teeworlds] old* 17:58 < bridge> [teeworlds] do you use that one line that has been removed? 17:58 < bridge> [teeworlds] one line? 17:58 < bridge> [teeworlds] didnt you remove multiple 17:58 < bridge> [teeworlds] well i use them all but i guess its not about me 17:59 < bridge> [teeworlds] me having to rewrite a parser shouldnt be a holdback to refactor tw 17:59 < bridge> [teeworlds] player joined... 17:59 < bridge> [teeworlds] that's the only line removed and replaced 17:59 < bridge> [teeworlds] to contain nick, id, ip, port 18:00 < bridge> [teeworlds] also now one would only need to parse for two lines without any complext logic 18:00 < bridge> [teeworlds] complex* 18:00 < bridge> [teeworlds] server_join, server_leave 18:00 < bridge> [teeworlds] ye ikr 18:00 < bridge> [teeworlds] parsing two lines is annoying 18:01 < bridge> [teeworlds] but didnt you duplicate information now? 18:01 < bridge> [teeworlds] maybe it would be best if you could show a diff of the actual log output 18:01 < bridge> [teeworlds] in my opinion the logs are not consistent 18:02 < bridge> [teeworlds] gotta look in my copy history x) 18:16 < bridge> [teeworlds] is commented 18:23 < bridge> [teeworlds] ty 18:24 < bridge> [teeworlds] seems likes its two times your patch tho so not very comparable 18:28 < bridge> [teeworlds] @jxsl13 18:28 < bridge> [teeworlds] 1. add =false to the other header too for port 18:28 < bridge> [teeworlds] 2. i dont like that the gamecontext is handling the message. the engine is aware of networking stuff and the client states and should also handle these messages. The GAME context is for the GAME stuff imo 18:29 < bridge> [teeworlds] But I agree that the messages should be simplified, but as said not from gamecontext 18:32 < bridge> [teeworlds] is the engine aware of nickname? 18:32 < bridge> [teeworlds] of course 18:32 < bridge> [teeworlds] Lol 18:32 < bridge> [teeworlds] *server()* ->clientname xd 18:32 < bridge> [teeworlds] the problem is actually those ingame states 18:33 < bridge> [teeworlds] what do you mean 18:33 < bridge> [teeworlds] the engine also drops players before they are even properly connected to the server 18:33 < bridge> [teeworlds] and then loose their connection 18:33 < bridge> [teeworlds] or disconnect 18:33 < bridge> [teeworlds] and how is it a problem? 18:34 < bridge> [teeworlds] dont log these i guess 18:34 < bridge> [teeworlds] are those connecting -> ready -> enter handled by the engine as well? 18:34 < bridge> [teeworlds] yes 18:36 < bridge> [teeworlds] then gotta take a look there 18:37 < bridge> [teeworlds] https://github.com/teeworlds/teeworlds/blob/master/src/engine/server/server.cpp#L692 18:37 < bridge> [teeworlds] take a look here for example 18:37 < bridge> [teeworlds] the engine even calls the gamecontext function 18:38 < bridge> [teeworlds] https://github.com/teeworlds/teeworlds/blob/master/src/engine/server/server.cpp#L926 18:38 < bridge> [teeworlds] aswell as the joining 18:51 < bridge> [teeworlds] moving it to engine/server makes the Port parameter obsolete 18:51 < bridge> [teeworlds] (Y) 20:03 < bridge> [teeworlds] i got some really weird bugs with sv_high_bandwith 20:03 < bridge> [teeworlds] for me the ping(!) gets better and for others it gets worse 20:03 < bridge> [teeworlds] and it's not a local server 20:13 < bridge> [teeworlds] good ping -> better, bad ping with a lot of packet loss -> gets worse 20:13 < bridge> [teeworlds] that was kinda the result of the previous discussion here.