01:55 <+bridge_> <totar> LLM says this isn't bulletproof because TEE still needs to ask the OS for hardware IDs which a user could control and spoof, very easily even if you're relying only on TEE code and doing scanning at a driver level to check for things that could be spoofing hardware IDs.
01:56 <+bridge_> <totar> LLM says this isn't bulletproof because TEE still needs to ask the OS for hardware IDs which a user could control and spoof, very easily even if you're relying only on TEE code and not doing scanning at a driver level to check for things that could be spoofing hardware IDs.
01:57 <+bridge_> <totar> you also can't just use the "ID" of the TEE itself because intel intentionally rolls the ID to prevent you from doing this for privacy reasons
02:10 <+bridge_> <totar> you can however get a TPM ID and ban with that if you did secure boot
02:14 <+bridge_> <totar> hmm you could be very annoying about how you get the CPU ID and that might also be quite good, but I assume TPM modules must exist for a reason
02:22 <+bridge_> <avolicious> Which hardware id?
02:22 <+bridge_> <avolicious> TEE doesnt load any hardware ids by default
02:23 <+bridge_> <avolicious> TEE is just a big ecosystem where you have Secure Enclave, TPM and other modules on the CPU that are standardized by a vendor like Intel or AMD
02:43 <+bridge_> <_qey> So, our beloved maintainers, when do I expect you to roll out any client identifier other than IP?
02:43 <+bridge_> <louis> Oh no
02:46 <+bridge_> <_qey> Sounds like never. :feelsbadman:
02:46 <+bridge_> <avolicious> Its not easy to maintain
02:48 <+bridge_> <_qey> Heuristics it is then.
02:49 <+bridge_> <louis> wait for accounts™
02:49 <+bridge_> <_qey> Sounds fun, but it would be hell in developing such a system for me.
02:49 <+bridge_> <_qey> Mandatory?
02:49 <+bridge_> <louis> u could require them for your server
02:50 <+bridge_> <_qey> ETA for accounts rollout?
02:50 <+bridge_> <louis> ♾️
02:50 <+bridge_> <_qey> I’ve seen talks about it about a year ago.
02:50 <+bridge_> <_qey> I wonder if it’s been anything but talks since then?
02:51 <+bridge_> <louis> u could implement some scruffy login system urself then link them later on if a better implementation ever comes along
02:52 <+bridge_> <avolicious> Hey hey, our login system is not scruffy
02:52 <+bridge_> <_qey> I’m already on it. I will be linking Telegram Bots / Discord for management, but it still requires an in-game login system along with it. The main hurdle isn’t me developing it, it’s making people use it.
02:54 <+bridge_> <_qey> People on DDNet can barely read chat announcements. I somehow need to not hurt new players, while keeping it easy to explain how and why they should use the login system.
02:54 <+bridge_> <_qey> The client itself is limited in ways to communicate with the said player.
02:57 <+bridge_> <_qey> At least give us an option to make MOTD a real window skippable with an OK button, not just some overlay.
02:57 <+bridge_> <avolicious> This works 😄
02:58 <+bridge_> <avolicious> But its very pain
02:58 <+bridge_> <avolicious> Fokkonaut implemented it years ago in f-ddrace
02:58 <+bridge_> <_qey> A client-side window implemented server-side?
02:58 <+bridge_> <avolicious> Yes
02:58 <+bridge_> <avolicious> MOTD use
02:59 <+bridge_> <_qey> Huh.
02:59 <+bridge_> <louis> Uhh theres an active issue
03:00 <+bridge_> <louis> I agree with this, there should be like some better formatted ui popup
03:01 <+bridge_> <louis> with player allowed to input text and buttons and whatnot, that would be cool
03:01 <+bridge_> <_qey> That alone may serve as a login system, exactly.
03:01 <+bridge_> <avolicious> Please dont
03:02 <+bridge_> <louis> go pr it
03:02 <+bridge_> <avolicious> sending username and password over cleartext
03:02 <+bridge_> <_qey> I’m not coming close to client within a touching distance.
03:02 <+bridge_> <louis> Not like almost every login system on tw does this
03:02 <+bridge_> <avolicious> Nope
03:03 <+bridge_> <avolicious> We are using auth tokens
03:03 <+bridge_> <louis> ye i know kog system is nicer
03:03 <+bridge_> <_qey> I’ve actually thought of just revamping auth system as a login, but then how do we register?
03:04 <+bridge_> <_qey> OOOHHH!
03:05 <+bridge_> <_qey> What if I generate a password upon player join and just give it to them? Lmao. Session-driven gameplay becomes possible. Each session is linked to a password. Though, brute-forceable and comes with several other caveats.
03:06 <+bridge_> <louis> u should probably do that if youre linking to discord or telegram
03:07 <+bridge_> <louis> well im not sure what u mean. I'd just have a discord bot generate a code, similar to email code logins on other games
03:08 <+bridge_> <_qey> No, not exactly. A player joins. A password is generated for that exact session. Everything that is happening is linked to this password. You can retrieve it by typing /password and it shows your password. You can then use it elsewhere.
03:09 <+bridge_> <_qey> No registration needed. Session is restored via revamped F2 auth.
03:10 <+bridge_> <_qey> It’s not in any way ideal, but it does work.
03:11 <+bridge_> <avolicious> Reworking F2 auth? Wow
03:11 <+bridge_> <avolicious> Thats a lot of work 😄
03:12 <+bridge_> <_qey> That would be my problem. Though mobile clients don’t have access to F2 AFAIK.
03:14 <+bridge_> <_qey> Then /login password, still skips registration step. But then, it would be easier to just make /register. I know I’m complicating things, but it’s all related.
03:15 <+bridge_> <_qey> Or are you saying to fully move registration to Telegram / Discord and only implement logins in game?
03:16 <+bridge_> <_qey> That actually works, too. And in a better way of enhanced engagement.
03:18 <+bridge_> <_qey> Can we do clickable links client-side? Only server-pushed ones.
03:42 <+bridge_> <_qey> Oh, I see. Most people just use F-DDrace it seems for their “custom” servers.
03:46 <+bridge_> <_qey> KoG servers show version 0.6/0.7, and mine (fork of DDNet-Server) only shows 0.6.4. Does that mean vanilla Teeworlds can’t join my servers?
03:49 <+bridge_> <_qey> Yep. Just checked. Should I be worried about 0.7 support? Given that Teeworlds is effectively dead?
04:13 <+bridge_> <totar> have you checked the availability of TEE on consumer cpus? it seems dead
04:14 <+bridge_> <totar> you can get TPM 2.0 with secureboot but TEE is a server thing now it seems
04:14 <+bridge_> <totar> you can get TPM 2.0 with secureboot but TEE is a server cpu thing now it seems
04:15 <+bridge_> <totar> you can get attested application specific HWID with it though
04:15 <+bridge_> <totar> you can get attested application specific HWID with it though, but it's not useful if you can't even access TEE
06:56 <+bridge_> <gorp_tw> really stumped with how GER works
06:57 <+bridge_> <gorp_tw> excerpt from curly's code:
06:57 <+bridge_> <gorp_tw> `out.payload = minitw.packint(1) .. nameToUuid["clientver@ddnet.tw"] .. table.concat(uuid) .. minitw.packint(19060) .. minitw.packstr("bot")`
06:58 <+bridge_> <gorp_tw> for DDNet 19.6 (we don't really want to fake the client number) it responds perfectly fine on GER
06:58 <+bridge_> <gorp_tw> but for some reason, GER doesn't respond to the bot, even after sending this
06:58 <+bridge_> <gorp_tw> so what's going on? how does GER differ from other servers?
06:59 <+bridge_> <gorp_tw> idk who to @ even for this
07:01 <+bridge_> <gorp_tw> ofc, we also send `minitw.packint(netIds.SYSTEM_INFO) .. minitw.packstr("0.6 626fce9a778df4d4") .. minitw.packstr("")` like normal
07:05 <+bridge_> <gorp_tw> we're pretty sure the specific UUID used doesn't matter, since Swarfey's lib always sends a random one
07:06 <+bridge_> <gorp_tw> i guess i shouldnt be surprised that it is hard to make non-player connections to GER
07:06 <+bridge_> <gorp_tw> xd
07:37 <+bridge_> <louis> thought u have to make https request to ger10.ddnet.org
07:37 <+bridge_> <louis> Ask davide
08:38 <+bridge_> <gorp_tw> this one? davide55?
08:47 <+bridge_> <teero777> i just went down the rabbit hole of hidpi on linux. it is so annoying xD
08:47 <+bridge_> <teero777> why must software be this bad
08:48 <+bridge_> <gorp_tw> requires wayland  right
08:48 <+bridge_> <melon> If you understand rust, you could see how jupstar managey legacy connections to ddnet ger in ddnet-rs
08:49 <+bridge_> <teero777> wayland does do it better
09:21 <+bridge_> <avolicious> Yes, all available on modern cpus but not toasters sadly
09:23 <+bridge_> <totar> Where do you see that? Index deprecated SDX and the replacement isnt available on consumer cpus afaict
09:23 <+bridge_> <totar> Where do you see that? Intel deprecated SDX and the replacement isnt available on consumer cpus afaict
09:23 <+bridge_> <totar> Where do you see that? Intel deprecated SGX and the replacement isnt available on consumer cpus afaict
09:28 <+bridge_> <totar> Its only widely available on mobile phones from what I see
09:55 <+bridge_> <louis> Would it be feasible to implement a game-layer-only hookthrough and update all current maps that use new hookthrough?
10:24 <+bridge_> <avolicious> https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html
10:24 <+bridge_> <totar> This is for servers?
10:25 <+bridge_> <avolicious> It is, but there is also one for consumer cpus
10:25 <+bridge_> <avolicious> One sec
10:55 <+bridge_> <avolicious> They are now selling: Intel vPro Business Client platforms (https://www.intel.com/content/dam/www/central-libraries/us/en/documents/white-paper-intel-tme.pdf)
11:21 <+bridge_> <totar> I think you need "vPro buissness laptops"
11:23 <+bridge_> <totar> https://en.wikipedia.org/wiki/Intel_vPro#vPro_hardware_requirements
11:23 <+bridge_> <totar> <https://en.wikipedia.org/wiki/Intel_vPro#vPro_hardware_requirements>
11:26 <+bridge_> <totar> I think it is more practical to go the TMP2.0+SecureBoot driver route than this
11:26 <+bridge_> <totar> which isn't that practical
11:48 <+bridge_> <learath2> I’d say it’s borderline worse even. The TEE interacts with the outside world by using OCALLs. That gives the attacker an extremely well defined surface, you know exactly what needs to be spoofed
11:52 <+bridge_> <learath2> You mean an “anti-cheat driver”? That is indeed the very best you can do, but even that isn’t foolproof. A lot of ancient unmaintained drivers that are signed out there. As long as the attacker also runs code at the kernel level you still can’t detect it
11:53 <+bridge_> <totar> this is pretty easy to fix, you just maintain a short-ish list of the vulnerable drivers
11:53 <+bridge_> <totar> and check if they're loaded
11:53 <+bridge_> <totar> (easy if you're AAA anticheat dev)
11:54 <+bridge_> <learath2> Funnily enough I never really had a problem with this. Settinf Xft.dpi always just worked for me 😄
11:57 <+bridge_> <learath2> Afaik most drivers don’t even get measured by the TPM. So you don’t have a reliable way to know what is loaded when
11:57 <+bridge_> <totar> idk I've seen many sources explicitly say that this is the technique valorant uses
11:58 <+bridge_> <totar> and it seems to work
11:59 <+bridge_> <learath2> Once you are running at ring 0 all the drivers are peers, you can pretty much just inject your code somewhere else and unload yourself
11:59 <+bridge_> <totar> easier said than done
11:59 <+bridge_> <totar> also I thought that the entire point of secureboot was literally to avoid this
12:00 <+bridge_> <totar> the hardware verifies that your driver hasn't been tampered
12:00 <+bridge_> <learath2> Ofc, I’m just talking about fundamental limits of trying to do trusted computing on untrusted hardware
12:01 <+bridge_> <learath2> SecureBoot measures/verifies up to the BootLoader and the Kernel (and some subset of drivers iirc). After that it’s the kernel enforcing the driver policy, for windows it enforces a signature by microsoft e.g.
12:01 <+bridge_> <totar> hmm
12:02 <+bridge_> <totar> I thought there was like some mechanism that the kernal will tell you all drivers that were loaded
12:02 <+bridge_> <totar> I thought there was like some mechanism that the kernel will tell you all drivers that were loaded
12:02 <+bridge_> <chinesemelon> https://cdn.discordapp.com/attachments/293493549758939136/1460589822467903619/Screenshot_20260113_190144.jpg?ex=696777c6&is=69662646&hm=cee05aad010bf22529098e446611fe8eec5bf9c3117085eda32d70ea29ced907&
12:02 <+bridge_> <learath2> It’s not even round wtf
12:03 <+bridge_> <melon> That design, believe it or not is just fine to handle
12:03 <+bridge_> <melon> Bad drivers it is
12:03 <+bridge_> <learath2> Problem is that there is no “separation of privileges” within the kernel, the drivers and the kernel pretty much operate on the same privilege level
12:04 <+ChillerDragon> i do not think it is a secret how to connect to lowhosting firewall protected servers
12:04 <+bridge_> <chinesemelon> Just a random short pull that reminds me of that "ASCII art" of yours
12:04 <+ChillerDragon> but i am not 100% sure davide wants to share it publicely but its quite obvious and has been mentioned multiple times already
12:05 <+ChillerDragon> @gorp_tw yes its davide55
12:05 <+ChillerDragon> @gorp_tw who is curly?
12:05 <+bridge_> <chinesemelon> is it DeiVid or DaVeed
12:05 <+ChillerDragon> @gorp_tw what client cant connect to ger? are you using the luluworlds thing right now? i guess i could look into implementing it
12:06 <+bridge_> <Assa> This is obviously bad design, I have a middle-less Kreisverkehr in my village and the local firefighters have to clean an accident there twice a year
12:07 <+bridge_> <chinesemelon> please do not comment on the video content anymore, I didn't even watch it. Or I have ruined #developer once again
12:08 <+bridge_> <chinesemelon> I'm just replying to this
12:08 <+bridge_> <chinesemelon> https://cdn.discordapp.com/attachments/293493549758939136/1460591317003403284/Screenshot_20260113_190814.jpg?ex=6967792a&is=696627aa&hm=9ade37852a17022aaca6679d2c88ab3ef33498e9a7916fe06ef141ee82a2b35f&
12:08 <+bridge_> <learath2> There is a fix to this that they are using nowadays. The fundamental issue is that there is no higher level of privilege to regulate this, so engineers at microsoft thought “why not introduce a higher level?”. So nowadays we have HVCI, technically every Windows installation is actually running virtualized. So the hypervisor can be used to check code integrity of the kernel. So you can’t do the easy attacks of just modifying the kernel code us
12:09 <+bridge_> <learath2> (but that doesn’t stop your malicious driver from just unlinking itself from the loaded driver list 😄 )
12:13 <+bridge_> <Assa> only linux OS github runners support is ubuntu, common github L
12:15 <+bridge_> <aegisub> considering how broken the existing runners are this may be a good thing
12:15 <+bridge_> <aegisub> considering how broken the existing runner images are this may be a good thing
12:15 <+bridge_> <totar> TPM stores a record of things that happened during boot so you can remotely verify if a known vulnerable driver was loaded
12:15 <+bridge_> <totar> https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices
12:16 <+bridge_> <Assa> Microslop
12:16 <+bridge_> <totar> the "TCG log"
12:19 <+bridge_> <learath2> From that same page, this is sort of what I remember from when I researched this for my secureboot “paper”. It’s only the early boot drivers that get measured
12:19 <+bridge_> <learath2> https://cdn.discordapp.com/attachments/293493549758939136/1460594002175987713/image0.jpg?ex=69677baa&is=69662a2a&hm=4f0e726f405800621360ac9b698c01ee544bed78938b64966f378727938c3db7&
12:20 <+bridge_> <aegisub> if you need other distros you can use docker and/or vms
12:20 <+bridge_> <learath2> The ELAM driver is the last properly measured part, after that the job of filtering out bad drivers is delegated to that
12:21 <+bridge_> <totar> but you only need to care about the initial boot, after that you can trust your own anti-cheat code to prevent bad drivers?
12:21 <+ChillerDragon> @gorp_tw what did you do with the bit operations i am currently failing to install the bitops-lua lib and would like to get rid of it. I wonder why i needed it and you dont
12:21 <+ChillerDragon> maybe i wanted to support old lua idk i forgot
12:23 <+bridge_> <learath2> Well two things, first you have to guarantee that your driver is loaded right after the last measured component so you can keep the chain of trust going. Second, Microsoft has signed thousands of drivers, over decades, there will be some you miss. It’s just like the cat and mouse game we play in the user-space, just now within the kernel 😛
12:24 <+bridge_> <totar> I think it's a much easier cat and mouse game, the mice already gave up
12:25 <+bridge_> <learath2> It’s just not profitable anymore, why would anyone waste a kernel 0 day on a Valorant cheat?
12:26 <+bridge_> <learath2> If I find a kernel 0 day I am selling it to the NSA and moving to the bahamas
12:26 <+bridge_> <totar> the issue isn't even that they need a kernel 0 day, it's that you have to burn them every time, and regular cheat detection is very possible, so once they notice that "all these people with rare sus driver are cheating" the game is over and you're back to finding a vulnerable driver
12:26 <+bridge_> <teero777> im now working on a 4k screen and everything is terribly small xdd
12:26 <+bridge_> <teero777> most applications apparently don't have automatic dpi scaling so i have to configure them. the problem is that that i work on multiple different pcs/laptops with different screens so i need to have scripts that automatically change configs based on the detected dpi. it works for now but i wouldn't say its a good solution
12:27 <+bridge_> <teero777> also i just noticed i need to be a good programmer and implement auto dpi scaling in my own applications too so im doing that rn
12:28 <+bridge_> <learath2> There are some drivers you couldn’t burn, so maybe you can find a bug in one of the early boot drivers, there are multiple filesystem drivers there so a fair bit of attack surface. Idk you’d have to get very creative and the reward is tiny
12:29 <+bridge_> <learath2> And at the very end of the day, you can still just use computer vision and feed the inputs back through a mouse and keyboard. There is no winning, you can just make it more annoying
12:29 <+bridge_> <learath2> Trusted computing on untrusted hardware is just fundamentally an oxymoron
12:30 <+bridge_> <totar> just because the computer vision thing is possible doesn't mean it's not a categorical difference in cheat protection
12:31 <+bridge_> <learath2> I guess the greatest success is secure enclaves. They really do just allow shipping secrets to clients
12:31 <+bridge_> <totar> it's much easier to detect mouse movements than a user having secret knowledge of all the enemy positions
12:31 <+bridge_> <totar> also, once the mice give up you have full control over the system
12:32 <+bridge_> <totar> the valorant devs say they send 1000hz mouse data back to the server
12:32 <+bridge_> <totar> and they can trust it 100%
12:33 <+bridge_> <learath2> It’s just not worth it to hack anymore, which is I guess a success. At the cost of running a black box binary blob as a kernel driver
12:34 <+bridge_> <totar> if I'm a gamer the purpose of my PC is to play the game, you don't hear people complaining about their xbox or ps5 "running binary blob kernel drivers"
12:34 <+bridge_> <totar> (well you do but they're stupid and should just buy a real PC)
12:34 <+bridge_> <learath2> You don’t do banking on your xbox or commit crimes on your xbox
12:34 <+bridge_> <totar> how is that related
12:35 <+bridge_> <learath2> Well if I am doing crimes I don’t want the glorious state of China to be snooping on my crimes
12:35 <+bridge_> <learath2> You pretty much need two computers to have any actual privacy now
12:36 <+bridge_> <totar> or you can see your computer as having 2 modes, 1 for running trusted code and 1 for running untrusted code
12:36 <+bridge_> <totar> that would be perfectly fine and everyone would be happy
12:36 <+bridge_> <totar> it's not widely supported in practice
12:38 <+bridge_> <learath2> As soon as there is one untrustworthy driver in there you can’t ever have security while booted into Windows. You could dualboot, but who is stopping the driver from installing a rootkit on my other disks?
12:38 <+bridge_> <totar> see
12:38 <+bridge_> <learath2> You can recover some semblance of security using secureboot on your other OS too.
12:38 <+bridge_> <totar> you would need new mechanisms
12:39 <+bridge_> <totar> for seperating them
12:39 <+bridge_> <totar> for separating them
12:39 <+bridge_> <learath2> But then who is stopping the driver from flat out installing a bootkit? SecureBoot does secure the early boot but there are at least 3 documented attacks on it that require a uefi update to fix, which means lots of vulnerable devices around
12:41 <+bridge_> <learath2> Btw this is all theoretical things I am talking about. In reality most people just don’t care to begin with
12:41 <+bridge_> <totar> I don't see how that's related, an attestable environment and privacy are not inherently conflicted things
12:42 <+bridge_> <learath2> Attestable environment is not the issue, an attestable environment is not enough to prevent cheating. It’s the kernel driver that’s breaking the privacy, not attestation
12:44 <+bridge_> <totar> it's theoretically possible that you compile the anticheat driver yourself
12:44 <+bridge_> <totar> and thus can verify it
12:45 <+bridge_> <learath2> Yeah, this would work, but then you need your anticheat to be perfect
12:45 <+bridge_> <totar> that's true
12:45 <+bridge_> <learath2> You can go to the extreme to solve it actually, like xbox
12:46 <+bridge_> <learath2> Literally do not allow anything unsigned to run ever, never have any code decrypted unless it’s immediately running, attest to every single piece of code ever run with a hardware tpm
12:46 <+bridge_> <learath2> Do it all in a single chip so nothing travels outside the secure domain ever
12:46 <+bridge_> <totar> ok sure but does that solve the privacy issue?
12:47 <+bridge_> <learath2> Not at all, but I just assumed an expectation of privacy isn’t a thing on a game console
12:48 <+bridge_> <_qey> Wen akkounts? I’ve made my own anti-cheat, I need bans to persist.
12:48 <+bridge_> <learath2> Solving privacy is quite tough, maybe Microsoft could provide a special sort of driver that can run at ring 3 with elevated privileges and isolation from other processes
12:48 <+bridge_> <kebscs> @totar why is predict tele pr in draft
12:48 <+bridge_> <kebscs> Isn't it ready
12:48 <+bridge_> <totar> no :(
12:48 <+bridge_> <totar> I ran into blocker
12:48 <+bridge_> <kebscs> What is it
12:49 <+bridge_> <totar> m_StartTick is fake and it ruins my invariant, so we need to add m_RealStartTick but that's ugly and idk what to do
12:50 <+bridge_> <totar> if you have an idea please tell
12:52 <+bridge_> <qxdfox> why is it fake im confused
12:52 <+bridge_> <qxdfox> any link to where someone explains
12:53 <+bridge_> <totar> my invariant is that there can only be 1 projectile per [Proj Type, Start Tick] but the server updates m_StartTick to the current gametick when it teleports something or when a laser bounces of a wall. This means that I lose my unique key for all projectiles that I use to ensure projectiles have unique RNG
12:54 <+bridge_> <totar> my invariant is that there can only be 1 projectile per [Tee, Proj Type, Start Tick] but the server updates m_StartTick to the current gametick when it teleports something or when a laser bounces of a wall. This means that I lose my unique key for all projectiles that I use to ensure projectiles have unique RNG
12:54 <+bridge_> <learath2> In that case, why not introduce a proper unique key instead of the ugly `m_RealStartTick`?
12:54 <+bridge_> <totar> not so easy
12:55 <+bridge_> <totar> the client and server need to agree on the unique key without talking to each other, and without knowing any of the events that happened
12:55 <+bridge_> <totar> if you can do that then sure
13:07 <+bridge_> <totar> I guess you could keep ``m_RealStartTick`` out of the protocol if you have the client and server both track it, and then they would get the same result when calculating a unique ID, so when the server takes ownership of the projectile it matches the ID that the client assigned. but that doesn't feel any better than just putting ``m_RealStartTick`` in the protocol
13:09 <+bridge_> <kebscs> Is it the same that predicted projectiles spawn with - 1, before they get matched with server's projectile?
13:09 <+bridge_> <kebscs> Or is it different
13:09 <+bridge_> <totar> -1 what?
13:11 <+bridge_> <qxdfox> id
13:13 <+bridge_> <totar> currently predicted projectiles do spawn with id -1, and when they arrive in the snapshot they get a real ID and on the same tick we stop running the prediction input that created them
13:14 <+bridge_> <totar> tbh I'm not really sure how the bullet trails get connected between them
13:17 <+bridge_> <totar> oh m_StartPos exists ok
13:35 <+bridge_> <kebscs> So after this happens start tick is invalidated?
13:36 <+bridge_> <totar> depends what you mean by invalidated
13:37 <+bridge_> <totar> my PR still uses the same code before and after the server owns the projectile, because neither the client or server can predict when that will be. The client could try to ack that their recieved the real ID and the server would ack back or something and they start using the ID alone for the RNG but that's a huge mess
13:37 <+bridge_> <totar> my PR still uses the same code before and after the server owns the projectile, because neither the client or server can predict when that will be. The client could try to ack that they recieved the real ID and the server would ack back or something and they start using the ID alone for the RNG but that's a huge mess
13:37 <+bridge_> <totar> well I guess the snapshot ack alone is enough for that, but it's still silly
13:38 <+bridge_> <totar> they would have to switch from one rng algorithm to another on the same tick, which is just complex for no reason
13:40 <+bridge_> <totar> from the server's perspective there's no distinction between when the client is using ID -1 vs the real ID, it doesn't know. So it just had to use an RNG that doesn't rely on the ID of the projectile
13:44 <+bridge_> <totar> I am fine with any solution that works as long as others agree that there's not something better we could have done
13:44 <+bridge_> <totar> I said m_RealStartTick was ugly but I have no better ideas
13:56 <+bridge_> <learath2> Is this so the client can predict the origination of the projectile too?
13:58 <+bridge_> <learath2> Could we maybe use the starting position of the projectile rounded into buckets?
14:01 <+bridge_> <pilonpl> Isn't there a simpler solution than manually implementing prediction for everything?
14:01 <+bridge_> <totar> wdym rounded into buckets? I don't think starting position adds much uniqueness, you can fire two projectiles from the same position?
14:02 <+bridge_> <totar> the nice thing about StartTick is that it's literally impossible to shoot two projectiles on the same tick, so you can never get the same RNG result
14:02 <+bridge_> <learath2> Oh, true we wanted to preserve randomness of the tp destinations
14:03 <+bridge_> <totar> yeah
14:03 <+bridge_> <learath2> Hey, maybe `m_RealStartTick` is the one true answer. It fits everything you need without being very complicated at all
14:04 <+bridge_> <learath2> Maybe a projectile counter per person as a unique id?
14:04 <+bridge_> <totar> If you think so then I'm ok with it. It just sounded really annoying to justify to maintainer in review
14:05 <+bridge_> <learath2> I can think about it a little more, (it would definitely be better if we had something even cleaner) but it really does sound like a nice simple solution
14:07 <+bridge_> <totar> the other "option" is we just mix all the state variables we have into the RNG and hope that it makes it unique in any way that matters xd
14:08 <+bridge_> <totar> in practice it would be extremely difficult to get two projectiles to hit a teleport on the same tick with the same position/velocity/angle
14:08 <+bridge_> <totar> but this makes me uncomfortable because there might be some edge case
14:10 <+bridge_> <totar> lol linus torvalds publishes literally anything and it gets 3k stars 
14:10 <+bridge_> <totar> <https://github.com/torvalds/AudioNoise>
14:11 <+bridge_> <learath2> What makes a counter not feasible? As the owner of the projectile you should always know what the counter is at unless the server launches projectiles on your behalf
14:12 <+bridge_> <totar> can you be more specific about the counter, do you mean owned by the Tee or the Projectile? It increments when a teleport happens?
14:12 <+bridge_> <learath2> I mean owned by the tee, every time the tee creates a projectile it gets incremented
14:13 <+bridge_> <totar> uh let me think about that
14:14 <+bridge_> <learath2> Maybe there is an issue with predicting other peoples projectiles, but by the time you see the other persons projectile you have already received a snap which could include the id
14:14 <+bridge_> <totar> not true
14:14 <+bridge_> <totar> they can hold fire and auto fire
14:15 <+bridge_> <learath2> So that only leaves the edge case of predicting another player creating a projectile, which idk how to solve tbh with you 😄
14:15 <+bridge_> <learath2> Do we even predict other people creating projectiles?
14:15 <+bridge_> <totar> yeah why not?
14:15 <+bridge_> <totar> I don't actually see any issue with the counter in that aspect
14:15 <+bridge_> <learath2> Is that something meant to be predictable? It would misbehave if say they were holding fire and suddenly stopped
14:15 <+bridge_> <totar> idk
14:16 <+bridge_> <totar> maybe we dont?
14:16 <+bridge_> <learath2> You know much more about the prediction code than I do anyway, so it's up to you. I'm not completely against `m_RealStartTick` if a counter as an id is not feasible
14:16 <+bridge_> <totar> we definitely do it for dummy
14:16 <+bridge_> <totar> I am still thinking about the counter idea
14:17 <+bridge_> <totar> it would be less data since it's per tee instead of per projectile
14:17 <+bridge_> <learath2> dummy is quite a weird edge case of a second local client, I don't even know if we "predict" it in the same sense as "predict others"
14:17 <+bridge_> <totar> oh right
14:17 <+bridge_> <totar> wait
14:18 <+bridge_> <inv41idu53rn4m3> Relating to dummy prediction, I think the dummy aimbot feature is delayed on high ping servers?
14:19 <+bridge_> <totar> I guess we don't call OnPredictedInput for other players, we just let it re-use the input that it had?
14:19 <+bridge_> <inv41idu53rn4m3> I have dummy missing lasers sometimes when I'm moving fast on high ping
14:19 <+bridge_> <totar> but pre-inputs change this quite a lot
14:19 <+bridge_> <totar> we treat players with pre-inputs like dummies basically
14:23 <+bridge_> <totar> yeah we don't predict hold fire projectiles from normal players I guess
14:23 <+bridge_> <totar> yeah we don't predict hold fire created projectiles from normal players I guess
14:24 <+bridge_> <totar> idk if that changes anything
14:24 <+bridge_> <totar> I don't really think it does
14:25 <+bridge_> <totar> hmm
14:30 <+bridge_> <totar> so what would actually happen with the counter?
14:30 <+bridge_> <totar> 
14:30 <+bridge_> <totar> - The server sends you a snap which has the initial count value for all tees
14:30 <+bridge_> <totar> - You shoot some projectiles, the projectiles would then become uniquely identified by [FireCount, Tee, StartTick]
14:30 <+bridge_> <totar> - But an issue is that without any other information when the server tells us about sends use a Snap with a bunch of tee-created projectiles how can we predict future teleports that they do without the server telling us their "FireCount" value? 
14:30 <+bridge_> <totar> - So we still end up needing to add "FireCount" to the projectile data?
14:30 <+bridge_> <totar> - This somewhat defeats the purpose of the counter?
14:31 <+bridge_> <totar> 
14:31 <+bridge_> <totar> @learath2 does this make sense?
14:31 <+bridge_> <totar> so what would actually happen with the counter?
14:31 <+bridge_> <totar> 
14:31 <+bridge_> <totar> - The server sends you a snap which has the initial count value for all tees
14:31 <+bridge_> <totar> - You shoot some projectiles, the projectiles would then become uniquely identified by [FireCount, Tee, StartTick]
14:31 <+bridge_> <totar> - But an issue is that without any other information when the server sends us a Snap with a bunch of tee-created projectiles how can we predict future teleports that they do without the server telling us their "FireCount" value? 
14:31 <+bridge_> <totar> - So we still end up needing to add "FireCount" to the projectile data?
14:31 <+bridge_> <totar> - This somewhat defeats the purpose of the counter?
14:31 <+bridge_> <totar> 
14:31 <+bridge_> <totar> @learath2 does this make sense?
14:32 <+bridge_> <totar> It seems to not save any data
14:32 <+bridge_> <learath2> Yeah, it definitely needs to be part of the projectile data, your analysis looks sane. Perhaps it's just a little less weird than `m_RealStartTick` but it has no extra value
14:34 <+bridge_> <totar> we don't have to literally call it ``m_RealStartTick`` if that helps 😄, is ``m_SpawnTick`` more palatable?
14:34 <+bridge_> <learath2> Yeah that does sound better 😛
14:34 <+bridge_> <totar> unless the counter has some other benefit that I can't think of that would make it better
14:35 <+bridge_> <learath2> gtg for a bit, I'll ponder this a little more on the train, but likely not
14:35 <+bridge_> <totar> ok cya, thanks for helping
14:42 <+bridge_> <totar> so what would actually happen with the counter?
14:42 <+bridge_> <totar> 
14:42 <+bridge_> <totar> - The server sends you a snap which has the initial count value for all tees
14:42 <+bridge_> <totar> - You shoot some projectiles, the projectiles would then become uniquely identified by [FireCount, Tee]
14:42 <+bridge_> <totar> - But an issue is that without any other information when the server sends us a Snap with a bunch of tee-created projectiles how can we predict future teleports that they do without the server telling us their "FireCount" value? 
14:42 <+bridge_> <totar> - So we still end up needing to add "FireCount" to the projectile data?
14:42 <+bridge_> <totar> - This somewhat defeats the purpose of the counter?
14:42 <+bridge_> <totar> 
14:42 <+bridge_> <totar> @learath2 does this make sense?
14:42 <+bridge_> <totar> oops I wrote "StartTick" in the counter example, that was wrong
15:13 <+bridge_> <qxdfox> StartTick changes when going trough tele? why
15:37 <+bridge_> <kebscs> For example the range of laser projectile resets
15:38 <+bridge_> <qxdfox> so if the end of the laser barely reaches a tele it has its full range again at its destination?
15:38 <+bridge_> <qxdfox> odd
15:39 <+bridge_> <kebscs> Yes
15:39 <+bridge_> <qxdfox> was this intentional or did it just happen
15:40 <+bridge_> <kebscs> Someone coded it like that when adding teles
15:42 <+bridge_> <qxdfox> doesnt seem right to me but i guess
15:44 <+bridge_> <kebscs> Nvm I think my memory is wrong and it doesn't increase range
15:44 <+bridge_> <kebscs> But I'm pretty sure it did smth
15:44 <+bridge_> <01000111g> its rooted deep in the hidden teeworlds lore. teleportation tiles are ancient sources of mystical power that predate the creation of tees by the teegods. Therefore they are able to supply fading laser rays with new energy
15:46 <+bridge_> <qxdfox> do we have a 2 hour long teeworlds lore video
15:46 <+bridge_> <qxdfox> id watch it
15:50 <+bridge_> <qxdfox> ah, starttick influences the width of the laser
16:26 <+bridge_> <remakepower> lore of teeworlds?
16:27 <+bridge_> <remakepower> cool
17:55 <+bridge_> <chillerdragon> @zwelf2: could you look into Teeworlds \#general bridge?
17:55 <+bridge_> <chillerdragon> It seems to be read only for matrix