03:33 <+bridge> i wonder if its my fault xd 04:08 <+bridge> I have a question concerning .cfg-files for toggling key-bindings / commands. Guess it's a bit too trivial to be postet in the the developer-Chatroom, but maybe someone can take a look at it anyway 😄 04:08 <+bridge> So I am currently trying to fix a problem with some .cfg-scripts that toggle some binds. 04:08 <+bridge> 04:08 <+bridge> THE GOAL OF THESE BINDS / SCRIPTS WAS: 04:08 <+bridge> - To have zoom+ and zoom- bound to mousewheel up and down when the pause-button is pressed; 04:08 <+bridge> - and bound back to default prevweapon / nextweapon bindings when leaving pause-mode by hitting the pause button a second time. 04:08 <+bridge> 04:08 <+bridge> MY APPROACH LOOKED LIKE THIS (simple bind-toggles set in .cfg-files, ) 04:08 <+bridge> I changed the binding of my pause-key 'q', 04:08 <+bridge> which previously had simply been: 04:08 <+bridge> bind q "say /pause" 04:08 <+bridge> 04:08 <+bridge> to execute a .cfg-file in addition to the /pause command: 04:08 <+bridge> bind q "say /pause; exec mousewheelZoomON.cfg 04:08 <+bridge> 04:08 <+bridge> mousewheelZoomON.cfg: 04:08 <+bridge> bind mousewheelup "zoom+" 04:08 <+bridge> bind mousewheeldown "zoom-" 04:08 <+bridge> bind mouse3 "zoom" 04:09 <+bridge> bind q "say /pause; exec mousewheelZoomOFF.cfg" 04:09 <+bridge> 04:09 <+bridge> mousewheelZoomOFF.cfg: 04:09 <+bridge> bind mousewheelup "+prevweapon" 04:09 <+bridge> bind mousewheeldown "+nextweapon" 04:09 <+bridge> bind mouse3 "zoom" 04:09 <+bridge> bind q "say /pause; exec mousewheelZoomON.cfg" 04:09 <+bridge> NOW TO THE THE PROBLEM: 04:09 <+bridge> 04:10 < bridge> I have a question concerning .cfg-files for toggling key-bindings / commands. Guess it's a bit too trivial to be postet in the the developer-Chatroom, but maybe someone can take a look at it anyway 😄 04:10 < bridge> So I am currently trying to fix a problem with some .cfg-scripts that toggle some binds. 04:10 < bridge> 04:10 < bridge> **THE GOAL OF THESE BINDS / SCRIPTS WAS:** 04:10 < bridge> - To have zoom+ and zoom- bound to mousewheel up and down when the pause-button is pressed; 04:10 < bridge> - and bound back to default prevweapon / nextweapon bindings when leaving pause-mode by hitting the pause button a second time. 04:10 < bridge> 04:10 < bridge> **MY APPROACH LOOKED LIKE THIS (simple bind-toggles set in .cfg-files, )** 04:10 < bridge> I changed the binding of my pause-key 'q', 04:10 < bridge> which previously had simply been: 04:10 < bridge> bind q "say /pause" 04:10 < bridge> 04:10 < bridge> to execute a .cfg-file in addition to the /pause command: 04:10 < bridge> bind q "say /pause; exec mousewheelZoomON.cfg 04:10 < bridge> 04:10 < bridge> ** *mousewheelZoomON.cfg:*** 04:13 < bridge> **I have a question concerning .cfg-files for toggling key-bindings / commands**. Guess it's a bit too trivial to be postet in the the developer-Chatroom, but maybe someone can take a look at it anyway 😄 04:13 < bridge> So I am currently trying to fix a problem with some .cfg-scripts that toggle some binds. 04:13 < bridge> 04:13 < bridge> **THE GOAL OF THESE BINDS / SCRIPTS WAS:** 04:13 < bridge> - To have zoom+ and zoom- bound to mousewheel up and down when the pause-button is pressed; 04:13 < bridge> - and bound back to default prevweapon / nextweapon bindings when leaving pause-mode by hitting the pause button a second time. 04:13 < bridge> 04:13 < bridge> **MY APPROACH LOOKED LIKE THIS (simple bind-toggles set in .cfg-files, )** 04:13 < bridge> I changed the binding of my pause-key 'q', 04:13 < bridge> bind q "say /pause; exec mousewheelZoomON.cfg" 04:15 < bridge> I remember you could do `/spec 0` and `/spec 1` I might be wrong I can't test it right now. The same for pause. 04:21 < bridge> Tried to enter these in chat, doesn' seem to behave different than just /spec 04:31 < bridge> https://gist.github.com/jamiephan/0c04986c7f2e62d5c87c4e8c8ce115fc 04:31 < bridge> quixel megascans is free right now. you can just bot the site and get everything 04:35 < bridge> indie games with all megascans assets are gonna blowup next year lmao 04:37 < bridge> so /spec 0 will still put you in spec ? 04:38 < bridge> I mean we could certainly add these values, but is it really useful at all? - (this could be fixed by bind groups btw) :KEKW: 04:38 < bridge> yup 04:38 < bridge> whoever thought it was a good idea to make it free is either a gigachad tired of corporative methods, or a dumbass messing up with an idiot marketing strategy 04:38 < bridge> @archimede67 I hope you're doing fine and well btw - didn't see you for a while 04:38 < bridge> in my eyes, gigachad :gigachad: 04:38 < bridge> it's just trying to move everyone to the new market place. typical epic game manuver 04:39 < bridge> if it's free, we all gucci 04:39 < bridge> they are just gonna shutdown the site and transfer everything to fab. then you have to login to fab to download all your free stuff. they get the chance of shoving more paid stuff in your face. 04:39 < bridge> it was free for unreal engine before anyway 04:40 < bridge> non-unreal people probably doesn't use megascans that much 04:40 < bridge> most of megascans stuff are paid, so yeah no way this'll pop up 04:40 < bridge> but the free stuff surely made people's eye attracted to them 04:40 < bridge> userbase conversion maneuver 04:41 < bridge> once the free stuff is gone, back to everyday suffer 04:41 < bridge> epic make terrible market place that is true tho 04:41 < bridge> mind you, we don't have any good ones either 04:42 < bridge> i'm mostly talking about steam and egs :greenthing: 04:43 < bridge> oh, epic games in general is shit, it's obv 04:43 < bridge> oh wait what if steam decided to sell assets :think_bot: 04:43 < bridge> Till Gabe died, it won't happen 04:43 < bridge> Till Gabe dies, it won't happen 04:43 < bridge> gabe will probably live in a machine somewhere forever 04:44 < bridge> I would say the Steam market cannot be worse, unless the revenue drops up because of CEO change. 04:45 < bridge> other than that only, Steam is a well done game store service. 04:46 < bridge> Epic ain't, their shit practices on giving away free games are not better, than giving away discounts like Steam does. Their terms of service practices makes use realize they only care about money, while Steam throws it away with plenty of discounts and somehow earns more 04:46 < bridge> Epic does everything to shoot themselves in the foot, while Steam does nothing and wins 04:50 < bridge> to conclude: you can get in spec-mode with both, /spec 0 and /spec 1 (and just /spec obviously), but for getting out of spec-mode neither /spec 0 nor /spec 1 do anyting. 06:29 < bridge> It always was yes 06:29 < bridge> It was Always yes 10:24 < bridge> Realizing the feature I want needs data that is modeled as a directed acyclical graph which turns out to be super annoying to model, maintain, and query in a relational DB. Really fun. 10:27 < bridge> Leave 10:28 < bridge> Leave? It's my project? xD 10:35 < bridge> who is this guy? Is this a discord account? 10:35 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1289868076199837747/image.png?ex=66fa62c1&is=66f91141&hm=303b0c0d1297dde156b8783a822fc4240d7c354325ab4fc07578b1b5e3480618& 10:35 < bridge> I thought it was one of the bridges 10:35 < bridge> they seem to have left 10:35 < bridge> maybe they tried to leave xd 10:35 < bridge> not tell u to leave 10:35 < bridge> xd 10:35 < bridge> haha 10:36 < bridge> he said what he had to say and left 10:39 < bridge> protocol experts: 0.7 protocol has no svglobalsound, did it move somewhere? 10:55 < bridge> @gerdoe https://chillerdragon.github.io/teeworlds-protocol/shared/06_vs_07.html#sound 10:57 < bridge> thank you chiller 10:58 < bridge> also do you know what Sv_VoteOptionListAdd does? 10:58 < bridge> its empty structure 10:58 < bridge> it adds votes 10:58 < bridge> no its dynamic 10:58 < bridge> dont trust network.py 10:58 < bridge> only trust the chillerdragon docs xd 10:59 < bridge> https://chillerdragon.github.io/teeworlds-protocol/07/game_messages.html#NETMSGTYPE_SV_VOTEOPTIONLISTADD 10:59 < bridge> yeah checked it rn 11:00 < bridge> do you remember any other dynamic structures in protocol? 11:01 < bridge> game messages 11:01 < bridge> https://chillerdragon.github.io/teeworlds-protocol/07/game_messages.html#NETMSGTYPE_SV_GAMEMSG 11:02 < bridge> besides game messages xd 11:02 < bridge> i dont remember any others 11:12 < bridge> > rempved 11:13 < bridge> chiller plz fix 11:13 < bridge> go pr 11:14 < bridge> it is generated or it really is just pure html 11:14 < bridge> pure html 11:14 < bridge> eww 11:15 < bridge> simple by design 11:16 < bridge> done 11:16 < bridge> github online editor moment 11:21 < bridge> seems i will not support 0.7 :troll: 11:24 < bridge> where? 11:24 < bridge> kinda nowhere rn 11:25 < bridge> where 11:25 < bridge> here 11:25 < bridge> @gerdoe ? 11:27 < bridge> theres nothing currently 11:27 < bridge> i just came back to my old project based on libtw2 11:28 < bridge> also i wonder why gamemsg id itself is not present in network.py 11:28 < bridge> it doesnt have to by dynamic xd 11:29 < bridge> yea but it would be unused. maybe its helpful to understand that its not a fixed struct 11:29 < bridge> i currently have a pending pr that would add such network.py breaking black magic to ddnet 11:31 < bridge> wdym unused 11:32 < bridge> if it is always red and written with GetInt and AddInt then the network.py fields are unused 11:33 < bridge> it could be used for validating the allowed range 11:33 < bridge> thats actually what i did in mine for ddnet 11:33 < bridge> I still wonder why `serbian` translation has more finished strings than `serbian_cyrilic` 11:36 < bridge> Also, `serbian` has both Latin and Cyrilic strings, for some reason 11:37 < bridge> Nice 11:53 < bridge> "Decoration"??? 11:53 < bridge> One of the 0.7 skin parts 11:54 < bridge> Would like a screenshot... 11:55 < bridge> See the "after" screenshots in #8940, they should mostly be accurate 11:55 < bridge> https://github.com/ddnet/ddnet/pull/8940 11:56 < bridge> Okay, thanks 12:05 < bridge> Waiting for the merge... 12:16 < bridge> enhancing my calm 😬 12:16 < bridge> <_lemon_ch_> hi 12:23 < bridge> Phew 12:23 < bridge> It still uses my old avatar! 14:54 < bridge> @chillerdragon @chillerdragon.9502 Ctrl+p doesn't have go to tele or go to x y cordinates 15:12 < bridge> `[Client] Smooth spectating [KebsCS]` 15:12 < bridge> now add smooth spectating for "multi-view" button :DD 15:15 < bridge> please make it so that the HUD panels can be moved as you want, or at least limitedly 15:15 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1289938708627456124/image.png?ex=66faa48a&is=66f9530a&hm=63c67801b579f221e40002809ef5dd560e60fcde579bb03406ba073a19b1b0f9& 15:20 < bridge> Fairly big change. I wouldn't expect it unless there is a dev around that also wants it 15:21 < bridge> I think it would be useful, this change is not very different from those described here ---, but it is quite useful and I think it will not be particularly difficult 15:32 < bridge> if you think it won't be difficult, go pr! 15:35 < bridge> yay im in the credits :D 16:08 < bridge> @robyt3 hey i have a question about https://github.com/ddnet/ddnet/pull/7555 16:08 < bridge> Its atm a 364 line change, pretty maintainable imo 16:08 < bridge> but if the server side code is too much to maintain can the client side + networking message at least be merged? 16:08 < bridge> then servers can implement their own physics without ddnet having to support them 16:08 < bridge> <0xdeen> Thanks for all the cool features! 16:48 < bridge> I'm still not convinced that this adds value for DDNet. Looks hard to maintain when changes would also need to be tested on other tick rates. As of now, I don't really see any maintainer actively supporting this except heinrich5991 maybe, but I'm not sure from the comments whether you convinced him that this should be added to DDNet. 16:49 < bridge> Don't think I convinced him, he was just cleaning up the code iirc 16:50 < bridge> does this still hold true for purely client side support as well? that should massively cut down on scope 16:55 < bridge> IMO not having a standard server implementation available to test also makes it harder to maintain 16:55 < bridge> ah damnit thats true xd 16:56 < bridge> if there were automated tests this wouldn't be nearly as much of an issue 16:56 < bridge> i tried to make those but got stuck pretty early on sadly 17:02 < bridge> assuming the amount of servers that will use it is very small (because ddrace, race and gores are the biggest modes and just don't work well with such a physics change) 17:02 < bridge> is it possible to add this as an non officially supported feature, as in. Its in the ddnet client but won't be actively maintained so breakage can happen? 17:05 < bridge> I'd rather not have a completely unmaintained feature. This would be a better fit for a custom client based on DDNet if only few servers are going to use it. 17:08 < bridge> dang D: 17:08 < bridge> yeah very true, the sad reality is tho that any feature that requires a custom client is unlikely to be used 17:08 < bridge> if there were to be automated tests would this pr be considered? 17:09 < bridge> with tests you could 1line ever of these functions 17:09 < bridge> https://github.com/ddnet/ddnet/pull/7555/files#diff-d76009083687ba43c59dc7bb2c7357457c999c2eb9d913967d598e913c6fd01fR757-R786 17:09 < bridge> since they don't really change behavior (in theory xd) 17:10 < bridge> i think the bigger problem is that individual features need to be properly suppoted 17:10 < bridge> i think the bigger problem is that individual features need to be properly supported 17:10 < bridge> like laser beams i had to manually add 17:10 < bridge> and some stuff was made with scalability in mind had it written backwards 17:11 < bridge> a convert position like here: 17:11 < bridge> https://github.com/ddnet/ddnet/pull/7555/files#diff-619bc2285dfceebaa74c335ad9df122d2cc19e665de4536801ccf63c4ab80714R204 17:11 < bridge> 17:11 < bridge> could be refactored out, if the rendering component wouldn't use the network positions but some normalized format. So that this line exist is also fault of bad ddnet impl 17:11 < bridge> i don't think these functions even need to be tested because they're indeed likely to not change 17:11 < bridge> kebs is doing lotta work 17:11 < bridge> i am defs very intersted in the physics code changes of this high tick support. i think they are rather small totally 17:12 < bridge> perfect for dd-pg 😄 17:12 < bridge> i can add them if you want 17:13 < bridge> in a previous rendition of this pr i converted all cnetobj_character(core) to ccharacters to use simplify it 17:13 < bridge> if thats what you mean 17:13 < bridge> i mean that the positions should be 1 float unit = 1 ingame tile 17:13 < bridge> ended up changing it because it added a lot of new lines and also wasn't very clear when read why 17:13 < bridge> and not _randomly_ scaled by some network factor 17:14 < bridge> then the convertpos would be in whatever converts network pos to render pos 17:14 < bridge> and not in some client render compnent 17:14 < bridge> and not in some client render component 17:14 < bridge> it converts network pos to rendering and in game pos 17:14 < bridge> yep, sadly the ddnet code base mixes lots of stuff like this 17:14 < bridge> 1 float unit stays the same, its purely for the networking which doesn't use floats that i had to scale it 17:15 < bridge> btw will this get its own client? 17:15 < bridge> or is it purely server sided? 17:15 < bridge> 😎 17:15 < bridge> yes 17:15 < bridge> dang, backwards compatible? 17:15 < bridge> a client & server where physics can be controlled with WASM modules 17:15 < bridge> no 17:15 < bridge> O: 17:16 < bridge> i think you can add backwards compatibility with WASM modules 17:16 < bridge> if you detected the server type like ddnet does, depends how much you changed the original code tho 17:16 < bridge> the biggest challenge is backcompat in the network code, and that is what i am not interested in 17:16 < bridge> clients not compatible with ddnet servers are ... unlikely to take off 17:16 < bridge> since i think ddnet network is pretty hard to understand and at least currently not cleanly abstracted away 17:17 < bridge> dang, you're just interested in creating the best version of teeworlds possible? 17:17 < bridge> well the new servers need database access to official ddnet ofc at some point 17:17 < bridge> teeworlds 0.8 O: 17:17 < bridge> haha, 17:17 < bridge> 17:17 < bridge> with infinite time, defs 17:17 < bridge> ofc it won't be finished or perfect when i go public with it 17:17 < bridge> but until then i try my best 17:18 < bridge> whilst i think its cool and wanna add to it 17:18 < bridge> i know from personal projects, getting players is hard as shit 17:18 < bridge> you might as well be making a new game 17:18 < bridge> depends mostly on how much ddnet maintainers likeit 17:18 < bridge> depends mostly on how much ddnet maintainers like it 17:18 < bridge> you're gonna add support for the client to ddnet? 17:18 < bridge> if we "advertise" it in some form it can also take off 17:18 < bridge> the other way around than i suggested 17:19 < bridge> fake 17:19 < bridge> well it's not a me decision 17:19 < bridge> i mean is that the intend? 17:19 < bridge> i won't be able to carry such a huge project for ever. 17:19 < bridge> 17:19 < bridge> if other devs here like it, then maybe it can be an alternative to the current client 17:20 < bridge> the intend is mostly to enhance mod support without thinking about consequences of compbat all the time 17:20 < bridge> thus it's kinda an alternative client 17:21 < bridge> im definitely willing to help, i can see many technical short comings to the current client, stuff all my prs and servers try to fix. 17:21 < bridge> Ping, limited tickrate, inperfect inputs 17:21 < bridge> i actually was thinking about making a pr to add roughly what you had in mind to ddnet itself 17:21 < bridge> sure, start to learn rust today 😏 17:21 < bridge> D: rust 17:22 < bridge> thats gonna be something to get used to 17:22 < bridge> indeed 17:22 < bridge> i cannot tell for sure, but i think there are quite some rust devs in this chat 17:22 < bridge> seems like younger ppl rather learn that than cpp 17:23 < bridge> its the hot new item i think 17:23 < bridge> i usually just code in c tho ._. 17:41 < bridge> whats always annoyed me as someone who uses a low max distance is that the accuracy of my gun is limited due to the client rounding the mouse coords to ints instead of using floats (same amount of space) or using a single float direction (less space) 17:41 < bridge> i fixed this by removing all the rounding and where it needs to be converted to ints i just multiply it by 1024 17:41 < bridge> would this be accepted as pr? 17:46 < bridge> this would also affect the default distance wouldn't it? also how would it work when zoomed in/out etc? 17:47 < bridge> doesnt effect anything since normalize(vec2(x, y)) == normalize(vec2(x * 1024, y * 1024)) 17:47 < bridge> Does it affect the use of angle bind? 17:47 < bridge> (whats angle bind) 17:47 < bridge> You lower your max distance to 2, so that you can shoot directly up 17:48 < bridge> well thats an exploitation of the bug 17:48 < bridge> so yes 17:48 < bridge> Very commonly used bind 17:48 < bridge> but given you set the multiplier to a low enough number you can keep the best of both worlds 17:48 < bridge> Community would have a lot of backlash against that, so I doubt you'd pass it 17:49 < bridge> it could be a toggle? 17:49 < bridge> (or a slider) 17:49 < bridge> You'd also have to convince the people that use lower max distances with the way it currently works, they like the limited angles 17:49 < bridge> they do? 17:49 < bridge> Ya 17:49 < bridge> In PVP 17:49 < bridge> Usually 17:50 < bridge> it means i have to use a bind to do anything precise 17:50 < bridge> also yeah u can just lower the number to 128 and the max distance 2 still works 17:52 < bridge> but if poeople like reduced angles u can make it a slider or toggle there shouldnt be anything wrong with that 17:52 < bridge> Would almost definitely have to be a toggle, no one here knows if that'll be accepted or not, you could make a PR and have people discuss it on github 17:52 < bridge> you could use it in your own client - but the angle bind is a mechanic often used - espacially in hard maps actually 17:53 < bridge> angle bind works fine when u use 128 17:53 < bridge> still unsure about a feature that can break existing binds 17:53 < bridge> well have it off by default 17:53 < bridge> and people who play low distance (with high accuracy) but still want angle keybind can just toggle the thing in the keybind 17:54 < bridge> You gotta convince admins, not us :greenthing: 17:54 < bridge> i think it's best to open an issue on github about it 17:54 < bridge> hehe oke 17:54 < bridge> (maintainers) - not all maintainers are admins 17:55 < bridge> Ya, but admins decide regardless 17:55 < bridge> it also fixes a random thing on infclass where i cant select classes without dyncamming xd 17:56 < bridge> since the server now thinks that my mouse is off in narnia 18:01 < bridge> tf 18:01 < bridge> same 18:02 < bridge> you play w/ low max distance and like it? 18:02 < bridge> i can see it being nice for getting those really annoying hooks thru corners for saving ppl 18:02 < bridge> I don't 18:02 < bridge> thats the main thing 18:02 < bridge> But I know people do 18:05 < bridge> ^ oh look thats me 18:11 < bridge> Liar 18:11 < bridge> I wish 18:11 < bridge> you use low max distance and *dont* like the low precision? 18:12 < bridge> i use 380 and it isnt noticable 18:12 < bridge> its only noticable < 100 18:12 < bridge> i use 30 x-x 18:12 < bridge> how 18:12 < bridge> on gods earth 18:12 < bridge> you move your mouse in the direction you want the gun/hook to point 18:13 < bridge> rather than the object you want to murder 18:13 < bridge> its like playing bopple battle with a controller instead of a mouse 18:13 < bridge> or minecraft... 18:13 < bridge> or literally any fps 18:13 < bridge> well fps is a bit 18:13 < bridge> its just a different way of controlling 18:18 < bridge> wait in some places the position is multiplied by zoom? 18:18 < bridge> oh 18:18 < bridge> shoiuldnt it be divided? 18:18 < bridge> or wait 18:18 < bridge> :justatest: 18:19 < bridge> theres too many coordinate sysrtems going on 18:19 < bridge> i thought the mouse posiiton was client viewport space in pixels 18:19 < bridge> i thought the mouse posiiton was client viewport space in pixels from middle 18:19 < bridge> unless its.. not 18:20 < bridge> and i assume mods would assume that the client cannot zoom so you want to preserve the mouse position regardless of zoom level 18:20 < bridge> agh 18:22 < bridge> and why does the hook collision render code have so many angle calculations 18:23 < bridge> you need 1 18:24 < bridge> Azerbaijanese sounds like someone not from Azerbaijane tried to name the language 18:24 < bridge> Azerbaijanese sounds like someone not from Azerbaijan tried to name the language 18:27 < bridge> yes im from turkey 18:28 < bridge> apparently its meant to be Azerbaijani [language] or Azeri 18:28 < bridge> There's an issue for this already ket me find it 18:28 < bridge> apparently its meant to be Azerbaijani [language] or Azeri () 18:29 < bridge> @sollybunny https://github.com/ddnet/ddnet/issues/8452 18:29 < bridge> ``` 18:29 < bridge> A proper fix would be to send the zoom float along with NETMSGTYPE_CL_SHOWDISTANCE then the server can get the exact same values that it gets now with a simple multiply. The size of the ints was only a concern in the context of resending multiple inputs per tick, you don't need to worry about that. 18:29 < bridge> 18:29 < bridge> EDIT: or most likely make a new net message that is sent at the same time as NETMSGTYPE_CL_SHOWDISTANCE to keep server compatibility. 18:29 < bridge> ``` 18:29 < bridge> would also fix zoom hax xD 18:30 < bridge> Introduced here 18:30 < bridge> 18:30 < bridge> https://github.com/ddnet/ddnet/pull/7512 18:30 < bridge> Unfortunately it can't be cleanly reverted 18:31 < bridge> yeah it can 18:31 < bridge> wherevre the mouse position is multiplied by zoom 18:31 < bridge> dont... 18:31 < bridge> It breaks backwards compatibility 18:31 < bridge> this breaks backward compatibility? 18:31 < bridge> oh wait /tc requires this? 18:33 < bridge> well i guess thats fine 18:33 < bridge> just multiply by a constant and zoom level 18:33 < bridge> when u want to /tc u turn multiplier to 1 18:34 < bridge> cl_mouse_multiplier 1; say /tc; cl_mouse_multiplier 1024 18:34 < bridge> Yes, we realized we made a mistake there but it was too late to fix so we didnt think about it much. I got help from my two azerbaijani friends for translation 18:35 < bridge> os its called azerbajanese in ddnet 18:35 < bridge> This is far too janky 18:35 < bridge> u can change that w/ another pr no? 18:35 < bridge> as mentioned - make a proper issue 18:35 < bridge> otherwise this discussion gets lost 18:35 < bridge> i have but im discussing it here as people are... 18:36 < bridge> yeah but... the only other way is to send zoom level which was not chosen 18:37 < bridge> and i dont think this bug should be kept 18:37 < bridge> You can choose it right now, the old choices were mistakes 18:38 < bridge> but that would mean all clients whcih want to use /tc will be broken untill they start sending zoom level 18:38 < bridge> also i dont know how to do that... x-x 18:38 < bridge> no the server can check if the client has sent a zoom level or not and use the appropriate choice 18:39 < bridge> true but thats.. kinda jank 18:39 < bridge> We have dozens maybe hundreds of such backwards compatibility checks on the server already 18:39 < bridge> oh okay 18:39 < bridge> well its still jank but okay 18:41 < bridge> this fixes #8452 but not the low max distance which would still require a multiplier which haas to be disabled for /tc 18:41 < bridge> https://github.com/ddnet/ddnet/issues/8452 18:42 < bridge> I'm not sure what you mean 18:42 < bridge> How does it only fix one 18:42 < bridge> i want a multiplier to fix precision for low maximum distance 18:42 < bridge> That's probably not want you want 18:42 < bridge> but it also coincidentally fixed preciison for zoomed in (?) states 18:43 < bridge> it is what i want 18:43 < bridge> i hate having low precision 18:43 < bridge> A multiplier isn't really going to help anything, you just need to send the screens pace mouse coordinates without scaling them 18:43 < bridge> Like before 18:43 < bridge> wait... your right 18:43 < bridge> so why does my fix work 18:44 < bridge> i removed the zoom multipling (i didnt know why it was there) 18:44 < bridge> Idk maybe it gets rounded to int after you multiplied 18:44 < bridge> So the precision is kept 18:44 < bridge> its just the multiplier 18:44 < bridge> wait but i havent tested it with 1 18:44 < bridge> wait but i havent tested it with x1 18:44 < bridge> because zoom isnt by default at 1? is it 18:44 < bridge> ? 18:44 < bridge> the default zoom is 10? 18:45 < bridge> Idk what you did tbh 18:45 < bridge> i just multiplied by a constant 18:45 < bridge>