02:50 < chococoala> .
02:50 < chococoala> you could always mute channels you don't want to see
02:52 < chococoala> i also wouldn't say discord has a "monopoly" as it's free and there are other options if you choose. there's not too much barrier to entry for online chat programs
09:05 < bridge> [teeworlds] <Learath2> Just because discord doesn't technically doesn't have a monopoly doesn't mean they don't have enough users to practically be one
12:14 < ZillyHuhn> o.O the predict pr works awesome! https://zillyhuhn.com/OpenTube/video.php?t=teeworlds_predict_pr2650.mp4
12:20 < bridge> [teeworlds] <redix> Still the other tees stutter a bit when they are moving
12:24 < bridge> [teeworlds] <redix> What about some machine learning to predict the input of the other players? :D
12:33 < ZillyHuhn> lol
12:33 < ZillyHuhn> we should use blockchain 
12:37 < bridge> [teeworlds] <Dune> 10 years ago it'd be big data
12:38 < bridge> [teeworlds] <Dune> ZillyHuhn: I don't see any difference. Isn't it supposed to be unnoticeable on a LAN server?
12:42 < bridge> [teeworlds] <redix> You can especially see it when he's hooking his dummy up. Without the prediction there is a noticable delay.
12:43 < bridge> [teeworlds] <Dune> ah ,right
12:44 < ZillyHuhn> its not a lan server this was recorded on a 200 ping server
12:44 < bridge> [teeworlds] <Sonix> Gj @Oblikumquat
12:44 < bridge> [teeworlds] <redix> It is sometimes really annoying that the own tee is not in sync with projectiles and other tees. When the server has high bandwidth I sometimes even play without prediction at all :O makes it a bit easier to avoid nades
12:45 < bridge> [teeworlds] <Dune> ctrl shift d can help since you shoot from the non-predicted tee
12:54 < bridge> [teeworlds] <redix> While it's not working perfectly, it should be considered to merge this... but disabled by default and no advanced stuff like rocket jump prediction. That would just require too much shared code and cause problems with modded weapons
13:07 < bridge> [teeworlds] <Sonix> Agree
13:07 < bridge> [teeworlds] <Dune> should comment that on the PR
13:39 < bridge> [teeworlds] <fokkonaut> I commented it already, an option to predict specific weapons only. That would be good if you want to play on modded servers, then special weapons are not predicted.
13:49 < bridge> [teeworlds] <Dune> blergh dissect everything in a dozen of options
13:55 < bridge> [teeworlds] <redix> The code needed to predict weapons/entities is just bloat that does not belong into the official game. The stuff included in this PR would be okay but anything beyond that should go into custom clients
14:00 < bridge> [teeworlds] <redix> Instead of using client side options for this, the server should tell the client to activate/deactivate weapon prediction. The server knows best if it's physics are compatible with the prediction.
14:09 < bridge> [teeworlds] <heinrich5991> @redix why do you draw the line at weapons/entities?
14:10 < bridge> [teeworlds] <heinrich5991> if one found a good way to share the code between client and server, I wouldn't really see issues with it
14:12 < bridge> [teeworlds] <redix> Well I haven't seen a good implementation for that yet. A problem is for example merging the entities created locally with the new ones from the snapshot. The ddnet implementation compared the properties of both. This kinda works but isn't really a nice solution for the official game
14:14 < bridge> [teeworlds] <redix> A solution would be a predictable id allocation for entities. But that would require a new major version I guess
14:14 < bridge> [teeworlds] <Learath2> ddnet implementation is really the best I've seen yet but it's still way too much code duplication imho
14:15 < bridge> [teeworlds] <redix> Yes absolutely
14:15 < bridge> [teeworlds] <Learath2> Unreal engine deals with this issue by having a "core" for each entity that is the only thing that's shared
14:17 < bridge> [teeworlds] <Learath2> but they have the advantage of having the server and client be the exact same binary to begin with 😛
14:18 < bridge> [teeworlds] <redix> Let's implement the core in lua or wasm and send it to the client :D
14:19 < bridge> [teeworlds] <heinrich5991> you could compile the C++ code we have to wasm 😉
14:33 < bridge> [teeworlds] <Learath2> matricks worked on something similar iirc, I think he went a little overboard trying to write an entire VM and come up with a bytecode though
14:34 < bridge> [teeworlds] <Learath2> The core being sent over the network will never happen in vanilla anyway, might aswell try to look for solutions that don't involve that
15:08 < bridge> [teeworlds] <heinrich5991> why not vanilla? 🙂
15:15 < bridge> [teeworlds] <Learath2> Can you imagine oy letting us link with a wasm vm? Any solution would probably need to be custom made which is a big no no when you are letting remote code execute on your own machine
15:17 < bridge> [teeworlds] <heinrich5991> well, the vm would definitely need to be a well-maintained library, yes
15:44 < bridge> [teeworlds] <Dune> how big are wasm vms?
15:49 < bridge> [teeworlds] <redix> depends on what you need... interpreter, ahead of time compilation, JIT
15:52 < bridge> [teeworlds] <redix> this one is kinda small: https://github.com/bytecodealliance/wasm-micro-runtime
15:52 < bridge> [teeworlds] <redix> there are ones that are based on clang... probably faster but way bigger
15:53 < bridge> [teeworlds] <redix> this one is probably a good compromise: https://github.com/bytecodealliance/wasmtime
15:53 < bridge> [teeworlds] <redix> 8 to 14 MB depending on the platform
15:53 < bridge> [teeworlds] <redix> but still big compared to tw itself
15:56 < bridge> [teeworlds] <Learath2> I did start integrating WAMR into teeworlds but the gamecontroller kept getting in the way so I started cleaning that up instead, then I got bored of it 😛
15:57 < bridge> [teeworlds] <Learath2> Well got bored because of scope creep tbh
15:57 < bridge> [teeworlds] <Learath2> I wanted to ship something actually usable for modders if I cleaned up the gamecontroller
15:59 < bridge> [teeworlds] <redix> data exchange between the host and the VM is still hard =\
15:59 < bridge> [teeworlds] <redix> once the interface types thing is ready, it will hopefully be easier to design usable APIs
16:00 < bridge> [teeworlds] <Learath2> it's inconvenient but at least it's a clean interface
16:14 < bridge> [teeworlds] <Learath2> Does the gamecontext actually need to know whether this is a team game?
16:36 < bridge> [teeworlds] <heinrich5991> @redix how did you get the sizes?
16:38 < bridge> [teeworlds] <redix> downloaded the latest release from here:
16:38 < bridge> [teeworlds] <redix> https://github.com/bytecodealliance/wasmtime/releases
16:38 < bridge> [teeworlds] <redix> an embeddable version might be smaller though
16:57 < bridge> [teeworlds] <heinrich5991> I get 14MB, 5MB stripped, 2MB stripped+gzipped for a simple wasmtime example application
17:01 < bridge> [teeworlds] <redix> Okay 5MB stripped sounds better. Still bigger than tw itself
17:01 < bridge> [teeworlds] <heinrich5991> tw is 10MB afaik
17:01 < bridge> [teeworlds] <redix> the binary i mean
17:02 < bridge> [teeworlds] <heinrich5991> I can put it into a dynamically linked library if you want to have the executable size down 😛
17:02 < bridge> [teeworlds] <redix> 1.5 - 2 mb depending on platform and compiler
17:02 < bridge> [teeworlds] <heinrich5991> the interesting thing is the total size of tw, no?
17:03 < bridge> [teeworlds] <redix> well I would not mind a few mb. but oy might 😄
17:03 < bridge> [teeworlds] <redix> but i guess he won't like the idea of shipping a vm in general