00:32 < bridge> @sollybunny I even implemented a duo-tree today, always splitting a rectangle on the longest side, this isn't too hard, hard can be efficient updating 00:34 < bridge> and you will want to implement a range search in the quadtree in order to find nearby entities to check collisions with, this is the only benefit 00:35 < bridge> I think quad trees don't make sense in ddnet, because the overhead is too big for only 64 players 00:35 < bridge> I think quad trees currently don't make sense in ddnet, because the overhead is too big for only 64 players and the game doesn't contain too many entities 00:37 < bridge> it would make more sense if ddnet would work with mapchunks, which also could be integrated into a tree, similar to minecraft chunks. You don't want to check if you collide with a creeper with every creeper in a minecraft world 😄 00:58 < bridge> because we need to switch the texture for each sprite of the tee 01:09 < ws-client> @barbs0327 could you describe the bugs in words? 01:09 < bridge> But there's all on the same texture? 01:09 < bridge> wdym 01:09 < bridge> It gets separated in memory? 01:09 < bridge> everything gets cropped & chunked out afaik 01:09 < bridge> before it even gets to the gpu 01:09 < bridge> But you don't have to do it that way 01:09 < bridge> yeah i mean you can treat it as an atlas 01:09 < bridge> but that's not how it works rn 01:10 < ws-client> I am not sure if JSaurursRex is maintaining that modification. I for sure am not. I am maintaining the server at 88.198.96.203:8309 "ChillerDragon's CTF GER1" but it would still be good to know what kind of bug. 01:11 < bridge> Idk the atlas doesn't even sound that hard right? We already have them on one texture and know the coordinates. 01:12 < bridge> Is it because of the tee colors? 01:12 < bridge> Those get stored in the texture itself? 01:13 < bridge> you'd need a shader to change the color if not 01:13 < bridge> which idk if it does already 01:13 < bridge> but i would assume not because it's a fairly well known algorithm that's been reproduced in a few other software representations 01:13 < bridge> that web one 01:13 < bridge> idk 01:14 < bridge> i wonder what it actually does yeah 01:15 < bridge> They all write the colors to the texture directly I'm pretty sure 01:16 < bridge> too bad it's american hours rn 01:19 < bridge> updating quad trees isnt that intensive seeing as you only have to do it once per tick at most. each player checks against each player for collisions, and when hooking and for each projectile turning an O(n^2) to a O(n) or less it definatley worth 01:19 < bridge> specially if we go upto 128 clients 01:38 < bridge> <01000111g> does someone has resources/a link to the new years photoshoot mod? I want to do sth similar with my friends 01:48 < bridge> @tsfreddie 01:48 < bridge> if theres not many players u can just photoshop it :P 01:48 < bridge> https://github.com/TeeworldsCN/MomentCap i think its this one 01:48 < bridge> @01000111g 01:48 < bridge> good find 01:48 < bridge> ill use that freddie ping to ask him another question then 01:48 < bridge> ||org reminds me of the BemaniCN 😢|| 01:49 < bridge> that's probably totally lost on u sorry 01:49 < bridge> https://cdn.discordapp.com/attachments/1280247930518896724/1308293172908130335/balls.gif 01:49 < bridge> ||we love ya freddie, no questions and no answers ;3|| 01:57 < bridge> With proper collision you can effortlessly handle thousands :) 01:57 < bridge> ^ 03:40 < bridge> Who can create a script for fifo? 03:41 < bridge> I just want my message to be displayed in the broadcast every specified time. 03:41 < bridge> this is implemented via fifo 03:41 < bridge> But I do not know how 04:46 < bridge> @woidless you can 04:46 < bridge> do some research 04:46 < bridge> i believe in you 07:34 < ws-client> nice website http://www.bricktou.com/arch/x86/include/asm/syscallsyscall_get_error_en.html 07:54 < bridge> I can't do it 07:54 < bridge> I've been trying for 2 weeks now, I've even been looking for a programmer, I'm asking the gpt chat 07:54 < bridge> Nothing helped me. 07:55 < bridge> When I was looking for a programmer, no one understood what I wanted and because they didn't play ddnet 07:56 < bridge> Although I was willing to pay $12 07:57 < bridge> >When I was looking for a programmer, no one understood what I wanted 07:57 < bridge> 07:57 < bridge> You will become a really good project manager 07:57 < bridge> > When I was looking for a programmer, no one understood what I wanted 07:57 < bridge> 07:58 < bridge> You will become a really good project manager 07:58 < bridge> you need to be the programmer 07:58 < bridge> lol 07:58 < bridge> $12 means little to most ppl in here 07:58 < bridge> This command was not found. 07:59 < bridge> you would probably have an easier time getting ppl to help you if you showed initiative & tried to code *with* them instead of just asking them to do it for you 08:04 < bridge> https://tenor.com/view/parks-and-rec-andy-dwyer-oh-yeah-10-bucks-scratch-ticket-scratchcard-gif-3256349126806075052 08:25 < bridge> 2 weeks is nothing 08:26 < bridge> buy yourself some c++ course with that money 08:26 < bridge> better invested 09:05 < bridge> I do not know how python works, I will not be able to use it. 09:06 < bridge> maybe $ 12 is not enough for this job, but it's more difficult for me to find , I can find a maximum of $ 30, I don't know if it's good for just creating a script that simply enters the broadcast command into a fifo file every specified time 09:07 < bridge> I've already ordered a book. 09:47 < bridge> And even then I do not know how long it will take to write a script, maybe a day, maybe a week 10:04 < bridge> <01000111g> thank you! 10:04 < bridge> <01000111g> kinda true, but its hard for me (no skill) 10:23 < bridge> I agree, that this might be viable with 128 players, since, as you already noticed, you'll have 128^2 = 16384 collision checks for players instead of 4096 curently at most 10:42 < bridge> Tbf I cannot say if the bottleneck is purely tee rendering. 10:42 < bridge> But generally in the player rendering pipeline you have a lot of unbatched draw calls. 10:42 < bridge> You first render the left hand + hook, then the right hand + weapon, then the player 10:42 < bridge> 10:42 < bridge> And this is repeated for all players on a per player basis. and even if you render one tee in a whole you still render 1200 tees on its own, since all tees have different skins / weapon textures etc. (potentially) 10:46 < bridge> Tbf I cannot say if the bottleneck is purely tee rendering. 10:46 < bridge> But generally in the player rendering pipeline you have a lot of unbatched draw calls. 10:46 < bridge> You first render the left hand + hook, then the right hand + weapon, then the player 10:46 < bridge> 10:46 < bridge> And this is repeated for all players on a per player basis. and even if you render one tee in a whole you still render 120 tees on its own, since all tees have different skins / weapon textures etc. (potentially) 10:50 < bridge> Hmm yeah it's a lot of draw calls I guess. 10:51 < bridge> Is anyone familiar with some good open source profiling tools for c++? I refuse VSC and the only other solution i found was Orbit from google 10:52 < bridge> on linux u have perf (+ flamegraph), callgrind and i think gcc even has some integrated counter 10:52 < bridge> Also thinking about it, the client will suffer from the n^2 physics much more than the server right? Potentially it must do 1000ms/20=50 ticks of simulation for every actual tick due to prediction. 10:53 < bridge> oh that's good, going to look into that, thank you ❤️ 10:54 < bridge> yeah, defs a big problem 10:54 < bridge> does the client check for collisions? 10:54 < bridge> anti ping has to 10:54 < bridge> and local char pred 10:54 < bridge> It does almost everything 10:58 < bridge> It would be nice if the server and client simply shared the same physics implementation. They're not really that far apart right now. 10:59 < bridge> they are mostly doing this, both client and server include collision and gamecore 10:59 < bridge> but I agree, there could be a better separation 11:00 < bridge> Yeah but they duplicate all entities 11:00 < bridge> ? they have to, they run on different machines. I don't get your point there 11:00 < bridge> I mean the code 11:00 < bridge> There's a duplicate file for each entity 11:01 < bridge> I want less separation lol. None ideally 11:01 < bridge> I mean separation of the physics to the rest of the code 11:01 < bridge> Yeah 11:02 < bridge> slab a version on it and poof, backwards compatible physics 11:03 < bridge> The issue is cleanly integrating all the servers sideffects in the physics in a way the client can ignore 11:03 < bridge> The issue is cleanly integrating all the servers sideeffects in the physics in a way the client can ignore 11:03 < bridge> Idk how ddpg does this tbh 11:03 < bridge> Maybe you just probe the game stack instead of triggering events 11:04 < bridge> Maybe you just probe the game state instead of triggering events 11:05 < bridge> I can tell you how I do it, physics are only done on base-entity-objects and entity-entity-interactions have callbacks 11:06 < bridge> you mean like random teleporters? 11:07 < bridge> No like calling the function that saves your time to avoid database when you touch finish 11:07 < bridge> No like calling the function that saves your time to thw database when you touch finish 11:07 < bridge> ah, yeah the client simply has a dummy database that is disabled 11:07 < bridge> No like calling the function that saves your time to the database when you touch finish 11:07 < bridge> in the end ddnet's database is also optional 11:08 < bridge> But that means the physics depends on the database implementation? 11:08 < bridge> database interactions are async to me 11:09 < bridge> Or you need a bunch of callbacks 11:09 < bridge> no, only on the interface 11:09 < bridge> if they alter physics that cannot be predicted ofc xd 11:09 < bridge> ah there is an interface anyway 11:09 < bridge> Yeah 11:10 < bridge> since wasm has no access to anything 11:10 < bridge> you have to import host functions into the module anyway 11:10 < bridge> and only the server gives access to anything real 11:12 < bridge> How many interfaces does the server need for the physics? 11:12 < bridge> I have no estimate 11:13 < bridge> currently it only has database and terminal (basic logging) 11:13 < bridge> maybe it will need file access too, but ddnet doesnt 😄 11:13 < bridge> (i think) 11:14 < bridge> terminal includes chat? 11:14 < bridge> i meant like create logging 11:14 < bridge> But don't you need chat 11:14 < bridge> yes, it currently only gets chat commands 11:14 < bridge> but chat for me is an input into the wasm module 11:15 < bridge> if you mean that, then it ofc has lot more stuff 11:15 < bridge> rcon commands etc. 11:15 < bridge> the other way around is more interesting bcs it is more unsafe 😄 11:15 < bridge> Input into the module is different from an interface? 11:16 < bridge> well i thought you meant, what the server can call outside of what wasm offers 11:16 < bridge> hmm 11:16 < bridge> But if the physics wants to say "player has finished" how does that happen 11:17 < bridge> Idk what my question is anymore lol 11:18 < bridge> well twgame for example uses a mpsc channel. 11:18 < bridge> The player hits the finish line -> then the player_tick or whatever checks for events in that channel and starts a database query. 11:18 < bridge> and the query itself happens async 11:18 < bridge> and the database query itself uses a database interface 11:18 < bridge> the client uses a dummy database which implements that interface 11:19 < bridge> except for the actual query all things happen inside the physics module tho 11:21 < bridge> What doesn't happen in the physics module then? 11:22 < bridge> I thought it was very limited 11:22 < bridge> i mean what does limited mean. wasm allows you to basically do anything that doesnt require a kernel call (even allocations) 11:22 < bridge> so you couldn't just do a http request 11:22 < bridge> Snapshot packets? 11:23 < bridge> ok 11:23 < bridge> ah that happens indeed outside of it 11:23 < bridge> well no 11:23 < bridge> 50:50 11:23 < bridge> 11:23 < bridge> the snapshot binary data is inside the physics module. but the compression / binary diff etc happen outside 11:25 < bridge> How can you require a database interface on the client if this module is supposed to be sent over the network. Does that mean servers need to use the standard interface? 11:28 < bridge> The wasm module has imports, which are functions inside a wasm module without a state or anything else. 11:28 < bridge> so e.g. you do `call_sql("SELECT ..")` inside the wasm module. and then inside the host you can do with that information whatever you want. 11:28 < bridge> The client simply returns an error that this is unsupported. 11:28 < bridge> 11:28 < bridge> This is very simplified, bcs i abstracted these simple functions away using derive macros, in the end it feels more like you use a instance of a database object. 11:28 < bridge> 11:28 < bridge> so you do `object.query(my_statement)` and the rest happens hidden away from the user 11:29 < bridge> ok that makes sense 11:32 < bridge> the color is added in the shader. 11:32 < bridge> the client doesn't use texture atlasses, probably because the colors might leak over (?) 11:33 < bridge> Not even for the tile atlases? 11:33 < bridge> Those get separate textures? 11:35 < bridge> btw with 128 tees that do random inputs on ctf1 i get an avg of: 11:35 < bridge> ``` 11:35 < bridge> 28601 t/s 11:35 < bridge> 29154 t/s 11:35 < bridge> ``` 11:35 < bridge> with the non O(n²) approach 11:35 < bridge> 11:35 < bridge> Which surprises me, this is like 2x more than i had a month ago lol. 11:35 < bridge> Time to git bisect xd 11:35 < bridge> 11:35 < bridge> But defs worth to optimize it ig 11:36 < bridge> those are texture arrays. those are great and work well with same-sizes textures 11:37 < bridge> This sounds high but it limits perceived smoothness to 29000/50 "fps" if you do it on the same thread 11:38 < bridge> which is probably fine 11:38 < bridge> what if all parts of tee will render batched? 11:38 < bridge> yep, kinda sad, but i'd assume ddnet does much worse even 11:38 < bridge> Not many people are playing with 1000ms 11:38 < bridge> is it the same in terms of visuals 11:38 < bridge> Am i a fortune teller xD 11:38 < bridge> it's first of all not easy 11:39 < bridge> skins can have hd variants so texture arrays are not really usable 11:39 < bridge> you are :troll: 11:39 < bridge> on high end gpus u can probably bind like 200 textures at once 11:39 < bridge> The teero tater client has identical physics at 3x+ the speed of the github one but I don't want to publish these changes because it only helps botters lol 11:39 < bridge> in one shader 11:40 < bridge> yep, but i guess yours is mostly optimized for single player 11:40 < bridge> can you dynamically select one? 11:40 < bridge> e.g. a pickup also goes through all characters in cpp version 11:40 < bridge> afaik there are at least extensions for that 11:41 < bridge> oh neat 11:41 < bridge> Not entirely true, it replaces length checks with square distance to decide if it should do the expensive check which is a huge gain for multi tee and high entity counts 11:41 < bridge> But now I'm leaking 11:41 < bridge> xd 11:41 < bridge> i see 11:42 < bridge> we can switch to a different chat 11:43 < bridge> There's nothing too ground breaking I just look at the profiler and optimize the expensive parts over and over 11:43 < bridge> yeah i basically did the same 11:43 < bridge> but i cannot fully trust the flamegraph i use XD 11:43 < bridge> 11:43 < bridge> it 100% wasnt so fast a month ago 11:43 < bridge> and i only rewrote other stuff than physics 11:44 < bridge> Quad tree or spatial having would eliminate n^2 but idk if you can have collision order perfect consistency with the slow version 11:44 < bridge> Quad tree or spatial hashing would eliminate n^2 but idk if you can have collision order perfect consistency with the slow version 11:45 < bridge> i mean collision order in ddnet is just the client id sorted or not? 11:45 < bridge> No 11:45 < bridge> it always does for i < MAX_CLIENTS .. 11:45 < bridge> There's 2 currently 11:45 < bridge> There's client ID and week strong order 11:45 < bridge> Both affect physics 11:45 < bridge> yeah but week strong still exists in my version too 11:46 < bridge> i only optimized the fetching of which ids are interesting 11:46 < bridge> idk 11:49 < bridge> i mean it scales better than lineary now. 11:49 < bridge> 11:49 < bridge> 64 tees are more efficient to calculate than 1 tee 11:49 < bridge> so it must work ig xd 11:49 < bridge> (if i just divide the ticks/s with 64) 11:49 < bridge> You did something special for tee checking? 11:50 < bridge> Wait better than linear??? 11:50 < bridge> That's impossible lol 11:51 < bridge> yeah, i created a world field where every tile contains the ids of the current tees inside the tile. 11:51 < bridge> 11:51 < bridge> as long as you don't stack redicolously, like 128 tees in 1 tile, this removes the O(n²) and is O(n) 11:51 < bridge> i mean there is other overhead than physics in the whole tick 11:51 < bridge> so maybe it's possible 11:51 < bridge> O(n) is linear 11:51 < bridge> yes 11:51 < bridge> i mean the actual results xD 11:52 < bridge> like with 1 tee i have 350k ticks 11:52 < bridge> with 64 i have 40k ticks 11:52 < bridge> Well that's C + O(n) 11:52 < bridge> 350000/64 = 5468.75 11:53 < bridge> So what method do you use for moving tees 11:53 < bridge> you mean move_box? 11:54 < bridge> or inside the field? 11:54 < bridge> No for tee<->tee 11:54 < bridge> Like if a tee moves across multiple tiles in 1 tick, you have to check all of them 11:54 < bridge> to sum it up shortly: 11:54 < bridge> i get a list of all ids of neighbouring tiles of the current tees position 11:55 < bridge> This is just spatial hashing tho right? 11:55 < bridge> kinda 11:56 < bridge> How it is not 11:57 < bridge> i dunno, i dont have an exact defintion, but yeah it looks similar 11:58 < bridge> i guess since tees are always a circle you don't need them to be in mutliple tiles at once 11:59 < bridge> Rly? 11:59 < bridge> i'd say so xd 12:00 < bridge> I guess TW has no unskippable interactions with entities right? 12:00 < bridge> So you skip needing to do intersection over buckets to find fast collisione 12:00 < bridge> So you skip needing to do intersection over buckets to find fast collisions 12:03 < bridge> I think you're just assuming a maximum object size with this 12:04 < bridge> You can use a bigger radius for all collisions to avoid figuring out how many buckets they should be in 12:04 < bridge> It's asymptotically linear but for a normal number of tees you're not reaching that asymptote 12:05 < bridge> Better than linear observed performance is possible with an apparently linear algorithm because of many reasons. The algorithms are usually not linear over their whole domain but only after a certain limit. The compiler can aggressively vectorize giving similar performance for a couple n in a row 12:05 < bridge> Many others 12:05 < bridge> Scaling doesn't factor the constant cost in the calculation so you ignore the overhead 12:06 < bridge> Wait+ 12:06 < bridge> Wait! 12:06 < bridge> @jupeyy_keks how do you have laser walls and those things 12:06 < bridge> They will break your 1 bucket per item model 12:06 < bridge> what is that? i implemented vanilla 😬 12:07 < bridge> but anyway, most entities only check for itself<->character collision or not? 12:07 < bridge> i dont know any entity that does entity<->entity collision 12:07 < bridge> Its still n*n 12:07 < bridge> Its still n*m 12:07 < bridge> For map lasers 12:08 < bridge> but why 12:08 < bridge> how else? 12:08 < bridge> you have n lasers, but only check for the characters in range 12:08 < bridge> There are currently none. But I guess you do preclude them from existing in future mods too 12:08 < bridge> which is O(1) 12:08 < bridge> Every tee has to check every laser once per tick 12:08 < bridge> but doesnt ever laser check for all characters in range instead? 12:09 < bridge> or wait 12:09 < bridge> is that part of the movement? 12:09 < bridge> of a char 12:09 < bridge> It is part of movement 12:09 < bridge> i see 12:09 < bridge> Currently lasers aren't checked like that iirc. They insert imaginary stoppers 12:09 < bridge> It's not a real entity<->entity collision 12:10 < bridge> well we'll find a solution for them if the time comes xD 12:10 < bridge> but yeah they sound like they always consume a tile, similar to any tiles 12:10 < bridge> ok they can be diagonal right 12:10 < bridge> that ofc sucks 12:11 < bridge> I mean fully correct spatial hashing is a valid solution 12:11 < bridge> but in worst case you could assume their length is treated as the diameter? 12:11 < bridge> Its not that hard 12:12 < bridge> Yes 12:12 < bridge> sure, could try that some day 12:12 < bridge> But 1 tile size is small tbh 12:12 < bridge> for now i just wanted 2000 tees on my screen xd 12:14 < bridge> Quad tree is like a fancier version you get to have small and big buckets, at more cost. But it's probably not worth it at all for just the lasers 12:14 < bridge> They can just update a few dozens buckets per tick 12:15 < bridge> I've stared at this problem for a while now. Quadtrees are not great for this usecase. Updating them is too annoying 12:16 < bridge> I mean Jupstar has apparently already proved you don't need it 12:17 < bridge> Spatial hashing is good enough 12:17 < bridge> I mean teeworlds has also proven that you can get away with O(n^2) for a loooong time 12:17 < bridge> well with n=<64 you can do almost anything 12:18 < bridge> if grenades would collide with each other this wouldn't be viable lol 12:19 < bridge> Shouldn't you instead only be updating the smallest node of the tree that contains the laser? I guess you'll get less fine grained collisions that way so it's a trade-off between a more complex update and more expensive collisions 12:19 < bridge> There is no tree 12:19 < bridge> I'm just thinking that in realistic play scenarios the more expensive collisions won't be expensive at all 12:19 < bridge> So to correct my intial wrong benchmark: 12:19 < bridge> ``` 12:19 < bridge> 6442 t/s 12:19 < bridge> 6678 t/s 12:19 < bridge> ``` 12:19 < bridge> 12:19 < bridge> Which is still quite good if we assume the 1p vs 128p bencmark 12:19 < bridge> But still much less 12:20 < bridge> Quadtrees and spatial hashing are broad passes of collision. It's to cull things that you can't possibly collide with. So they wouldn't change the "resolution" of it 12:20 < bridge> Wdym resolution 12:20 < bridge> Nvm 12:20 < bridge> Replying to this "fine grained" comment 12:21 < bridge> At the end of the day you just have to do the box/sphere/capsule/whatever collision check 12:22 < bridge> I mean, the tree consists of a bunch of different sized quads, so depending on which size you're comparing against you'll get information that's of different levels of usefulness 12:22 < bridge> One thing is for certain. if all 128p in ddnet would be active at the same time and collide with each other, we probably have super bad performance xD 12:22 < bridge> point being that lasers would naturally be placed in much larger quads 12:22 < bridge> so PSSST 12:23 < bridge> I feel like calculating the collisions of 128 players should be no problem at all, but calculating the result of those collisions might be depending on how it's done 12:24 < bridge> but you calculate it a few houndred times on the client 12:24 < bridge> If your tree has quads that are very small your broadpass eliminates a lot, but your updates get expensive. If they are very large it degenerates to current ddnet situation 12:24 < bridge> 100*128 = ? 12:24 < bridge> So there is a balance there 12:24 < bridge> This is still actually quite good I didn't do the math on your previous one but it would have been insane lol 12:24 < bridge> yeah i added spectator slots recently and didnt update the benchmark lol xD 12:24 < bridge> pros at work 12:24 < bridge> I think 128 still doesn't completely break. I remember someone testing it with just tees dumped into the start of a map 12:25 < bridge> How fast is your single tee 12:25 < bridge> that's still on the order of tens of thousands, should be doable in less than a millisecond if you do it right, right? 12:25 < bridge> 256 is where it starts breaking down and 512 is barely still working iirc 12:26 < bridge> Wym by do it right? I'm guessing Jupstar is more talking about the current situation. There are obv ways to do it properly and handle far more 12:27 < bridge> I'm just not exactly seeing the reason why we can't do it properly, so I'm assuming there's something fundamentally difficult about keeping identical behaviour 12:27 < bridge> around 350k. 12:27 < bridge> 12:27 < bridge> And the flamegraph shows that most is spend in the pickups. 12:28 < bridge> 12:28 < bridge> so since it's vanilla and ctf1 you can do your own math. 12:28 < bridge> If i disable that i get around 500k 12:28 < bridge> ok im pretty impressed by your "super linear" performance 12:29 < bridge> should I be using multiple tees in the same gameworlds to get more ticks/s? 12:29 < bridge> lol 12:29 < bridge> lmao 12:30 < bridge> i guess it's fair to say that with few tees, other factors like player ticks etc. also have a small impact 12:30 < bridge> If your previous benchmark was real it would be 3.5 million tee ticks/s lol 12:31 < bridge> I think we can pump those numbers up 12:31 < bridge> With multi threading yes 12:31 < bridge> TPS: tees per second 12:33 < bridge> Multi threaded collision is a thing as well if we want 10,000s of tees 12:34 < bridge> The reason is that the ROI is low on doing it properly. 64p works just fine. 128p also works pretty acceptably which is our next stop. 12:34 < bridge> 12:34 < bridge> So migrating to a full spatial hashing or quadtree solution would just be a marginal performance improvement on the server side 12:34 < bridge> water simulation _tee edition_ 12:34 < bridge> YES 12:35 < bridge> You can't really do this well deterministically, the only option seems to be maintaining islands of tees that you simulate separately, but you need to be careful with moving tees between them as it will require locking and blocking if not done properly 12:35 < bridge> it might really already be needed now. 12:35 < bridge> 12:35 < bridge> if someone has prediction_margin of like 200 and zooms out, good bye xd 12:35 < bridge> What would happen if you pumped high pressure tee into the spawn point of Multeasymap? Would some of it eventually finish? 12:36 < bridge> Yeah the client running the physics aswell is a bit of an issue. I can only advise them to not do that 😄 12:36 < bridge> this is a funny experiment ngl xd 12:36 < bridge> Its a good model tho. The client should run physics as many AAA games do 12:37 < bridge> If anyone wants to do it properly it'll definitely be accepted as a PR. The hardest part is reviewing it since we don't currently have the capability of replaying teehistorian files to check nothing broke 12:37 < bridge> I think the client could potentially cull tees that are fad away for prediction if it becomes an issue 12:37 < bridge> I meant as in not set prediction margin so high then zoom all the way out 12:37 < bridge> I think the client could potentially cull tees that are far away for prediction if it becomes an issue 12:38 < bridge> Running the physics on the client aswell is sane and the correct(tm) thing to do 12:38 < bridge> Now the real question: 12:38 < bridge> How high should the flow rate be for the pumped tee fluid to achieve a finish faster than a 63 player server of average Multeasy players? 12:38 < bridge> Now that is one demo I would love to see 12:38 < bridge> Prediction margin is capped at 300 now so the real issue is the 4000ms ping cap 12:39 < bridge> Keep pumping tees at the start. See how fast you need to spawn tees to get an average finish 12:40 < bridge> i found a new elevator. 12:40 < bridge> 12:40 < bridge> The tee popping one 12:40 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1316731391769182228/tee_elevator.mp4?ex=675c1d2b&is=675acbab&hm=64383358aeee1580048e79c6178fa7d30df04c4979f3cc6ae67edee049cbb6ed& 12:40 < bridge> I'm not sure any number is faster with current physics, the tees don't push each other than fast 12:41 < bridge> ok now make each tee in the fluid hammer in a random direction once every 10 seconds 12:41 < bridge> oh wait the mazes would immediately stop the fluid on multeasy 12:42 < bridge> Would be better on aip gores 12:42 < bridge> yeahhh 12:42 < bridge> needs to be a simple map without no collision or large areas of tele backwards 12:43 < bridge> though tele backwards with ever increasing tee pressure could be funny to see 12:45 < bridge> morning 12:52 < bridge> hai 13:02 < bridge> gm 13:17 < ws-client>