00:11 <+bridge> [ddnet] @deen is it ok if we add the new texture "extras.png" from ravie to the 16.2 release ๐Ÿ™‚ He really wants it. 00:15 <+bridge> [ddnet] do you know if the protocol supports sending non-fixed sized packets? I only saw the ability to send strings which I guess would work but doesn't seem ideal. 00:16 <+bridge> [ddnet] sending a whole second of inputs would be quite a lot, but I guess if you're playing in solo it doesn't matter if you have a 1000ms prediction margin 00:18 <+bridge> [ddnet] I think some netmessages have variable sizes ("[]" in network.py). another possibility would perhaps be a fixed size and not use everything 00:20 <+bridge> [ddnet] and yes, for the last part I was thinking about some kind of compression. for example at the very least not send inputs every single tick if the input only changed some of them 00:21 <+bridge> [ddnet] yeah it would compress very well with run-length encoding 00:25 <+bridge> [ddnet] was also thinking about bit-packing the data (in theory a single input could be packed into 16 bits or less if you send an angle instead of a target and sacrifice accuracy a little :P), but that ended up being a bit complicated 00:27 <+bridge> [ddnet] you could still bit pack the rest of the input I guess 00:27 <+bridge> [ddnet] I think the server need mouse position for anit-bot 00:27 <+bridge> [ddnet] I think the server need mouse position for anti-bot 00:28 <+bridge> [ddnet] yes, I guess it does 07:55 <+bridge> [ddnet] soon at this pace and the account system will appear 07:55 <+bridge> [ddnet] and api for mods 07:55 <+bridge> [ddnet] :trollet: 09:19 <+bridge> [ddnet] hello dumb question. if you fork a repo and want to stay "compatible" with the newest ddnet/master, but you want to have your own master like fork/master. and put all your features into the master plus change readme and everything. 09:19 <+bridge> [ddnet] whats the best workflow? i am confused. merge? 09:19 <+bridge> [ddnet] make my repo as origin/upstream and frequently merge ddnet/master into it? having it as a second remote named ddnet, but not upstream for any branch? 09:19 <+bridge> [ddnet] i just want to put some features together but dont want to stay behind ddnet/master. 09:20 <+bridge> [ddnet] hello dumb question. if you fork a repo and want to stay "compatible" with the newest ddnet/master, but you want to have your own master like fork/master. and put all your features into your own master plus change readme and everything. 09:20 <+bridge> [ddnet] whats the best workflow? i am confused. merge? 09:20 <+bridge> [ddnet] make my repo as origin/upstream and frequently merge ddnet/master into it? having it as a second remote named ddnet, but not upstream for any branch? 09:20 <+bridge> [ddnet] i just want to put some features together but dont want to stay behind ddnet/master. 09:21 <+bridge> [ddnet] hello dumb question. if you fork a repo and want to stay "compatible" with the newest ddnet/master, but you want to have your own master like fork/master. and put all your features into your own master plus change readme and everything. 09:21 <+bridge> [ddnet] whats the best workflow? i am confused. merge? 09:21 <+bridge> [ddnet] make my repo as origin/upstream and frequently merge ddnet/master into my fork master? having ddnet master as a second remote named ddnet, but not upstream for any branch? 09:21 <+bridge> [ddnet] i just want to put some features together but dont want to stay behind ddnet/master. 09:25 <+bridge> [ddnet] i just have the problem that i have a feature branch where i changed hud specific things but the branch is one month behind and now with the new hud in master i have merge conflicts... 09:25 <+bridge> [ddnet] i guess ill just code it again 09:26 <+bridge> [ddnet] based on current master, easier than understanding all the merge conflicts 09:27 <+bridge> [ddnet] it might be easier to do a rebase 09:28 <+bridge> [ddnet] If you do it with a good IDE, you could also use the new hud files and ignore changes from you and reimplement it. The other changes could be merged as usual 09:30 <+bridge> [ddnet] ye ok, ill just reimplement 09:30 <+bridge> [ddnet] yes ok, ill just reimplement 09:31 <+bridge> [ddnet] whats the ide got to do with it? is rebase a manual thing like resolving merge conflicts? i use ms vscode 09:31 <+bridge> [ddnet] yes ok, i'll just reimplement 10:46 <+bridge> [ddnet] separating your changes into separate files or functions and making minimal changes to original code makes it a lot easier when possible. 11:14 <+bridge> [ddnet] Make ur own branch 11:32 <+bridge> [ddnet] can we have a ingame wordfilter? at least for twitch? 12:16 <+bridge> [ddnet] u can hide whole chat or only show msgs from friends already 12:41 <+bridge> [ddnet] @Tater have you considered simply sending multiple input packets? 12:42 <+bridge> [ddnet] our game/engine packets are coalesced into UDP packets 12:44 <+bridge> [ddnet] map editor autosaving 12:44 <+bridge> [ddnet] @Simon' yes, that would probably be good for streamers 12:57 <+bridge> [ddnet] no worries, as maintainer i should have called that out earlier 12:58 <+bridge> [ddnet] The packets are automatically combined? Are you sure it doesn't add significant overhead sending lots of input packets every tick? it would certainly be easy to do if thats the case 12:59 <+bridge> [ddnet] they are automatically combined until you send a packet with `NETSENDFLAG_FLUSH` 13:00 <+bridge> [ddnet] `NETSENDFLAG_FLUSH` tells the network to send everything it has out 13:00 <+bridge> [ddnet] (or until the buffer for one packet is full) 13:00 <+bridge> [ddnet] oh wow that's very nice 13:00 <+bridge> [ddnet] extra overhead per packet: 2 byte 13:00 <+bridge> [ddnet] extra overhead per packet: 2 bytes 13:00 <+bridge> [ddnet] extra overhead per sub-packet: 2 bytes 13:02 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blob/c345bc6993332fc1969650121d7aab4fa49ce270/src/engine/shared/network.h#L19-L35= 13:02 <+bridge> [ddnet] "chunk header" 13:02 <+bridge> [ddnet] I'll look more at that later, it would probably be better if trml implemented this system but I'll give it a try if he is busy 13:04 <+bridge> [ddnet] you don't need to implement anything server-side, right? 13:06 <+bridge> [ddnet] well in my testing the server is currently not very good at handling duplicate packets, I was able to fix it but the code path for inputs on the server seems very complex 13:06 <+bridge> [ddnet] ah ๐Ÿ˜ฆ 13:11 <+bridge> [ddnet] I don't really know why it's so complex but its rather scary code to touch especially with the lack of any tests 13:12 <+bridge> [ddnet] that is very appreciated 13:22 <+bridge> [ddnet] "Don't think that helps much personally. There can always be creative wordings that are not blocked." what about not blocking names but ip adresses, so u cant just rejoin with another name? 13:46 <+bridge> [ddnet] various refactoring 13:57 <+bridge> [ddnet] people are actually really motivated to spam and use proxies to circumvent IP bans 15:48 <+bridge> [ddnet] ah... i'll just try to merge with resolving conflicts, not want to reimplement xd 15:49 <+bridge> [ddnet] yes, that's the best way, but can i somehow say github that they sould show my branch as default branch on my fork. because i want a "fork readme" and not the master branch that's identical to the ddnet master 15:51 <+bridge> [ddnet] you can name the upstream branch upstream and have your own master branch be the main 15:52 <+bridge> [ddnet] or change the default branch https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch 15:54 <+bridge> [ddnet] i never forked something before, i guess it's obvious how to do it... xd i'll just change the default branch i think, name it "cauldron" and push it to my own repo. merge all my other branches into the cauldron branch and merge ddnet/master into the cauldron branch. in my theory it's cool. 15:54 <+bridge> [ddnet] but maybe not xd 16:20 <+bridge> [ddnet] lol, So it will be, there are more and more people, therefore, the community is growing :nouis: 22:05 <+bridge> [ddnet] https://blog.rust-lang.org/2022/06/30/Rust-1.62.0.html 22:05 <+bridge> [ddnet] @ReiTW hehe 22:05 <+bridge> [ddnet] @Not Keks this update makes it even easier to write kernels 22:05 <+bridge> [ddnet] before u had to do some config to disable the red zone 22:05 <+bridge> [ddnet] with the new compile target u dont need to 22:06 <+bridge> [ddnet] also now rust uses its on mutexes instead of using pthread 22:06 <+bridge> [ddnet] from 40 byte overhead to 5 bytes 22:06 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/992159293786816562/unknown.png 22:06 <+bridge> [ddnet] :BASED: 22:07 <+bridge> [ddnet] epic 22:08 <+bridge> [ddnet] https://news.ycombinator.com/item?id=31935116 22:08 <+bridge> [ddnet] discussion 22:15 <+bridge> [ddnet] now only godot 4 is missing 22:25 <+bridge> [ddnet] I wonder what they did with mutexes on windows, they also have something similar to futexes but they also have critical sections that are part of the winapi. The two have very different performance characteristics obv 22:27 <+bridge> [ddnet] Also futex based locks can't really be moved either, I wonder what they were talking about there 22:29 <+bridge> [ddnet] heck, it's also the reason pthread based mutexes can't be moved because glibc and most other libcs use futexes under the hood ๐Ÿ˜„ 22:29 <+bridge> [ddnet] it rly improved perf tho 22:29 <+bridge> [ddnet] idk 22:30 <+bridge> [ddnet] but i guess the key part is this 22:30 <+bridge> [ddnet] > The pthreads locks support more features than the Rust APIs themselves do, including runtime configuration, and are designed to be used in languages with fewer static guarantees than Rust provides. 22:30 <+bridge> [ddnet] **and are designed to be used in languages with fewer static guarantees than Rust provide** 22:30 <+bridge> [ddnet] https://github.com/rust-lang/rust/issues/93740 22:30 <+bridge> [ddnet] I don't doubt that it improved performance, why would they lie about that. I was just wondering what they were talking about with movability and what they did on windows for parity 22:31 <+bridge> [ddnet] no 22:31 <+bridge> [ddnet] they said that pthread cannot be moved 22:31 <+bridge> [ddnet] and so to make that guarantee on rust 22:31 <+bridge> [ddnet] they have to be boxed 22:31 <+bridge> [ddnet] and thats an allocation 22:31 <+bridge> [ddnet] which is now removed 22:31 <+bridge> [ddnet] by using their own impl 22:31 <+bridge> [ddnet] Ah, so the new implementation might not be movable either, it just doesn't need a box 22:31 <+bridge> [ddnet] as far as i udnerstand 22:33 <+bridge> [ddnet] @Learath2 i think before it did 2 allocations 22:33 <+bridge> [ddnet] if u used arc mutex 22:33 <+bridge> [ddnet] so now its 12 22:34 <+bridge> [ddnet] 1 22:34 <+bridge> [ddnet] in the future when they stabilize scoped threads without needed a library as is now, you can avoid the arc 22:34 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/992166266565578752/unknown.png 22:34 <+bridge> [ddnet] in the future when they stabilize scoped threads without a needed a library as is now, you can avoid the arc 22:37 <+bridge> [ddnet] Huh, bizarre, how does this thread scope thing even work? Seems you can spawn 2 threads in the same scope and both can borrow the same thing at the same time 22:38 <+bridge> [ddnet] because with the scope rust can know the value lives as long as needed (aka as long as the scope lives) 22:39 <+bridge> [ddnet] the std says it better 22:39 <+bridge> [ddnet] > Unlike non-scoped threads, scoped threads can borrow non-'static data, as the scope guarantees all threads will be joined at the end of the scope. 22:39 <+bridge> [ddnet] > 22:39 <+bridge> [ddnet] > All threads spawned within the scope that havenโ€™t been manually joined will be automatically joined before this function returns. 22:39 <+bridge> [ddnet] https://doc.rust-lang.org/nightly/std/thread/fn.scope.html 22:40 <+bridge> [ddnet] Oh, so when `thread::scope` returns the threads spawned within it will have joined already 22:40 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/992167756281688184/unknown.png 22:40 <+bridge> [ddnet] yeah 22:40 <+bridge> [ddnet] and u can handle errors by joining them explicitly 22:40 <+bridge> [ddnet] otherwise if one panics it will panic too 22:41 <+bridge> [ddnet] I see, that does sound useful indeed 22:41 <+bridge> [ddnet] it allows to avoid Arc on most cases 22:41 <+bridge> [ddnet] A lot of Arcs can be avoided that way 22:41 <+bridge> [ddnet] ye 22:41 <+bridge> [ddnet] Arc is the multithreaded way to make a value live for 'static more or less 22:41 <+bridge> [ddnet] xd 22:43 <+bridge> [ddnet] @Learath2 have u used lazy_static? 22:43 <+bridge> [ddnet] yes, with a regex 22:44 <+bridge> [ddnet] i hate tweets but she tweets a lot of good stuff about rust 22:44 <+bridge> [ddnet] https://twitter.com/m_ou_se/status/1538209506085244929 22:44 <+bridge> [ddnet] tldr u can avoid it in 1.63 22:44 <+bridge> [ddnet] due to mutex new being const 22:44 <+bridge> [ddnet] Oh that's nice too 22:45 <+bridge> [ddnet] "On Linux and *BSD these use futex() syscalls directly. On Windows, they're wrappers around SRW locks. On macOS, these (still) use pthread's locks, but now lazily allocated and initialized." 22:45 <+bridge> [ddnet] macos always there to be funny 22:45 <+bridge> [ddnet] This is the new mutex implementation? 22:45 <+bridge> [ddnet] nah thats for the future const new mutex 22:46 <+bridge> [ddnet] well yeah 22:46 <+bridge> [ddnet] SRW locks are nice 22:46 <+bridge> [ddnet] but maybe it uses that on 1.62 22:50 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/992170178144120994/unknown.png 22:50 <+bridge> [ddnet] found it 22:58 <+bridge> [ddnet] Huh, surprising they didn't match parking_lot in the no contention case given how similar their implementation looks 22:58 <+bridge> [ddnet] but that's a massive improvement indeed, very nice to see things moving forward in a language 22:58 <+bridge> [ddnet] C++ is permastuck with pthread ones 23:13 <+bridge> [ddnet] xD 23:24 <+bridge> [ddnet] https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/ 23:24 <+bridge> [ddnet] https://news.ycombinator.com/item?id=31932250 23:25 <+bridge> [ddnet] > If it is, as you claim, permissible to train the model (and allow users to generate code based on that model) on any code whatsoever and not be bound by any licensing terms, why did you choose to only train Copilot's model on FOSS? For example, why are your Microsoft Windows and Office codebases not in your training set? 23:48 <+bridge> [ddnet] Difference between github and sourceforge is that github isn't a shit product. It's very convenient and pretty, furthermore new generation of open source developers aren't as ideological as the ones we had back in the day. Good luck convincing hipsters that fetishize UI/UX to switch 23:48 <+bridge> [ddnet] The only way I see github ever dying like sourceforge is if massive projects decide to move away from it, which is unlikely given most seem to be moving to github rather than away from github