05:27 <+bridge> [ddnet] i have a suggestion to remake the rankpoint system. right now there are big differences between maps and the rankpoints they give. for example its probably very hard to get top10 on multeasymap but when you finish a harder map quickly you can get rankpoints evenw hen you didnt really speedrun the map. thats why i think its a good idea to use the % of ranks that were recently added. lets say you get rankpoints if youre within the top 05:27 <+bridge> [ddnet] after all... you can be rank 11 on every map and have 0 rankpoints 09:49 <+bridge> [ddnet] yo @deen this is me begging you to not force push anymore to ddnet master \:) i have like 2 active forks merging in irregular intervals and it would cause me big pain in the ass 10:07 <+bridge> [ddnet] yikes what do i do when client launch segfaults but running with gdb just hangs it? \:C 10:54 <+bridge> [ddnet] fixed it with printf driven development \:D 10:55 <+bridge> [ddnet] did anyone of you ever try to configure vscode with cmake? I am a bit annoyed by the greyed out code because vscode does not know about the cmake options i use 10:56 <+bridge> [ddnet] image.png 10:56 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/905757270477013012/image.png 11:17 <+bridge> [ddnet] you can configure it probs 11:17 <+bridge> [ddnet] the cmake command 11:17 <+bridge> [ddnet] what vscode probs does is generate compile_commands.json 11:17 <+bridge> [ddnet] but it depends on the flags u pass to cmake 11:18 <+bridge> [ddnet] for dev u should enable -DDEV and any other feature u want 11:19 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/905763179416678420/unknown.png 11:19 <+bridge> [ddnet] maybe 11:19 <+bridge> [ddnet] https://vector-of-bool.github.io/docs/vscode-cmake-tools/settings.html#conf-cmake-configuresettings 11:20 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/905763347704737823/unknown.png 11:26 <+bridge> [ddnet] did I? 11:37 <+bridge> [ddnet] @deen\: no worries mate you did not \:) just asking you to keep it that way 11:38 <+bridge> [ddnet] @Ryozuki\: yea tried that it affected the build but not the syntax hightlight 11:38 <+bridge> [ddnet] u have to reconfigure 11:38 <+bridge> [ddnet] nobo 11:38 <+bridge> [ddnet] ctrl shift p 11:38 <+bridge> [ddnet] cmake: configure 11:38 <+bridge> [ddnet] oh ok lemme try 11:39 <+bridge> [ddnet] did it work for u? 11:39 <+bridge> [ddnet] lol im not a normie 11:39 <+bridge> [ddnet] i use neovim 11:39 <+bridge> [ddnet] ok sir 11:41 <+bridge> [ddnet] :greenthing: 12:04 <+bridge> [ddnet] omagwd it works how did it not work the first time 12:04 <+bridge> [ddnet] thanks ryo babe for motivating me to try again 12:05 <+bridge> [ddnet] image.png 12:05 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/905774661575516200/image.png 12:05 <+bridge> [ddnet] but oof can we get some gitignore? \:D 12:06 <+bridge> [ddnet] echo ".cmake" >> .git/info/exclude 12:06 <+bridge> [ddnet] ur a nobo 12:06 <+bridge> [ddnet] echo ".cmake/" >> .git/info/exclude 12:10 <+bridge> [ddnet] ik 12:10 <+bridge> [ddnet] but that diff 14:16 <+bridge> [ddnet] @Ryozuki\: here u go mozilla dudes accepted it https://addons.mozilla.org/en-US/firefox/addon/github_forks/ 14:17 <+bridge> [ddnet] Jupstar ✪ do you compile with llvm CFI? 14:17 <+bridge> [ddnet] LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto). 14:17 <+bridge> [ddnet] i discovered this cuz rust added it xd 14:17 <+bridge> [ddnet] > Clang includes an implementation of a number of control flow integrity (CFI) schemes, which are designed to abort the program upon detecting certain forms of undefined behavior that can potentially allow attackers to subvert the program’s control flow. These schemes have been optimized for performance, allowing developers to enable them in release builds. 14:18 <+bridge> [ddnet] -fsanitize=cfi for clang 14:18 <+bridge> [ddnet] and requires lto 14:19 <+bridge> [ddnet] new version poggers 14:19 <+bridge> [ddnet] :poggers: 14:21 <+bridge> [ddnet] That is a massive release :D 14:26 <+bridge> [ddnet] 15.6: the memory safety update 14:26 <+bridge> [ddnet] :monkalaugh: 14:27 <+bridge> [ddnet] No 14:27 <+bridge> [ddnet] those changes are not in 15.6 14:27 <+bridge> [ddnet] oh 14:27 <+bridge> [ddnet] since they were not broken by 15.6 changes I think 14:28 <+bridge> [ddnet] If I keep adding new changes into 15.6 we need more and more rcs 14:28 <+bridge> [ddnet] yeah 14:28 <+bridge> [ddnet] its good our problem are too many changes 14:28 <+bridge> [ddnet] and not the other way around 14:29 <+bridge> [ddnet] :ddnet: 14:30 <+bridge> [ddnet] @deen the sha sums are not updated yet? 14:30 <+bridge> [ddnet] maybe im too fast 14:30 <+bridge> [ddnet] xd 14:33 <+bridge> [ddnet] true, running it now 14:36 <+bridge> [ddnet] aur is updated 14:39 <+bridge> [ddnet] great, thanks 14:51 <+bridge> [ddnet] I'm around for an hour or so incase something blows up 😛 14:52 <+bridge> [ddnet] :monkaS: 14:58 <+bridge> [ddnet] so nice version rls without conflicts in version.h \:D 14:58 <+bridge> [ddnet] 14:58 <+bridge> [ddnet] without any conflicts at all 17:04 <+bridge> [ddnet] rip rc 17:05 <+bridge> [ddnet] I don't get how not a single one of us gets these weird issues 17:05 <+bridge> [ddnet] well i dont play on windows 17:05 <+bridge> [ddnet] yeah really weird 17:05 <+bridge> [ddnet] especially louis and others tested it 17:06 <+bridge> [ddnet] i also asked a few ppl from my clan to test it, who are all on windows 17:06 <+bridge> [ddnet] :frozen: 17:20 <+bridge> [ddnet] we have way too few RC testers I'd say 17:25 <+bridge> [ddnet] Yes RC are nice to stabilize releases. I try to merge client to master often its not rly RC but at least something \:D 17:29 <+bridge> [ddnet] or minimize ifdefs for windows and stuff, use the std or if the std isnt good enough some libs 17:29 <+bridge> [ddnet] 17:29 <+bridge> [ddnet] SDL also has some read write stuff, sadly not really powerful like e.g. c++17 filesystem (https://wiki.libsdl.org/SDL_RWFromFile "a UTF-8 string representing the filename to open") 17:30 <+bridge> [ddnet] i could atleast imagine that most stuff used in system.h also exists in boost or std 17:31 <+bridge> [ddnet] I dont want to imagine how much we'd break trying to replace system.h 17:32 <+bridge> [ddnet] in the end boost and std have insanly stricter rules, so its probs easier to use than our randomly written system replacement functions xd 18:20 <+bridge> [ddnet] I pulled out all the laptops I have, none seem to be able to reproduce this :/ 18:21 <+bridge> [ddnet] Maybe if you switch your Windows language to Russian 18:21 <+bridge> [ddnet] or your username to Russian 18:21 <+bridge> [ddnet] at least Nakimar reported that reverting the unicode filesystem changes fixed part of the issue 18:24 <+bridge> [ddnet] Oh, that's a lead 18:24 <+bridge> [ddnet] If only one developer could reproduce it we could find what's going wrong 18:45 <+bridge> [ddnet] We should start logging the version and githash when starting the client 18:47 <+bridge> [ddnet] definitely worse performance in 15.6 18:47 <+bridge> [ddnet] Yes, the performance is obviously my greatest concern right now 18:47 <+bridge> [ddnet] idk why you released it anyways xd 18:47 <+bridge> [ddnet] XDE 18:47 <+bridge> [ddnet] how is the performance worse? 18:48 <+bridge> [ddnet] Oh idk why, maybe since it worked for everyone in rc and it has been in testing for a long time now? 18:48 <+bridge> [ddnet] i hope its not SDL again xD 18:48 <+bridge> [ddnet] But the performance loss was known 18:48 <+bridge> [ddnet] You know we tend to write software to release not to let ferment 18:48 <+bridge> [ddnet] @fokkonaut\: can you be more explicit? 18:48 <+bridge> [ddnet] snapfinditem is slow on entityex 18:48 <+bridge> [ddnet] bcs of the doors? 18:48 <+bridge> [ddnet] to match to the real entity 18:49 <+bridge> [ddnet] as learath suggested, we should have a new netmsg including them 18:49 <+bridge> [ddnet] but that only matters for zooming out far doesnt it 18:49 <+bridge> [ddnet] idk 18:49 <+bridge> [ddnet] Yep, clipped to the view and zoomed at default you shouldn't be losing much performance at all 18:49 <+bridge> [ddnet] the whole client feels a bit worse than 15.5 18:49 <+bridge> [ddnet] i also benchmarked find item and most overhead comes from the insanly slow uuid manager lookup 18:49 <+bridge> [ddnet] At zoom level 2 I lose about 5 fps from 15.5 18:52 <+bridge> [ddnet] is there anything unique for every single netmsg? 18:52 <+bridge> [ddnet] that does not require uuid lookup for example 18:52 <+bridge> [ddnet] oh, hm actually I do lose a lot more fps when checking on desktop 18:52 <+bridge> [ddnet] not every entityex in a message each, but all in one 18:53 <+bridge> [ddnet] I get 2k fps in 15.5 1k in 15.6 😛 18:53 <+bridge> [ddnet] see 18:53 <+bridge> [ddnet] on what map tho? 18:53 <+bridge> [ddnet] 📉 18:53 <+bridge> [ddnet] but there are no entityex on that map, I'm on grandma 18:54 <+bridge> [ddnet] then its weird, are u on windows? 18:54 <+bridge> [ddnet] I spec and look at the first part on both clients 18:54 <+bridge> [ddnet] on windows yep 18:54 <+bridge> [ddnet] pls SDL 18:54 <+bridge> [ddnet] dont do this to me 18:54 <+bridge> [ddnet] can you replace SDL.dll @Learath2 ? 18:54 <+bridge> [ddnet] yep, let me try 18:54 <+bridge> [ddnet] to check if it comes from there 18:55 <+bridge> [ddnet] ah won't work 18:55 <+bridge> [ddnet] `SDL_FlashWindow` is missing in old sdl 18:56 <+bridge> [ddnet] ah true 18:57 <+bridge> [ddnet] https://github.com/Jupeyy/ddnet/commit/84e580b4d98d8c57b933f7bd1a7085bfaa19bdd9 18:57 <+bridge> [ddnet] 18:57 <+bridge> [ddnet] completly randomly make UUID grouped in their 8Bit CRC already almost doubles the performance 18:57 <+bridge> [ddnet] so the best would be if we somehow could evade calls to it 18:57 <+bridge> [ddnet] I just noticed heavy fps drops when you do /showothers and there are other players, is it due to the alpha? 18:58 <+bridge> [ddnet] mhh, showothers generally drops alot of fps 18:58 <+bridge> [ddnet] why? because /pause doesnt drop fps, while at the same position 18:58 <+bridge> [ddnet] i even get more fps in /pause 18:58 <+bridge> [ddnet] xd 18:58 <+bridge> [ddnet] ah weird 19:01 <+bridge> [ddnet] I can make a build with reverted SDL_FlashWindow. Would that help? Then we can test if SDL is causing lower fps 19:01 <+bridge> [ddnet] i guess learath could just build himself? 19:02 <+bridge> [ddnet] I can't on this computer 19:02 <+bridge> [ddnet] I rage uninstalled VS 19:07 <+bridge> [ddnet] image.png 19:07 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/905880848165924934/image.png 19:07 <+bridge> [ddnet] lookupuuid is so slow, with my trash crc thing it almost halves 19:07 <+bridge> [ddnet] 19:07 <+bridge> [ddnet] thats why i want to know if there is any unique ID that can identify a uuid packet early 19:08 <+bridge> [ddnet] or can it be sorted somehow to do binary search over the packets 19:08 <+bridge> [ddnet] CAN REPRODUCE \o/ 19:09 <+bridge> [ddnet] Just create a local user account with cyrillic name 19:12 <+bridge> [ddnet] the Key() is that a 100% bet? 19:12 <+bridge> [ddnet] @nuborn EntityEx for doors is sadly not helpful at all, since it still requires the tiles to be placed there ._. My plot doors that work with other tiles are not showing as closed with this :/ 19:13 <+bridge> [ddnet] Even tho they are sent with entityex m_Number correct + SwitchState state closed 19:14 <+bridge> [ddnet] @nuborn\: you are not here by any chance? 19:19 <+bridge> [ddnet] @nuborn I dont think it is smart to not send doors to clients when they are closed anyways, bcs thats such a small change in snapshot and somehow belongs to the server 19:19 <+bridge> [ddnet] Do any of you have the capability to compile on windows? 19:20 <+bridge> [ddnet] yes 19:21 <+bridge> [ddnet] Um @deen this is nice and all but that build you gave out on #bugs didn't fix it for me, I'm not sure that's enough 19:21 <+bridge> [ddnet] If you have some time can you create a user account with a russian name and try to bisect the bug? 19:21 <+bridge> [ddnet] ah, too bad 19:21 <+bridge> [ddnet] wym user acc? 19:22 <+bridge> [ddnet] windows username 19:22 <+bridge> [ddnet] what would that change 19:22 <+bridge> [ddnet] ah nvm 19:22 <+bridge> [ddnet] i see 19:22 <+bridge> [ddnet] It completely breaks the game for some reason 19:22 <+bridge> [ddnet] Reverting the most obvious commits didn't help 19:22 <+bridge> [ddnet] not sure what we broke there 19:23 <+bridge> [ddnet] hm, i also had a unicode fs change 19:23 <+bridge> [ddnet] but it was only fs_rename so probably unrelated 19:24 <+bridge> [ddnet] @Learath2 i can ask someone about the russian name, sec 19:25 <+bridge> [ddnet] @fokkonaut\: or @nuborn 19:25 <+bridge> [ddnet] what would this break? 19:25 <+bridge> [ddnet] https://github.com/Jupeyy/ddnet/commit/46b9a7abf8967315c30503c5191686e7dae559da 19:25 <+bridge> [ddnet] this fixes the performance basically 19:26 <+bridge> [ddnet] very cool, thanks for looking into the performance so quickly jupstar 19:27 <+bridge> [ddnet] you can always ask deen or compile with the github CIs \:D 19:27 <+bridge> [ddnet] (@Learath2) 19:27 <+bridge> [ddnet] it wouldnt respect https://github.com/Jupeyy/ddnet/blob/46b9a7abf8967315c30503c5191686e7dae559da/src/engine/shared/snapshot.cpp#L24-L49 anymore 19:27 <+bridge> [ddnet] Means, it would break extended messages 19:28 <+bridge> [ddnet] why not ask robyte, he'll glady do it i bet 19:28 <+bridge> [ddnet] Dont apply that, lol 19:28 <+bridge> [ddnet] he also tested ime stuff for teeworlds 19:28 <+bridge> [ddnet] I doubt we can bisect remotely like this :D, with 500 commits it'd take 9 compilations 19:29 <+bridge> [ddnet] so, 9 builds? 20 min turnaround time, we'd be done in 3 hours 19:29 <+bridge> [ddnet] I'll just get mingw back on this windows installation 19:30 <+bridge> [ddnet] ok 19:30 <+bridge> [ddnet] so its not possible anyway? 19:30 <+bridge> [ddnet] todo binary search 19:31 <+bridge> [ddnet] https://github.com/Jupeyy/ddnet/blob/46b9a7abf8967315c30503c5191686e7dae559da/src/engine/shared/uuid_manager.cpp#L128-L136 19:31 <+bridge> [ddnet] @fokkonaut\: can you please just say how your client does it?, do you use a different system for extensions? 19:31 <+bridge> [ddnet] You mean F-Client? 19:31 <+bridge> [ddnet] It does the same as DDNet 19:32 <+bridge> [ddnet] I think 0.7 is better at doing it's searches in snaps 19:32 <+bridge> [ddnet] https://github.com/fokkonaut/F-Client/blob/F-Client/src/engine/shared/uuid_manager.cpp#L100-L110 19:32 <+bridge> [ddnet] my client uses heinrichs older approach, i htink 19:32 <+bridge> [ddnet] no idea if this is slower or not 19:32 <+bridge> [ddnet] this sucks i know that 19:32 <+bridge> [ddnet] We can go even further and unpack snaps into hashmaps so all further lookups are O(1) 19:33 <+bridge> [ddnet] ok so you have the same performance regressions 19:33 <+bridge> [ddnet] maybe the uuid manager is just overkill 19:33 <+bridge> [ddnet] i dont see an easy way to binary search if you HAVE to use the UUID 19:33 <+bridge> [ddnet] no other vanilla compatible way i think, because it sends this snap as if it has the id 0 19:33 <+bridge> [ddnet] iirc 19:33 <+bridge> [ddnet] yeah i already optimized it a bit, bcs nameplates were so slow in the past 19:34 <+bridge> [ddnet] hashmaps will be very slow i think 19:34 <+bridge> [ddnet] we need a 32bit lookup 19:34 <+bridge> [ddnet] everything else gets slow very fast 19:36 <+bridge> [ddnet] Is that really the part that is getting overwhelmed? 19:36 <+bridge> [ddnet] yes 19:36 <+bridge> [ddnet] https://matrix-client.matrix.org/_matrix/media/r0/download/matrix.org/MzBjRAcoNIsJBIqChKFOGLxp 19:36 <+bridge> [ddnet] seems so 19:36 <+bridge> [ddnet] oh sry 19:36 <+bridge> [ddnet] this 19:37 <+bridge> [ddnet] if there is a way to sort them somehow or not call uuid its fixable 19:37 <+bridge> [ddnet] else its a design flaw 19:37 <+bridge> [ddnet] Sort what? 19:37 <+bridge> [ddnet] sort keys to call the uuid loopup as less as possible 19:37 <+bridge> [ddnet] the uuid lookup is already binary, and still so slow, bcs its called so often 19:38 <+bridge> [ddnet] is heinrich online 19:38 <+bridge> [ddnet] Nope 19:38 <+bridge> [ddnet] he could just tell xd 19:39 <+bridge> [ddnet] Okay, iirc currently the snap includes an object that has the mappings from snap-type-id -> uuid 19:39 <+bridge> [ddnet] wait netobject extensions have an unique identifier type dont they? 19:40 <+bridge> [ddnet] did we have some documentation somewhere? 19:41 <+bridge> [ddnet] https://github.com/heinrich5991/libtw2/blob/master/doc/snapshot.md 19:41 <+bridge> [ddnet] wrong information as it seems, let me debug 19:41 <+bridge> [ddnet] Basically `NETOBJTYPE_EX` objects provide a mapping from type-id inside the snap to a uuid 19:42 <+bridge> [ddnet] ok 19:42 <+bridge> [ddnet] i mean we just need to "original key" and check against that i guess, snapfind item uses the lookedup item type 19:42 <+bridge> [ddnet] we need to original item type, is that always NETOBJTYPE\_EX 19:44 <+bridge> [ddnet] Extended objects get `typeid > OFFSET_UUID_TYPE`, `NETOBJTYPE_EX` objects provide the mapping from this typeid to the uuid 19:45 <+bridge> [ddnet] ok 19:48 <+bridge> [ddnet] https://github.com/teeworlds/teeworlds/pull/2129 here is what 0.7 did to optimize snap lookups 19:48 <+bridge> [ddnet] yeah, but that doesnt like, like its doable 19:49 <+bridge> [ddnet] Why not? 19:49 <+bridge> [ddnet] ok another question you might know 19:49 <+bridge> [ddnet] 19:49 <+bridge> [ddnet] lets say you have 2 extended objects of the same type, do they share the same offset to the item uuid? 19:50 <+bridge> [ddnet] bcs type + id is not the same refering @fokkonaut 19:50 <+bridge> [ddnet] they do 19:50 <+bridge> [ddnet] Well to be more correct they will have the exact same type within that one snap 19:50 <+bridge> [ddnet] it is the same, but extended objects have type 0 19:51 <+bridge> [ddnet] to be vanilla compatible 19:51 <+bridge> [ddnet] "compatible" 19:51 <+bridge> [ddnet] i other words: so they can be sent to vanilla clients, so they can drop them 19:51 <+bridge> [ddnet] Um, nope. I don't think so 19:51 <+bridge> [ddnet] yes, they are 19:51 <+bridge> [ddnet] yes, they have 19:52 <+bridge> [ddnet] Eeeh, no they don't or snapshot.cpp is lying to me 19:52 <+bridge> [ddnet] They are found by the uuid 19:52 <+bridge> [ddnet] Type 0 is used to provide the mapping, 19:52 <+bridge> [ddnet] Types > OFFSET_UUID_TYPE are decoded using objects of type 0 19:52 <+bridge> [ddnet] @Learath2\: are the extended types dynamic, e.g. can it have a different internal index from snapshot to snapshot? 19:52 <+bridge> [ddnet] Yes 19:52 <+bridge> [ddnet] ok 19:53 <+bridge> [ddnet] so we only need to store these mappings? 19:53 <+bridge> [ddnet] yea, but you dont send them as lets say 65557, it can differ from the type number thats on the server 19:53 <+bridge> [ddnet] from snapshot to snapshot? 19:53 <+bridge> [ddnet] then we can doi smth like this 19:53 <+bridge> [ddnet] https://github.com/Jupeyy/ddnet/commit/46b9a7abf8967315c30503c5191686e7dae559da 19:53 <+bridge> [ddnet] 19:53 <+bridge> [ddnet] just with the mapped type 19:54 <+bridge> [ddnet] e.g. a map that has ENTITY\_EX as key and the internal index as data entry of a std\:\:map 19:54 <+bridge> [ddnet] 19:54 <+bridge> [ddnet] so we can just see what ENTITY\_EX requires as internal type 19:55 <+bridge> [ddnet] and than do the thing in my commit with that mapped data 19:56 <+bridge> [ddnet] I'm not sure what you are really referring to, the first extended type in a snapshot will be type `32766` 19:57 <+bridge> [ddnet] yes 19:57 <+bridge> [ddnet] i'll just try it out and you have to judge on if it will work xd 19:57 <+bridge> [ddnet] I'm not sure what part of the process is the bottleneck. Is it the fact that we are looking for objects of type `ENTITY_EX` and that has to go through uuid which is too slow? 19:59 <+bridge> [ddnet] i mean linear search is slow, but most bottleneck simply comes from the fact we do uuid lookup and uuid is 16bytes 20:00 <+bridge> [ddnet] but what call stack leads to the lookup? 20:00 <+bridge> [ddnet] Is the new `void CGameClient::SnapCollectEntities()` taking too long? 20:00 <+bridge> [ddnet] i assume all calls, bcs it always hits extended objects 20:00 <+bridge> [ddnet] and they are "unwrapped" 20:01 <+bridge> [ddnet] that function too yes 20:01 <+bridge> [ddnet] its 50% of the calls, the rest is onnewsnapshot 20:01 <+bridge> [ddnet] ok no 20:01 <+bridge> [ddnet] its -5% of all perf 20:01 <+bridge> [ddnet] and onnewsnapshot does 50% of all 20:02 <+bridge> [ddnet] I don't follow, I'll just get a profile of my own 20:02 <+bridge> [ddnet] image.png 20:02 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/905894778200281108/image.png 20:03 <+bridge> [ddnet] oh thats the optimized version 20:03 <+bridge> [ddnet] image.png 20:03 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/905895029258719232/image.png 20:07 <+bridge> [ddnet] Hm, I don't know what SnapFindItem call is causing this 20:07 <+bridge> [ddnet] probably from entityex 20:08 <+bridge> [ddnet] There is no SnapFindItem for entityex tho, they are collected differently 20:08 <+bridge> [ddnet] ah 20:08 <+bridge> [ddnet] it also doesnt really matter which one it is, i think all netobjects use it 20:08 <+bridge> [ddnet] the problem is that entity ex are part of the snapshot 20:08 <+bridge> [ddnet] so they are still looked up 20:08 <+bridge> [ddnet] (?) 20:08 <+bridge> [ddnet] There are rather few calls to snapfinditem in the code :/ 20:09 <+bridge> [ddnet] yes, what i thought too 20:09 <+bridge> [ddnet] right now xd 20:09 <+bridge> [ddnet] Maybe the new entityex just make the snap too big for linear search to be viable? 20:09 <+bridge> [ddnet] so @Learath2 you are saying that we can just ignore objectex? 20:09 <+bridge> [ddnet] in that call 20:09 <+bridge> [ddnet] that would be even easier 20:10 <+bridge> [ddnet] i think so, yes 20:11 <+bridge> [ddnet] Wym? The id 0? that already should be early returning from GetItemType 20:11 <+bridge> [ddnet] so just check if the item type is over UUID\_OFFSET, and only check else 20:11 <+bridge> [ddnet] it doesnt rearly return if there is a object\_ex somewhere in the snapshot 20:11 <+bridge> [ddnet] early\* 20:11 <+bridge> [ddnet] bcs that object\_ex is looked up, even if it doesnt matter for this find call 20:12 <+bridge> [ddnet] it makes no difference between the type of the snapshot thing 20:12 <+bridge> [ddnet] What do you mean by object_ex? `NETOBJTYPE_EX`? 20:12 <+bridge> [ddnet] yes 20:12 <+bridge> [ddnet] `NETOBJTYPE_EX == 0` which is < `OFFSET_UUID_TYPE` so GetItemType should never result in a uuid lookup 20:13 <+bridge> [ddnet] Idk what else you'd be meaning by lookup 20:15 <+bridge> [ddnet] ok 20:15 <+bridge> [ddnet] then not objtype\_ex 20:15 <+bridge> [ddnet] but whatever uses the uuid thing 20:15 <+bridge> [ddnet] Can we somehow learn where this snapfinditem is being called from? 20:15 <+bridge> [ddnet] NETMSG\_MAP\_DETAILS 20:15 <+bridge> [ddnet] You can try caching the mapping OnNewSnapshot actually 20:16 <+bridge> [ddnet] if snapfinditem doesnt require extended protocol, it will be fast enough 20:16 <+bridge> [ddnet] Get all the `NETOBJTYPE_EX` objects, build a map from internal id directly to externalid, then use that for this snapshot 20:17 <+bridge> [ddnet] NETMSG_MAP_DETAILS isn't even a snap object, how would it be going thru snapfinditem? 20:19 <+bridge> [ddnet] well i dunno what message 20:19 <+bridge> [ddnet] but one of them must be in 20:19 <+bridge> [ddnet] or the server sends buggy snapshots 20:19 <+bridge> [ddnet] https://github.com/Jupeyy/ddnet/commit/7b91d861c65ef152f4ed0f16ff8a52be03627951 20:19 <+bridge> [ddnet] safe or not? 20:21 <+bridge> [ddnet] I don't see how that's helpful 20:22 <+bridge> [ddnet] You removed the ability to find extended objects? 20:22 <+bridge> [ddnet] NETOBJTYPE\_GAMEINFOEX 20:23 <+bridge> [ddnet] thats the question 20:23 <+bridge> [ddnet] (@Learath2) 20:23 <+bridge> [ddnet] is it ever useful? the client only 2 times does not try to find a non vanilla object type 20:25 <+bridge> [ddnet] I'm not following your logic here. You are still doing GetItemType, which is already cheap for non extended object 20:25 <+bridge> [ddnet] s 20:25 <+bridge> [ddnet] ok NETOBJTYPE\_DDNETPROJECTILE seems like a problem atleast? 20:25 <+bridge> [ddnet] thats what i suggested yes 20:25 <+bridge> [ddnet] (@Learath2) 20:25 <+bridge> [ddnet] I actually don't have any idea, you managed to completely confuse me 😄 20:26 <+bridge> [ddnet] ok lets see it like this\: 20:26 <+bridge> [ddnet] NETOBJTYPE\_GAMEINFOEX is in the snapshot every time isnt it? 20:26 <+bridge> [ddnet] every tick 20:26 <+bridge> [ddnet] yes 20:27 <+bridge> [ddnet] and NETOBJTYPE\_GAMEINFOEX is uuid 20:27 <+bridge> [ddnet] 20:27 <+bridge> [ddnet] so even if you search for something completly unrelated, like a character, it might still lookup this ID type 20:27 <+bridge> [ddnet] Ah, I see what you mean, as said I think building a map at the start will work 20:27 <+bridge> [ddnet] ok 20:28 <+bridge> [ddnet] Your patch makes more sense too now, it's not correct but it does make sense 20:29 <+bridge> [ddnet] Check if the type we are looking for is an extended type. If not don't even do the lookup is what you are trying to do, right? 20:32 <+bridge> [ddnet] from what i see only NETOBJTYPE\_DDNETPROJECTILE is used in snapfinditem 20:32 <+bridge> [ddnet] so we basically only would require mapping for this single uuid 20:33 <+bridge> [ddnet] (the only non vanilla netobj to be precise) 20:34 <+bridge> [ddnet] Branch on `Type < OFFSET_UUID_TYPE` if true check the raw type, else check thru getItemType. it's not pretty but it will show if that's the issue 20:38 <+bridge> [ddnet] but i guess i can also check against OFFSET\_GAME\_UUID-1 from protocol.h so i know if the type expects a uuid or not 20:38 <+bridge> [ddnet] 20:38 <+bridge> [ddnet] the uuid manager always adds + OFFSET\_UUID 20:39 <+bridge> [ddnet] Oh please don't confuse me more, these are all different uuids 20:39 <+bridge> [ddnet] offsets* 20:40 <+bridge> [ddnet] `OFFSET_UUID_TYPE` is the offset you are looking for, types < that are internal vanilla types, types >= are extended types period 20:41 <+bridge> [ddnet] https://github.com/Jupeyy/ddnet/commit/a990669050f70dbac7a14f89e0a4e19438668f56 20:45 <+bridge> [ddnet] that fix atleast doubles my fps 21:37 <+bridge> [ddnet] this better be all the unicode fixes :justatest: 22:08 <+bridge> [ddnet] oh. do normal doors show correctly for you? doors are only rendered from the snapshot, so the client doesn't know if it's actually a "real" door or anything else. perhaps you can compare the values (and m_Number/m_Layer) with normal doors 22:09 <+bridge> [ddnet] All fine, I was only sending m_NumSwitchers amount for SwitchState, forgot to add + m_NumPlots from my side 22:09 <+bridge> [ddnet] All working 22:09 <+bridge> [ddnet] ah ok, nice 22:10 <+bridge> [ddnet] If door prediction will base on this, and not tiles, it will work so good :) 22:11 <+bridge> [ddnet] yes, the idea is to make it possible to get more general prediction (and in theory you could even add other types of doors, and get prediction) 22:12 <+bridge> [ddnet] oo 22:12 <+bridge> [ddnet] if someone ever fixes the "pass through doors thing" for example:P 22:12 <+bridge> [ddnet] if someone ever fixes the "pass through doors" thing for example:P 22:13 <+bridge> [ddnet] (or maybe it already is) 22:13 <+bridge> [ddnet] its not 22:14 <+bridge> [ddnet] I dont think its needed to fix that for prediction tho 22:25 <+bridge> [ddnet] I have a branch where I got rid of even more calls to SnapFindItem, including this one (I think), by caching the SNAP_CUR->SNAP_PREV mapping in addition to the entity ex mapping, so I could try to finish up that one 22:28 <+bridge> [ddnet] I dont know much about how UUIDs/SnapFindItem works otherwise, but noticed previously that the uuid lookup took most of the time there 22:37 <+bridge> [ddnet] oh, you're here too. hi, thanks for fix 🙂 23:02 <+bridge> [ddnet] @nuborn || anyone looking into the uuid thing: The mapping of type to uuid is not static, it's per snap. Just be careful with that 23:09 <+bridge> [ddnet] oh, so its a mapping to the types, not the objects? then I probably misread a few things of the discussion above 23:10 <+bridge> [ddnet] Okay, let's use concrete terminology here. When I say type I refer to the type part of the "typeandid" construct inside any given netobject 23:11 <+bridge> [ddnet] That type if below `OFFSET_UUID_TYPE` refers to vanilla object types. Except for type 0 (`NETMSGTYPE_EX`). Objects of type 0 instead denote a mapping from their id (which refers to the id inside the netobject) to a uuid. 23:12 <+bridge> [ddnet] Types above `OFFSET_UUID_TYPE` are mapped to uuids using the mappings sent in the `NETMSGTYPE_EX` objects. Then these uuids are mapped to types using the uuid manager 23:13 <+bridge> [ddnet] That last sentence should have been `s/types/concrete types/` as in `NETOBJTYPE_ENTITYEX` e.g. 23:15 <+bridge> [ddnet] Optimizations that come to mind are first keeping this a mapping from extended concrete types to snap internal types 23:15 <+bridge> [ddnet] Second optimizing the linear lookup in SnapFindItem 23:16 <+bridge> [ddnet] Third re-engineering the extended net objects to negotiate the mapping before the first snap through netmsgs 23:17 <+bridge> [ddnet] yes, thanks, that clarified it quite a bit (wasn't aware of how uuids worked internally) 23:19 <+bridge> [ddnet] something I thought about previously (and tried a bit) was to do something like SnapCollectEntities to also gather the snap_prev and snap_cur versions of netobjects in the same list, to reduce the calls to SnapFindItem more, but not sure if that would be needed with those other optimizations? 23:20 <+bridge> [ddnet] I actually have no idea what is the problem here, I haven't profiled it myself so I'll refrain from saying anything concrete 23:20 <+bridge> [ddnet] I think the optimization jupeyy came up with + taking the binary search for snaps from 0.7 should get us back to the same performance, but not exactly sure 23:21 <+bridge> [ddnet] I'd also like to get @heinrich5991 to take a look at the optimization we thought of, I'm sure he'd have a more elegant way of doing it since my idea breaks abstraction 23:23 <+bridge> [ddnet] Oh and an extreme optimization I don't remember who came up with is to unpack the snaps as they arrive into a hashmap 23:23 <+bridge> [ddnet]