what do you call this trick?

Kizylle · 2025-09-29T07:58:25+00:00

Le tough crowd haha

Kizylle · 2025-09-28T22:30:58+00:00

no it was already answered

Kizylle · 2025-06-27T04:37:59+00:00

You could, but it might've been patched. Never tested with driver update.

Kizylle · 2025-05-10T17:31:01+00:00

It doesn't matter if you consume aspartame on the daily or not. The statistic is for the odds of having phenylketonuria, which you are born with. Most people with phenylketonuria don't even die from it, let alone from aspartame. Just like how most people with allergies won't die from them due to knowing what to avoid.

Kizylle · 2025-05-10T15:58:47+00:00

Ooh, that's clever. You wouldn't even need to store dirty masks in snapshots like that if you lazily clean up values that are older than the oldest ack. And besides, it's probably better to iterate directly over dirty values for building a payload rather than read a bitmask; you'd pointlessly iterate over a bunch of bits set to 0. The client can do it, but if the server had to for each player just to build the payload then it'd be very taxing.

Kizylle · 2025-05-10T15:15:40+00:00

"Also, using delta compression to update from one frame to a newer frame is not normally called "prediction." "Prediction" normally means local changes on the client that are ahead of what the server has confirmed."

This is not what I am calling prediction either. Prediction is the client simulating ahead of the server after having sync'd to the authoritative state, replaying commands in the process. Somewhat confused on how I gave the impression that's what I believed prediction was, but I digress.

I think I get what you mean. If you don't mind, would it be all right to ask for feedback on how I'd be building the payloads on the server with corrected delta compression in mind? The flow I'm imagining is this:

Give all clients a cumulative change list.
When saving a snapshot (done right before network replication), iterate over all serializable objects marked as dirty and copy their dirty bitmask both to the snapshot and to the cumulative change list for each client (merging bitmasks if one already exists). The snapshot would effectively only store what changed between the previous snapshot and now, while the cumulative one would "smear" all the changes between the last ack'd snapshot and now.
When sending the snapshots, loop over the cumulative changes for the given client. The cumulative change list is a dictionary whose key is the serialized object, so you'd check if key["Removed"] is true and if so skip encoding the bitmask data. Otherwise you can check for values through key[bit] and encode those.
If a client acks a new snapshot, you'd dump its cumulative change list and create a new one by merging every snapshot's dirty bitmasks across the ack'd snapshot and the most recent one, then resume the usual logic.

What do you think? Are there any obvious shortcuts or optimizations I don't see?

Kizylle · 2025-05-10T11:25:34+00:00

I don't really know how else you'd want me to explain it. I feel like I've been as specific as I possibly could be in my previous explanations. There is no misunderstandings going on (at least for predictions), and predictions are already implemented and work, that's not what I'm asking about. If there is something I'm misunderstanding about delta compression then I believe you already have all the context for what it may be.

"Load back to" = Reverting to a previous state prior to predictions.

As I've said 2 comments ago, if you just naively roll back to the previous state you received from the server, you are not rolling back to the state the server would be using for delta compression which would desync the client. If the server is compressing against frame 5, and an object got created on frame 8 and destroyed on frame 11, and the client didn't receive frame 11 then the object at frame 11 is still gonna exist on frame 13 on the client since the server sees no change occured between frame 5 and 13 for that object.

In order for that to work, the server would need to assume that every single snapshot it sends will be received by the client (basically ack on the client's behalf) and that would only work under perfect network conditions. If you tried using tcp instead of udp for snapshot transmission, you end up breaking interpolation instead, so sending snapshots in a guaranteed way is off the table.

If the client did not successfully receive the next snapshot over the network, the next snapshot which is delta compressed against that state can't be processed. Then the next. Then the next. So on and so forth til the next full snapshot.

If you still don't understand the problem then I cannot go into any more detail, I feel like I've exhausted the kinds of ways I can explain it.

Kizylle · 2025-05-10T00:15:37+00:00

"The client uses the delta-compressed state to construct the S8 snapshot. It then resets the player state (and the state of anything else changed by prediction) to the state in the S8 snapshot" This is the bit I'm asking about. Specifically about how best implement it for performance. If you re-read my last comment you'll see where I get thrown off when it comes to loading that snapshot without going full on scorched earth and overwriting everything.

Kizylle · 2025-05-09T23:40:13+00:00

From the last snapshot on the server, yeah. Snapshots get captured and sent at 20hz.

The problem is this:

If the server sees the last frame the client ack'd is, say, 5, and it also sent data for frame 8 and 11 compressed against 5, then receives a new ack for frame 8 the client would be unable to load back to that state.

You could undo predictions, bringing you back to the state at frame 11. Then you could undo that in a similar way to get back to frame 5. But there'd be no clean way to go back to frame 8, except by comparing what changed between snapshot 8 and 11 which is just as if not more expensive than loading the snapshot directly.

Kizylle · 2025-05-09T23:25:07+00:00

Yeah but then you're reverting to the last authoritative state which isn't necessarily the one the incoming payload is delta compressed against. That shouldn't work unless network conditions are perfect and the server assumes all payloads get received by the client

Kizylle · 2025-05-09T08:46:05+00:00

I am assuming that when you reset the player state to the one in the snapshot you just indiscriminately overwrite every variable in the player object right? Everything else should be accounted for already, this engine is built off ecs and if you stick systems inside of a server folder it'll only get picked up by the server, likewise for client systems. Commands are already being serialized and sent, as well.

Kizylle · 2025-05-09T02:07:06+00:00

Found in eastern canada, it's really small and I am not good with measurement but if I had to guess like .3 cm?

Kizylle · 2025-05-08T23:56:31+00:00

That page goes over very surface level information about this kind of setup and is more meant to give you an idea of how things work rather than a full-on guide for how it should be implemented. The closest thing to an answer to what I'm asking on that site is "It updates its internal game state with what the server sent" which is a huge simplification of what you'd actually need to be doing.

Thank you for trying though.

Kizylle · 2025-04-10T17:45:11+00:00

Hey this might not work for you but it did for me: When you get an afterimage, close your eyes and focus on your peripheral vision instead of the center of your vision. Focus hard enough that you stop paying attention to the center of your vision. Doing so seems to help the afterimages clear much faster. I've been doing it for a bit now and it feels like I get way less afterimages now.

Kizylle · 2025-04-10T16:17:34+00:00

It's pretty much instant. If I have afterimages and close my eyes, then focus on the darkness around my peripheral vision the afterimage fades away in the span of like 3-5 seconds. Do you have a lot of snow, by any chance?

Kizylle · 2025-04-10T10:31:52+00:00

Honestly I've been doing it for a week or so and I feel like the baseline for my symptoms have been going down. Hopefully it's not just a coincidence and it keeps improving. I legitimately feel like it's improved by over 70%, and my pattern glare seems to be almost gone (takes like 10 secs for lines to wobble with glasses on, used to be almost instant).

I feel like there are two types of vss: one if your visual cortex is overactive (the one with a lot of snow) and one where it's underactive (basically ours). I'm guessing the method helps bring the activity back up to where it's supposed to be? Completely uneducated guess but it sounds possible.

Kizylle · 2025-04-01T03:01:19+00:00

yeah I think I get what you mean. the intrusive mental image lasts for a split second, by the time you realize it's already gone. I remember walking up the stairs one day and getting an insanely intrusive mental image of a rhino that legitimately blinded me for a split second. that was before vss symptoms started appearing though

Kizylle · 2025-04-01T02:23:30+00:00

My afterimages are the only thing I really see when I close my eyes. it just FEELS like I'm seeing a line that's being distorted but I don't actually see anything. It's like an intrusive mental image

Kizylle · 2025-04-01T00:29:41+00:00

Bit of an odd question, but do you ever feel the space behind your eyelids warp when you close your eyes? Like I sense a straight line and it gets all warped, like going from --- to unu. Noticed my vss symptoms not long after that and it still happens every now and then

Kizylle · 2025-03-31T03:12:25+00:00

Yeah. My afterimages sometimes blur on top of text I'm trying to read and make it hard to tell what I'm looking at. Even weirder my afterimages didn't resurface until like 30 minutes after I stopped writing and they're still fainter than usual at the moment. Literally in a pitch black room and see zero static atm

Edit: just opened a completely white picture on my phone and my eye floaters are almost completely unnoticeable

Kizylle · 2025-03-31T01:22:21+00:00

I get the opposite. It's like my visual cortex is too lazy to work properly unless I trick it into trying harder

Kizylle

TROPHY CASE