Teeworlds - bridge

.

00:50

you could always mute channels you don't want to see

00:52

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

Just because discord doesn't technically doesn't have a monopoly doesn't mean they don't have enough users to practically be one

o.O the predict pr works awesome! https://zillyhuhn.com/OpenTube/video.php?t=teeworlds_predict_pr2650.mp4

Still the other tees stutter a bit when they are moving

10:24

What about some machine learning to predict the input of the other players? :D

lol

10:33

we should use blockchain

10 years ago it'd be big data

10:38

ZillyHuhn: I don't see any difference. Isn't it supposed to be unnoticeable on a LAN server?

You can especially see it when he's hooking his dummy up. Without the prediction there is a noticable delay.

ah ,right

its not a lan server this was recorded on a 200 ping server

Gj @Oblikumquat

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

ctrl shift d can help since you shoot from the non-predicted tee

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

Agree

should comment that on the PR

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.

blergh dissect everything in a dozen of options

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

12:00

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.

@redix why do you draw the line at weapons/entities?

12:10

if one found a good way to share the code between client and server, I wouldn't really see issues with it

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

12:14

A solution would be a predictable id allocation for entities. But that would require a new major version I guess

ddnet implementation is really the best I've seen yet but it's still way too much code duplication imho

Yes absolutely

Unreal engine deals with this issue by having a "core" for each entity that is the only thing that's shared

12:17

but they have the advantage of having the server and client be the exact same binary to begin with

Let's implement the core in lua or wasm and send it to the client :D

you could compile the C++ code we have to wasm

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

12:34

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

why not vanilla?

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

well, the vm would definitely need to be a well-maintained library, yes

how big are wasm vms?

depends on what you need... interpreter, ahead of time compilation, JIT