13:19 <+bridge> [ddnet] @fokkonaut you just need std::sort and a lambda function to do the comparison 13:19 <+bridge> [ddnet] :( Tried that 13:19 <+bridge> [ddnet] (or you could just use a function, instead of a lambda function if you are old school :P) 13:19 <+bridge> [ddnet] show what you tried 13:20 <+bridge> [ddnet] When I get home 13:21 <+bridge> [ddnet] I dont have that example anymore tho 13:21 <+bridge> [ddnet] Just the one that sorts it correctly but has 2 entries per entry xd 13:25 <+bridge> [ddnet] `std::sort(v.begin(), v.end(), [](const somestruct &a, const somestruct &b) -> bool { return a.x > b.x; });` 13:25 <+bridge> [ddnet] sth like this should be correct 13:26 <+bridge> [ddnet] I'll try that! Thanks :)) 13:28 <+bridge> [ddnet] what is this -> return thing? 13:44 <+bridge> [ddnet] its an arrow 13:45 <+bridge> [ddnet] its an arrow :troll: 13:50 <+bridge> [ddnet] const return 14:02 <+bridge> [ddnet] @fokkonaut that's literally the only way to explicitly list the return type in lambda functions, otherwise it is inferred, which would also be fine in this case I guess: https://en.cppreference.com/w/cpp/language/lambda 14:03 <+bridge> [ddnet] for non-lambda functions you can also use auto as return type and add an -> if the return type depends on the parameters 15:34 <+bridge> [ddnet] Well, it works but I get two entries each... 15:36 <+bridge> [ddnet] ahhh 15:36 <+bridge> [ddnet] okay, lol? 15:36 <+bridge> [ddnet] my listdirectory calls every file twice 15:36 <+bridge> [ddnet] but why 15:38 <+bridge> [ddnet] Yea, thats the error. ListDirectory() goes through all files twice it seems 15:40 <+bridge> [ddnet] Is there a fix? Is this a bug? Or do I have to check whether I opened that file already manually? 15:40 <+bridge> [ddnet] is this CStorage::ListDirectory you are talking about? 15:40 <+bridge> [ddnet] Yes 15:41 <+bridge> [ddnet] Placing a dbg_msg returning the filename in it, I get each twice 15:41 <+bridge> [ddnet] what storage type are you using? 15:41 <+bridge> [ddnet] ALL 15:41 <+bridge> [ddnet] TYPE_ALL 15:43 <+bridge> [ddnet] is it possible that you have some weird storage.cfg that lists a path twice? 15:43 <+bridge> [ddnet] current dir, data dir is the same? 15:43 <+bridge> [ddnet] could be, either way it's because of the TYPE_ALL 15:43 <+bridge> [ddnet] Well, the files are located in ../files/ 15:44 <+bridge> [ddnet] so 15:44 <+bridge> [ddnet] (still a bug, I guess) 15:44 <+bridge> [ddnet] one dir back. then in a folder again 15:44 <+bridge> [ddnet] @heinrich5991 one I wouldn't really know how to fix tbh 15:44 <+bridge> [ddnet] I dont have a storage.cfg 15:45 <+bridge> [ddnet] Should I just check whether this file has been called already manually for a workaround? 15:45 <+bridge> [ddnet] ../files sounds like you aren't really using storage correctly tbh 15:45 <+bridge> [ddnet] its a path based on a config var 15:45 <+bridge> [ddnet] the files are located at ../files relative to what? 15:45 <+bridge> [ddnet] relative to the binary of course 15:46 <+bridge> [ddnet] well that "of course" is not at all obvious to CStorage πŸ˜› 15:46 <+bridge> [ddnet] What do you mean? :F 15:46 <+bridge> [ddnet] What do you mean? :D 15:46 <+bridge> [ddnet] should I try placing them in the binary path/files? 15:47 <+bridge> [ddnet] Well no wait 15:47 <+bridge> [ddnet] ahh 15:47 <+bridge> [ddnet] this might be because of my windows 15:47 <+bridge> [ddnet] I have tested this on windows 15:47 <+bridge> [ddnet] and here it is in binarydir/data/files 15:48 <+bridge> [ddnet] no storage.cfg tho 15:48 <+bridge> [ddnet] no, thats not it :/ 15:48 <+bridge> [ddnet] if there is no storage.cfg, the engine adds $USERDIR, $DATADIR, $CURRENTDIR 15:49 <+bridge> [ddnet] TYPE_ALL means check all added paths 15:49 <+bridge> [ddnet] I will add a storage.cfg and only include CURRENTDIR, then it only checks for the binary dir, right? 15:49 <+bridge> [ddnet] or what is what? 15:49 <+bridge> [ddnet] $DATADIR is binary dir 15:50 <+bridge> [ddnet] oke 15:50 <+bridge> [ddnet] $CURRENTDIR is cwd, from where your process started 15:50 <+bridge> [ddnet] listing duplicate names is probably not helpful for CStorage::ListDirectory 15:51 <+bridge> [ddnet] it should probably discard entries with the same name in lower priority folders 15:51 <+bridge> [ddnet] only DATADIR doesnt work, it cant find the files 15:51 <+bridge> [ddnet] maybe I'm wrong about $DATADIR 15:51 <+bridge> [ddnet] $DATADIR is ./data iirc 15:52 <+bridge> [ddnet] looks for data/mapres in cwd 15:52 <+bridge> [ddnet] cwd? 15:52 <+bridge> [ddnet] current working directory 15:52 <+bridge> [ddnet] ? 15:52 <+bridge> [ddnet] yea 15:52 <+bridge> [ddnet] if it's not in the current working directory, it checks whether it's in the path from argv[0] 15:53 <+bridge> [ddnet] ```add_path $USERDIR 15:53 <+bridge> [ddnet] add_path $DATADIR 15:53 <+bridge> [ddnet] add_path $CURRENTDIR 15:53 <+bridge> [ddnet] add_path $APPDIR``` 15:53 <+bridge> [ddnet] this is available 15:53 <+bridge> [ddnet] there is no $APPDIR 15:53 <+bridge> [ddnet] in 0.7 there is :o 15:53 <+bridge> [ddnet] damn 0.7 messing around with things again 15:53 <+bridge> [ddnet] $APPDIR 15:53 <+bridge> [ddnet] # - usable path provided by argv[0] 15:54 <+bridge> [ddnet] I have no idea what $APPDIR is or might be, given I haven't read the 0.7 source since oy abandoned it 6 years ago 15:54 <+bridge> [ddnet] ```$USERDIR 15:54 <+bridge> [ddnet] # - ~/.appname on UNIX based systems 15:54 <+bridge> [ddnet] # - ~/Library/Applications Support/appname on Mac OS X 15:54 <+bridge> [ddnet] # - %APPDATA%/Appname on Windows based systems 15:54 <+bridge> [ddnet] # $DATADIR 15:54 <+bridge> [ddnet] # - the 'data' directory which is part of an official 15:54 <+bridge> [ddnet] # release 15:54 <+bridge> [ddnet] # $CURRENTDIR 15:54 <+bridge> [ddnet] # - current working directory 15:54 <+bridge> [ddnet] # $APPDIR 15:54 <+bridge> [ddnet] # - usable path provided by argv[0]``` 15:54 <+bridge> [ddnet] what if no usable path is provided by argv[0] 15:55 <+bridge> [ddnet] idk what that is 15:55 <+bridge> [ddnet] you'd have to read `AddPath`Β to see how $APPDIR is handled 15:56 <+bridge> [ddnet] Anyway, your issue is most definitely one of the paths you are adding is overlapping 15:56 <+bridge> [ddnet] you could just print out the paths to see which ones are overlapping 15:57 <+bridge> [ddnet] yea 15:57 <+bridge> [ddnet] if I remove APPDIR it is working 15:57 <+bridge> [ddnet] lol 15:58 <+bridge> [ddnet] bet it's how they handle "usable" path provided by argv[0] 15:59 <+bridge> [ddnet] it was the same path as CURRENTDIR, checked the log of the server 16:00 <+bridge> [ddnet] Yeah "./" and "" are perfectly "usable" paths 16:00 <+bridge> [ddnet] @heinrich5991 the better solution would be to make storage paths a set rather then an array 16:00 <+bridge> [ddnet] my thing is also needed 16:00 <+bridge> [ddnet] it's intended that storage paths from higher priority override lower priority ones 16:01 <+bridge> [ddnet] for the "are two paths the same" problem, there are probably also solutions. I'd guess that they're not particularly nice 16:01 <+bridge> [ddnet] you could probably `stat` the directory on linux and compare ino and device number 16:02 <+bridge> [ddnet] the ugliness can be abstracted into an fs_same_file 16:02 <+bridge> [ddnet] I think the solution will still be hacky and not work at all times if we do it 16:02 <+bridge> [ddnet] the override in listdirectory isn't particularly pretty to implement either 16:03 <+bridge> [ddnet] see the problems around `#pragma once` 16:03 <+bridge> [ddnet] the problem of "are these two directories the same" is that the question is underspecified IMO 16:03 <+bridge> [ddnet] at least this problem does not exist for the other solution 16:03 <+bridge> [ddnet] *the other bugfix 16:04 <+bridge> [ddnet] I mean we already treat the files as such (`OpenFile` only opens the highest priority file) 16:04 <+bridge> [ddnet] i'm sure winapi provides some fancy function with many underscores and an Ex at the end that solves the problem 16:05 <+bridge> [ddnet] https://en.wikipedia.org/wiki/Pragma_once#Caveats 16:05 <+bridge> [ddnet] Identifying the same file on a file system is not a trivial task.[6] Symbolic links and especially hard links may cause the same file to be found under different names in different directories. Compilers may use a heuristic that compares file size, modification time and content.[7] Additionally, #pragma once can do the wrong thing if the same file is intentionally copied into sev 16:06 <+bridge> [ddnet] No underscores but GetFileInformationByHandleEx is a thing 16:07 <+bridge> [ddnet] The shortcomings of compilers is not particularly interesting. comparing ino and devid on linux and the triplet returned by winapi should be enough for our uses 16:07 <+bridge> [ddnet] okay. the other thing is still needed though, right? 16:07 <+bridge> [ddnet] yes, definitely 16:08 <+bridge> [ddnet] no idea how to do it without keeping track of the files returned by fs_listdir and then delaying the calling of the callback 16:08 <+bridge> [ddnet] I guess it wouldn't look too bad with a lambda function 16:09 <+bridge> [ddnet] do we have a set in base/tl? 16:09 <+bridge> [ddnet] no, don't think so 16:10 <+bridge> [ddnet] that's gonna get ugly w/o a container 16:15 <+bridge> [ddnet] matricks's tl code is so cryptic πŸ˜› 17:11 <+bridge> [ddnet] https://github.com/Learath2/ddnet/commit/3f416136 17:11 <+bridge> [ddnet] Oh they finally fixed the huge avatars 17:12 <+bridge> [ddnet] xd 17:12 <+bridge> [ddnet] Turns out fixing the bugs is more intricate then I predicted earlier 17:12 <+bridge> [ddnet] I don't feel comfortable touching 17:12 <+bridge> [ddnet] it 18:25 <+bridge> [ddnet] Also added sort_quick https://github.com/Learath2/ddnet/commit/8da7f65 18:25 <+bridge> [ddnet] but I forgot what I added it for after adding it 18:25 <+bridge> [ddnet] such a productive day πŸ˜› 18:49 <+bridge> [ddnet] Does anyone here got in touch with 0.7 already or do I have most knowledge about it here and you cant help? xd 18:53 <+bridge> [ddnet] 18:53 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/621025482296655873/Screenshot_20190910-185325_Discord.jpg 18:53 <+bridge> [ddnet] @Learath2 LIAR xd 18:57 <+bridge> [ddnet] It used to be muuuch bigger πŸ˜› 18:58 <+bridge> [ddnet] It was like this on phone forever 18:58 <+bridge> [ddnet] @fokkonaut @heinrich5991 is the only person I imagine knows about some of the 0.7 code 18:58 <+bridge> [ddnet] Mh, well, this could also be known by you 18:58 <+bridge> [ddnet] I don't think I feel comfortable touching anything about 0.7 yet, too many unknowns about the dev team 18:59 <+bridge> [ddnet] god forbid we spend time implementing things and they just refuse to cooperate, or vanish into thin air again 19:02 <+bridge> [ddnet] in 0.7, skinchanges arent handled in snap anymore, instead using a `CNetjObj_Sv_SkinChange`. I created a rainbow, so the skinchange message will be sent every tick to the currently snapping client. If there are about 7 players on the server, it will overload the buffer and disconnect the players one by one (or most of them) for the reason `out of buffer`. Oy said, this shouldnt e 19:02 <+bridge> [ddnet] pleasedont 19:02 <+bridge> [ddnet] mh? 19:02 <+bridge> [ddnet] make your rainbow slower 19:03 <+bridge> [ddnet] sending an extra sv skinchange every tick is just very not nice 19:03 <+bridge> [ddnet] if all the 7 people have rainbow* is what i meant 19:03 <+bridge> [ddnet] why not ask oy 19:04 <+bridge> [ddnet] @Learath2 By making it slower you mean sending it every (?) 2 ticks or even more? 19:04 <+bridge> [ddnet] yep that's what I mean 19:04 <+bridge> [ddnet] would 2 be enough? 19:04 <+bridge> [ddnet] i guess it wont 19:04 <+bridge> [ddnet] 2 ticks is 25 times a second 19:04 <+bridge> [ddnet] what kinda rainbow is this? 19:05 <+bridge> [ddnet] a smooth transition rainbow, pretty slow 19:05 <+bridge> [ddnet] also why did they move the skin changes out of the snap?... 19:05 <+bridge> [ddnet] They completely removed them at first 19:06 <+bridge> [ddnet] but some people (also me) didnt want to accept that change, so they reimplemented it using a netobj in like 0.7.2 or .1 19:06 <+bridge> [ddnet] completely removed skinchanges? 19:06 <+bridge> [ddnet] oh I remember this 19:06 <+bridge> [ddnet] such a stupid change 19:06 <+bridge> [ddnet] yea, needed to reconnect 19:06 <+bridge> [ddnet] yes 19:06 <+bridge> [ddnet] name and clan cant even be changed ingame 19:06 <+bridge> [ddnet] i think country cant aswell 19:19 <+bridge> [ddnet] yes 0.7 is stupid 19:36 <+bridge> [ddnet] nah its not stupid 20:22 <+bridge> [ddnet] I mean those are pretty stupid design decisions 20:22 <+bridge> [ddnet] probably with no reason even 20:26 <+bridge> [ddnet] Yea, thats true 20:32 <+bridge> [ddnet] so thats why we should be active in 0.7 and make sure they dont fuck things up 20:32 <+bridge> [ddnet] 20:32 <+bridge> [ddnet] @fokkonaut does a good job there 20:33 <+bridge> [ddnet] 20:33 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/621050559226707978/unknown.png 20:33 <+bridge> [ddnet] me top1 master 21:04 <+bridge> [ddnet] wow 21:04 <+bridge> [ddnet] i didnt expect that many players on 0.7 21:04 <+bridge> [ddnet] ^^ 21:09 <+bridge> [ddnet] they are masochists 21:14 <+bridge> [ddnet] more like sadists