05:47 < bridge> did someone say... option? 05:57 < bridge> I don't see anyone 06:07 < bridge> quick heinrich’s asleep add more options 09:51 < bridge> @jupeyy_keks can you roughly explain how `RenderTileLayer` works? I guess pIndicesOffset are the tile IDs? So If I want to add something like a float to the tile IDs I need my own new struct and then create my own shaders 09:51 < bridge> oh and gumo everyone ^.^ 09:52 < bridge> no that can't be, because the pIndicesOffset is an uint_32 and not uint8 09:52 < bridge> It's the offsets to the index buffers ig 09:53 < bridge> Why do you want to add a field? For ddnet? 09:53 < bridge> I prefer we don't use more VRAM 09:54 < bridge> I want to experiment with colored speedtiles, could be an optional feature, all I need is a uint8 for the speed value and let the gpu color it 09:55 < bridge> so yes, would be more vram, even if not much 09:55 < bridge> the min alignment is 16bit afaik 09:55 < bridge> guess I could add the max_speed then too :/ 09:57 < bridge> So you only want it for speedlayers? 09:58 < bridge> yes, just submit the Hue and color by it 09:59 < bridge> yes, just submit the Hue and color by it (where Hue and speed are equal) 10:00 < bridge> I guess I'd need to add a version of SUniformTileGPos, however I don't get why it's a float[8] 10:00 < bridge> oh now I get it, x/y for each corner 🙈 10:06 < bridge> omg you could also group it again ... 10:12 < bridge> ~~I guess I'd need to add a version of SUniformTileGPos, however I don't get why it's a float[8]~~ 10:20 < bridge> group what? 10:23 < bridge> don't worry about it :justatest: 10:23 < bridge> don't worry about it :justatest: (group speedtiles by strength and then just push constants) 10:24 < bridge> don't worry about it :justatest: (group speedtiles by strength and then just push constants, no I am not going to implement that) 10:25 < bridge> don't worry about it :justatest: (group speedtiles by strength and then just push constants, no I am not going to implement that, but maybe I should because I could set color like an env color without using any extra shader code) 10:30 < ws-client> @learath2 could you merge https://github.com/ddnet/ddnet/pull/10350 for me? UwU 10:31 < ws-client> somehow it slipped through deen the machine 10:34 < ws-client> @Jupstar ✪ in https://github.com/ddnet/ddnet/pull/10363 you encoded a link as code? Makes it unclickable ._. is that to avoid pinging the issue? If so may i suggest to use the www. prefix hack ;) 10:34 < ws-client> example here https://github.com/ChillerDragon/github-meta/issues/6#issuecomment-2975586041 if you slap www. in front of github.com it works and redirects but it does not ping 10:36 < ws-client> but tbh you should just full ping them! Its good exposure for ddnet. We need the marketing. 10:37 < bridge> chiller: oh good to know 10:37 < bridge> that's handy 10:37 < ws-client> full time githubber u know 10:37 < bridge> I only ping ddnet repo on stuff where it's not our fault 10:37 < bridge> :deen_star: 10:38 < bridge> gotta have good marketing campaign 10:38 < ws-client> ok giga chad developer 10:38 < ws-client> but is it our fault even? 10:39 < bridge> Yes 10:39 < bridge> It's a new validation error added that exposed a bug in almost every vulkan app 10:39 < ws-client> i could imagine others browsing that issue could appreciate the pings with example projects fixing the same issue 10:39 < bridge> Even huge players like source engine and godot 10:39 < bridge> I asked the vulkan tutorial to adopt our solution 10:40 < bridge> Bcs I think it's the most clear fix xd 10:40 < ws-client> then you should do a proud ping 10:40 < bridge> I used fake acc sry 10:40 < ws-client> i dont think the our fault argument works here if everyone made the same mistake 10:41 < bridge> I'd say it still is.. I could have understod the problem in theory 10:41 < bridge> It's one of these bugs, when you see it, it's so fcking obvious 10:41 < ws-client> ofc 10:41 < ws-client> you are not as noob as fakin source engine devs 10:41 < ws-client> cring to do same mistakes like they do 10:42 < ws-client> jupstar einfach deutsche chuck norris 10:42 < bridge> I mean, I don't even know how much effect that error has in practice tbh. 10:42 < bridge> 10:42 < bridge> In vulkan semaphores don't just call `signal` they first go into a _signal state_. 10:42 < bridge> 10:42 < bridge> (Bcs the actual signal happens on the GPU not CPU) 10:42 < ws-client> jupstar doesn't need vulkan tutorial 10:43 < bridge> And that is basically the bug here.. the vk-tutorial ignored that signal state 10:43 < ws-client> vulkan tutorial needs jupstar 10:43 < bridge> Yes, I should write a new vulkan-tutorial 10:43 < bridge> I have infinite time anyway 10:43 < ws-client> wowo 10:43 < ws-client> since when 10:44 < bridge> Since never 10:44 < bridge> Paradox 10:44 < ws-client> ah it was irony? 10:44 < bridge> Yes 10:44 < ws-client> i did not get that xd 10:44 < ws-client> its not like you are fred 10:44 < bridge> Ah you thought I have infinite time 10:44 < bridge> alr 10:44 < ws-client> yes 10:46 < bridge> I am not on that spiritual state yet 10:46 < ws-client> do you meditate? 10:47 < bridge> No, but I shower with hot water 10:47 < ws-client> thats not a thing 10:47 < ws-client> maybe cold water? 10:47 < bridge> I swear everytime I shower I am most creative 10:47 < ws-client> you need meditation or drugs to unlock spiritual perks. And I doubt you do drugs. 10:48 < ws-client> i know that cuz im basically guru 10:48 < bridge> @jupeyy_keks if I'd create 255 CTileLayerVisuals, would that be bad for performance? 🙈 10:48 < ws-client> i am close to infinite time 10:48 < bridge> I guess xd 10:48 < ws-client> wait 3rd way 10:48 < ws-client> is to buy my book on unlocking the spiritual path! 10:49 < bridge> Yeah no, I am not really spiritual sry to destroy your dreams 10:49 < bridge> Meditation can probably help to relax, but I don't think it connects you to cosmic energy 10:49 < ws-client> being releaxed is basically cosmic energy 10:50 < ws-client> it makes you invincible 10:50 < bridge> Or buy this goofball's book to have more time! https://youtube.com/shorts/PJIRexfVkYE?si=JNd1fj0SOGIF9Gxk 10:50 < bridge> I think being in sun, literally connects you more to cosmic energy 10:50 < bridge> 😂 10:50 < ws-client> thats why doctors just say 99% "oh your symptoms are caused by stress" 10:50 < ws-client> if you chill you can't get sick 10:51 < ws-client> sun is deadly lazers 10:51 < ws-client> it kills you 10:51 < bridge> Yeah, the cure to cancer is meditation right? 10:51 < ws-client> i guess the hack to not get cancer in the first place is meditation 10:51 < bridge> Ah 10:52 < bridge> And if you still get cancer, you simply didn't meditate enough 10:52 < ws-client> yes 10:52 < bridge> If you'd have starved by meditation you'd have not gotten cancer 10:52 < ws-client> you can't starve if you mediate correctly 10:52 < ws-client> energy will come from within 10:53 < bridge> I me**tee**tate sometimes 10:53 < ws-client> tate 10:53 < bridge> Ah right, the ppl that eat sun energy 10:53 < ws-client> yes through their butthole 10:54 < ws-client> you know the guy that swears on sunning the butthole? 10:54 < ws-client> oh shit we left #developer on topic 10:54 < bridge> That is so on topic 10:55 < ws-client> enuff trolling for today 10:55 < ws-client> good chat as always josspit 11:08 < bridge> @blaiszephyr i have to use nix against my will at work 11:08 < bridge> do u know how to get this to be available 11:08 < bridge> ``` 11:08 < bridge> thread 'main' panicked at /build/cargo-vendor-dir/bindgen-0.70.1/lib.rs:622:27: 11:08 < bridge> > Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-*.so', 'libclang.so.*', 'libclang-*.so.*'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])" 11:08 < bridge> ``` 11:28 < bridge> ok i fixed it 11:29 < bridge> pkgs.rustPlatform.bindgenHook 11:56 < bridge> You use nix in prod? 11:57 < bridge> Is your boss mental 11:57 < bridge> :justatest: 12:07 < bridge> boss loves nix reproducibility 12:07 < bridge> but im not using nixos 12:07 < bridge> the nix pkg thing 12:08 < bridge> btw boss also bet on rust in 2015 12:08 < bridge> i think he is a visionary 12:11 < bridge> yeah I know, nix is the pkg manager 12:11 < bridge> 12:11 < bridge> I mean nix is great, but it can be annoying as hell to work with, especially if you use nix for one thing and your usual environment for the other 12:11 < bridge> 12:11 < bridge> Most programs are used to /usr/bin 12:11 < bridge> Nix uses /nix/store with versioning for each existing link in there, which can be hell to work with 12:12 < bridge> Espacially if you use things like pkg_config, which requires patches to work with it sometimes (for example my ddnet pr for findmysql.cmake) 12:12 < bridge> ¯\_(ツ)_/¯ 12:13 < bridge> But hey, if it works it works :justatest: 12:13 < bridge> tbh nixos for servers looks like it has uses 12:13 < bridge> if im not wrong u just save the config 12:13 < bridge> and can reproduce the sv 12:14 < bridge> xd 12:14 < bridge> You push up your /etc/nixos folder 12:14 < bridge> Dynamically generate a hardware config 12:14 < bridge> 12:14 < bridge> And reproduce one server a million times :nouis: 12:15 < bridge> Or even entire environments 12:15 < bridge> @scrumplex managed to force your workplace to switch to nixos yet? :mlem: 12:46 < bridge> @kebscs Are you generally interested in #237? Since you were interested in prediction. 12:46 < bridge> https://github.com/ddnet/ddnet/issues/237 12:47 < bridge> The seeded tele pr was fine, idk why it was closed 12:47 < bridge> This #6775? 12:47 < bridge> https://github.com/ddnet/ddnet/pull/6775 12:48 < bridge> Yea 12:49 < bridge> I think it was missing some stuff when I checked it, but the idea is good 12:55 < bridge> Nope :(( 12:55 < bridge> :( 12:56 < bridge> But we are gonna use NixOS to spin up VMs for a CTF we are gonna host :3 12:56 < bridge> :poggers2: 13:20 < bridge> I was mostly unhappy with the seeding method, gametick was fine but the entity IDs for projectiles didn't seem to be set consistency on the client and I never finished figuring out why. 13:21 < bridge> So it was not a random seed? 13:21 < bridge> wdym? 13:21 < bridge> The seed was predictable 13:21 < bridge> tick + entity id 13:22 < bridge> yes 13:22 < bridge> Alr 13:22 < bridge> how would you do it? 13:22 < bridge> what about generating a random seed and sending a netmsg with it on join? 13:22 < bridge> The client doesn't know all teleports that happen on a single tick so just sending the rng value wont work imo 13:22 < bridge> I'd generate a random seed for every entity and put it into the snapshots 13:22 < bridge> That way even on packet loss it's always available 13:23 < bridge> If it's per entity it should be fine 13:23 < bridge> Doesn't that massively increase snap diffs? 13:23 < bridge> I dunno, how huge do you want the seed to be? 😄 13:24 < bridge> oh are you saying the seed only changes when it teleports? 13:24 < bridge> otherwise you need to send every seed every tick 13:24 < bridge> you don't need to reset a seed for a prng? 13:24 < bridge> Ah well I'd probs still use like the current tick additionally 13:24 < bridge> Just the random seed as base 13:24 < bridge> Wait 13:24 < bridge> ah 13:24 < bridge> Hmm 13:25 < bridge> Well that's basically the same as hash(entity_id) 13:25 < bridge> Isn't it? 13:25 < bridge> just more secure 13:25 < bridge> Yeah ig so 13:25 < bridge> do we need seeds to be secure? Ig knowing the exact sequence of where teleports will take you would make bot clients a hair stronger but like 13:26 < bridge> does it really matter? 13:26 < bridge> I dunno what the exact problem of your PR was, but if the RNG was reset with a new seed, your idea should actually work 13:26 < bridge> The idea is fine I just didn't want to finish the implementation 13:26 < bridge> Well we had a vote in the issue above 13:26 < bridge> the only people who get an advantage are tassers, but they wont be able to do it on live servers since the tick is kinda random when they join 13:26 < bridge> Most maintainers wanted random seed to prevent replay bots 13:26 < bridge> even if they vote change map 13:27 < bridge> oh yeah, random for sure 13:27 < bridge> you can also seed it with a crypo random 13:27 < bridge> and your lazy ass tells me to write 500loc interface 😭 13:27 < bridge> a smart replay bot doesnt care about teleport result 13:27 < bridge> Smart bots also work with how tele works now 13:27 < bridge> They are probs not of question 13:27 < bridge> yes 13:27 < bridge> Yeah but youre code doesn't have to wait 1-6 months to get merged by a maintainer 13:27 < bridge> so why dont we just switch to seeded random now, surely its a tiny change 13:28 < bridge> true 13:28 < bridge> How random? 13:28 < bridge> Once per load or all the time random? 13:28 < bridge> an unknown initial seed psuedo random is indistinguishable from true random 13:29 < bridge> unless the psuedo random is flawed 13:29 < bridge> random seed on tee spawn, current seed gets sent to clients when tee enters render distance 13:29 < bridge> use like a pcg because fast and gud 13:29 < bridge> It should somehow involve a secure seed. 13:29 < bridge> 13:29 < bridge> E.g. the server could store a global cryptographically random seed, and then generate seeds based on that 13:29 < bridge> Would probably random enough 13:29 < bridge> What 13:29 < bridge> That sounds overkill 13:29 < bridge> rand() is good enough lol 13:29 < bridge> if you want security you can just read /dev/random 13:30 < bridge> (ugh Windows exists why) 13:30 < bridge> srand(NULL) rand() 13:30 < bridge> That is a cryptographically random value 13:30 < bridge> go brr 13:30 < bridge> the server time is not known to second precision 13:31 < bridge> I don't get why this seed needs to be so secure at all 13:31 < bridge> i guess you could brute force it 13:31 < bridge> you send it to the client anyways for prediction 13:31 < bridge> I mean how predictable should the randomness be. The client by definition needs to be able to predict the result, the question is how far in the future is it allowed to predict 13:31 < bridge> or do we pretent that TASes, which just wait for the seed to align, don't exist? 13:31 < bridge> a smart play bot doesnt care if it can predict everything or nothing, a good enough random will have even cahnces of every result, so tas's would have to be smart 13:31 < bridge> if you want to not go crazy brute force you can read once from /dev/random on server start and then xor that with current time and use that as your starting seed 13:31 < bridge> If it's per entity, then for as long as it lives I guess 13:32 < bridge> It is kinda known to tick precision if changing map generates a new seed xd 13:32 < bridge> But you can also use 2 seeds and always reseed one and swap them 13:32 < bridge> is tele pred already implemented? 13:32 < bridge> Just not too often 13:32 < bridge> less than once every 5 seconds ig 13:32 < bridge> What about hook entity, the client will spawn it. And it goes through a teleporter before the server has time to tell the client what seed it should use 13:33 < bridge> We can use the owner seed for example 13:33 < bridge> The hook isn't an entity. The player is 13:33 < bridge> ok 13:33 < bridge> But anyway, I also didn't want to create a whole concept 13:33 < bridge> so you want to add random reseeds every few seconds 13:34 < bridge> We need someone that is willing to implement this 13:34 < bridge> I can guarantee you that no matter how much we discuss some reviewer will find smth unhappy about 13:34 < bridge> Can we define the minimum viable implementation, This conversation added more questions 13:34 < bridge> Create a whole concept, put it into the issue. 13:34 < bridge> 13:34 < bridge> That would be really nice if someone is motivated 13:35 < bridge> Random reseed every few seconds seems overkill, like what are you securing against 13:35 < bridge> Ig you can then prevent tases on a single server 13:35 < bridge> Also changing the seed is cheap 13:35 < bridge> I think a somewhat secure initial seed would be good enough 13:36 < bridge> I personally would probs fill smth like rand() with a secure seed 13:36 < bridge> 13:36 < bridge> And then use rand() to generate seeds for the entities 13:36 < bridge> was this a public discussion on github? 13:36 < bridge> I think as a minimal viable product, this would actually be good enough for a start 13:36 < bridge> can you link if so 13:36 < bridge> it feels like bloat to me 13:36 < bridge> #237 13:36 < bridge> https://github.com/ddnet/ddnet/issues/237 13:36 < bridge> ^ 13:37 < bridge> Well what does bloat mean, it's probs pendetic 13:37 < bridge> in this case I'm more complaining about the extra code than about the runtime cost 13:38 < bridge> what runtime cost? 13:38 < bridge> yeah exactly 13:38 < bridge> ;D 13:38 < bridge> :D 13:38 < bridge> What extra code 13:38 < bridge> xDD 13:38 < bridge> I mean yeah dunno 13:38 < bridge> I was not even my idea xD 13:39 < bridge> Heinrich said he doesn't like any of the ideas :apafrog: 13:39 < bridge> He had two weeks to answer 13:39 < bridge> he did lose the vote ig 13:39 < bridge> What *does* Heinrich like? 13:40 < bridge> He was actually neutral 13:40 < bridge> He probably is not satisfied that I didn't add a whole concept 13:41 < bridge> But I feel like a developer that is interested should just think as good as he can about what problems can arrise 13:41 < bridge> idk is there anything low effort that would make it harder for replays bots? (other than refreshing the seed periodically) 13:41 < bridge> Minimal viable product: 13:41 < bridge> - Add netmessage for random teleporter seed 13:41 < bridge> - should contain future (server) time when the seed is switched, there would be no gain if this would be used immediately due to ping 13:41 < bridge> - Send player a start seed only for teleporters 13:42 < bridge> - Do seed based prediction (client side) 13:42 < bridge> - Do seed based teleports (server side) 13:42 < bridge> 13:42 < bridge> Am I missing something? 13:42 < bridge> for me any solution works 13:43 < bridge> idk how anyone thinks botters wont guess the seed when it has to be sent to the client 13:43 < bridge> I thought its going in snapshot as entity field 13:43 < bridge> I think we should implement a solution that works. preferably minimal code changes. 13:43 < bridge> 13:43 < bridge> And if we are not happy in future change it again 13:44 < bridge> > I think we should implement a solution that works. preferably minimal code changes. 13:44 < bridge> i agree, 13:44 < bridge> 13:44 < bridge> > And if we are not happy in future change it again 13:44 < bridge> Careful with this, ddnet is anti change and pro back compat 13:44 < bridge> But the worst that can happen is that prediction breaks in older clients 13:44 < bridge> Botters will guess the seed. The hope is that the bots are just too stupid to compensate 13:44 < bridge> But yeah you are right 13:45 < bridge> they arent stupid tho, and its affecting all players 13:45 < bridge> I can tell you that they wont compensate in realtime but they will probably spam kill until they get a seed where all teleports work. 13:45 < bridge> What is the issue here again? I thought a prng with a random seed is just good enough. What other option is tempting you guys? 13:46 < bridge> with my proposal it doesn't matter where the server gets it seeds from, you can do it with `rand()` or by watching a lava lamp 13:46 < bridge> Not a lot actually. 13:46 < bridge> It's only about randomness vs non randomness mostly xd 13:46 < bridge> Tater already had a non random solution that could maybe work, dunno what the exact issue was 13:47 < bridge> Just don't roll the seed on kill. Make it per server session? 13:47 < bridge> And then we added a random seed instead of entity_id to the entities 13:47 < bridge> oh right, this depends on how many bits of randomness are in the teleports involved in the run, as opposed to bits of randomness in the seed 13:47 < bridge> Maybe this is better 13:47 < bridge> I said keep the randomness so on the surface it just appears as if nothing changed to the normal player 13:48 < bridge> Maybe this is better, I was thinking if you do that then they can make a new TAS after joining the sever but that's already possible anyway with kill seed 13:48 < bridge> But not if the seed changes every few seconds 13:48 < bridge> yes ofc 13:49 < bridge> The nuclear option 13:50 < bridge> Eh, do we really want to go that far? So much traffic generated for blocking a few bots that aren't even real yet 13:50 < bridge> Im feeling no, personally 13:51 < bridge> but also I don't think its much traffic. Im more concerned with annoying implementation and resulting back compat 13:51 < bridge> bots should be fought with a different solution like accounts, you arent stopping them with overengineered teleport seed 13:51 < bridge> If you want to be extra annoying maybe xor the real seed by the current second of the day rounded down to 10s. Then the bot has to find a server with a seed that perfectly lines up with no easy way to reroll the seed 13:51 < bridge> yeah a seed is a few bytes, so this would generate maybe less than a byte per second on average 13:51 < bridge> This is actually true, do most maps even contain multiple destinations or teleports at all? 13:52 < bridge> yeah a seed is a few bytes, so this would generate maybe less than a byte per second of traffic on average 13:52 < bridge> Rare, especially on maps where this sort of deterrant would work, on maps where you are getting tpd to safe ground, resynchronizing your bot is trivial anyway 13:52 < bridge> I think this is worse than just sending the seed periodically 13:53 < bridge> don't use /dev/random, it's a blocking read if entropy is too low. 13:53 < bridge> Prefer /dev/urandom 13:53 < bridge> It is as it technically is possible to find a seed and time of day/year that lines up perfectly 13:53 < bridge> nooo but we need security (also with modern kernels it's not blocking anymore) 13:54 < bridge> But in exchange it doesn't require any bandwidth 13:54 < bridge> The main "issue" is to get perfect prediction you need to inform the client ahead of time by ~2-4 seconds that the seed will change and exactly which gametick. Or you get mispred. But tbh for teleport this is a small mispred anyway 13:54 < bridge> Let's add a HWRNG as a system requirement for ddnet servers 13:54 < bridge> We need at least 10MB/s of entropy 13:55 < bridge> Anyway, I'd probably just use a single seed per server restart and call it a day 13:56 < bridge> I'm currently reading over 400MiB/s from my /dev/random 13:57 < bridge> `pv < /dev/random > /dev/null` 14:00 < bridge> i think we should avoid the WHOLE seed mechanism for 1 way teleporters 14:01 < bridge> teles with 1 out* 14:01 < bridge> Are teles with 1 out handled in a special way already? 14:01 < bridge> I don't think avoiding advancing the prng by one even when it's useless makes sense 14:01 < bridge> i would bet 70% of teles are 1 out 14:02 < bridge> don't you get much less entropy on the server? as you don't have any free entropy source like mouse movements and stuff? 14:02 < bridge> or smth like that 14:02 < bridge> most teles are part teles for fails 14:02 < bridge> or to go next zone 14:02 < bridge> the prng is basically free to run, it's like a dozen instructions 14:02 < bridge> but if we need to send seed 14:02 < bridge> its network traffic 14:02 < bridge> we can avoid 14:02 < bridge> why not? 14:02 < bridge> i think it shouldnt be too hard of a if case 14:03 < bridge> That alone won't work tho 14:03 < bridge> good maps will have like two or three outs for fail teles 14:03 < bridge> The client does not know about all teleports that happen in an instant 14:03 < bridge> The randomizer has to be reset every tick for every entity 14:03 < bridge> as in system clock 14:03 < bridge> But we don't? The way a PRNG works is that getting a number out of it updates the seed 14:03 < bridge> (or initialized as soon as the teleport happens) 14:04 < bridge> @teero777 14:04 < bridge> one seed at the start gets you the whole random sequence 14:04 < bridge> i guess depends on how we go about it ur right 14:05 < bridge> tick + entity_id + random seed 14:05 < bridge> 14:05 < bridge> would probs work 14:05 < bridge> does one client need to know the seed of another client for prediction? I would have thought that the own seed would have been enough 14:05 < bridge> If we really want a server global seed 14:05 < bridge> yeah you'd need to know the seeds of every tee 14:06 < bridge> so you do need to handle sending seeds whenever a tee enters your render distance or however the logic for sending tees works 14:07 < bridge> That can be reseeded every few seconds too ofc if we want to switch to nuclear bomb xdddd 14:07 < bridge> we also need to sync where we are on the random seed sequence, I can imagine scenarios where this desyncs :justatest: 14:07 < bridge> I'd not use a sequence 14:07 < bridge> global seed and base it on tick instead of increment every teleport? 14:07 < bridge> Reset every tick for every entity 14:07 < bridge> aka init just in time 14:08 < bridge> and then you misspredict and hit the teleport 1 tick later or earlier and prediction is rip? 14:08 < bridge> If that is what taters solution did 14:08 < bridge> We even have a impl already 14:08 < bridge> yeah adding the tick number to a static seed would be a bit more robust than having the client and server both independently count the number of teleports a tee has gone through 14:08 < bridge> Why not just use the seed as an initial seed and keep a prng for each entity? 14:08 < bridge> For sure 14:08 < bridge> ^ this is also what I thought 14:09 < bridge> Fine too, but snaps are only send every second tick 14:09 < bridge> It's britle 14:09 < bridge> you need to keep track of of alternate realities with mispredictions and allat 14:10 < bridge> You know what that doesn't work too well for other entities anyway. We clip entities out 14:10 < bridge> easier to just *not* 14:10 < bridge> initially I thought keeping a prng for each tee would be easier but I was convinced otherwise :) 14:10 < bridge> Ok so we want something memoryless 14:11 < bridge> hash(random per-tee seed + tick) seems like the way imo 14:11 < bridge> Tick is too brittle no? You'd want tick rounded down to 50s 14:11 < bridge> At least 14:12 < bridge> I would have thought to use the prng only for the teleporter prediction, so for each teleport use one prng value, I don't see why this would be too brittle 14:12 < bridge> Actually yeah rounding the tick value slightly would help make mispredicts slightly less noticeable 14:12 < bridge> Sounds generally fine, but if you want it to be as random as our current teleporters then you'd need to do it 14:12 < bridge> If the client does not observe a teleport, how does it sync back up? 14:13 < bridge>