lmaoo

exactly

A disease that turns you into a lime? Horrifying

I think KZfaq has the same idea. It served me an ad for a mobile game about bugs fighting.

The midwest be like

/tick freeze stops the internal server ticks, and therefore doesn’t harm or affect in any way the client itself. I think it’s quite important to make clear how Minecraft works, where your world or save is actually a separate server. The client doesn’t necessarily rely on ticks, and only on the information provided by the internal server (your world). This means that while the server might be dying, your client is likely going to be just fine as it’s not affected by the server’s tick timings. It’s pretty much like getting the official Minecraft server JAR and running it on localhost. The results would be the same

In the minecraft however there is no delta timin, everything assumes there will be 20 ticks per second and changing that will make everything slower or faster

​@@ShadowTheAge delta timing is tick, and tick is delta timing. I mean, because the code has to explain to CPU what "tick" is, and the meaning of ticks for a low-level programming is delta-time (as said in the video). Maybe some games call "ticks" as "ticks" in their game code, but it is merely an abstraction, instead there's a lower-level code that actually explain what "ticks" is, and it is delta-time. For example, let's do 10ticks per second, which is delta-time of 0.1second, so for a low-level code, such as C++, you do an infinite loop and for each pass you add a ""sleep" command to CPU for 0.1second (to let the CPU rest for 0.1second or let it to do other task), and you define this as 1 tick for higher-level code like LUA, and modders and devs only need to code on LUA.

so now you can TAS minecraft, neat

Minecraft sets ticks on the server, not the client. This is also how most multiplayer games would do this; as baissicaly all of the game code is done on servers; and the client is just a dummy, making the graphics and sending out inputs.

the credits at the end were funny as well lmao

2 days ago?

@@nodrognameerf unforeseen consequences of being a sponsor

@@olegmoki lol

That gave me a good laugh

@sbr9598 It's all just a really well made Quake mod

Or decino

Since it's peer to peer, the issue with being splatted by a dead player is more likely that the other player's screen showed that they killed the first player before they received info that they died, resulting in both players saying "I killed you". Since there's no server to sanity check or to prioritize one player based off timestamps, both kills end up going through regardless.

Splatoon tickrate is 60, but only sends and receives data packets from other players every 4 ticks (so 15 ticks a second). This is why replays in Splatoon 3 look really floaty and not 100% accurate in terms of the movements and actions you've made during a battle as it's showing how you would of appeared to other players (as you and other players were only being captured every 4 ticks). The packets sent still contain certain info of events that occured between those other 3 ticks when packets weren't being sent however. OatmealDome has an excellent article on Splatoon (2)'s netcode if you're interested. It's a bit technical and has more info than what I've mentioned here, but it was an interestimg read.

When a company doesn't host servers but still asks you to pay for online

I guess it helps that ink moves a lot slower than bullets which are usually implemented as a single raycast

and what you said can be seen on GTA 3 and VC's engine

also, the dt system is often the culprit of nondeterministic physics.

The valve equivalent to the farlands

A lot of problems are caused when divisions are involved too. I remember seeing bugs in some old games where values proportional to dt were being used as the divisor for certain algorithms and when they get too small that's how you get the objects that fly around too quickly and so on. I believe in the simpsons hit and run, dt was calculated with such low precision that it could be 0 on modern hardware, which would just instantly set your coordinates to NaN and the world would disappear.

@@jetfaker6666 >instantly set your coordinates to NaN and the world would disappear. Lmao

You would love shounic's videos, if you don't already watch them

@@yarknark i'm aware of that channel and really like the vids but thank u anyway :)

same

This video contains 5 examples of singleplayer games that do have issues stemming from frame rate, so this doesn't make sense.

Games don't need to run the client and server at the same TPS to function correctly, as long as they track stuff with real time instead of ticks

While it's true that this video is just a simplified explication of the client/server architecture, there's a reason games like Minecraft also use it in single player - it solves performance problems and is much more predictable. Before Minecraft separated the server and client, chunk generation used to briefly freeze the game. (Unrelated , but wayyy back when, Minecraft used to use the SYSTEM CLOCK to calculate delta time)

@pinsplash I mean that the Source engine’s tick system is much much more than a simple fixed rate function system. Other game engines have fixed rate functions but that alone is no where near enough to make multiplayer possible. You mentioned that Source does interpolation but you didn’t explain why. Source does interpolation because the game state is only updated on each tick. The vast majority of games update the game state on every frame so it’s always deterministic and there is no jitter. So why does source do it? Because you can’t instantly broadcast every state update over the network. It’s just too expensive and error prone. It’s a model that is developed solely for multiplayer and reused for single player because it’s easier than maintaining two distinct systems. I’m not saying that you’re wrong. It does help fix framerate dependency issues but talking about the broader context is fun and informative . :)

@Hunter M Using clocks to synchronize the client and server is really quite difficult. It means that the client and server need to have their clocks tightly synchronized and all clients need to have a timer with high resolution (1ms or less). Also, source clients don’t really “run” the server ticks. They just store the snapshots and use them for interpolation. The client can sample the ticks at a rate different than the server without much issues if tuned correctly. In fact the interpolation period is 100ms is so clients can continuously interpolate even if they’re receiving ticks slower than 66 per second. Why? Valve was accounting for packet loss, network jitter, etc

@@richardvlasek2445 Literally everything because we were given source code to a proto version of the game lmfao. There's a lot of really cool shit going on in the modding discord all the time if you're interested at all. As for what content people want to make, depends on your creativity ofc. People are getting more and more into custom code and full game mods, which weren't possible with previous tools

I didn't know Harry Potter and the Chamber of Secrets was considered a part of the Unreal series, but surely it makes sense when you think about it!!!!!!111

@@TarenGarond Lmfao I get the joke but I mean it's a UE1 game, same with HP1PC and HP3PC is on UE2

​@@OmegaRC59 Remember Unreal is a game(series) and Unreal Engine is a game engine, if you ever disrespect the Unreal series like this again I will find you, and one day stand beside you at the bus stop making a mildly annoying noise for a few seconds! You hearing me dude!!!

@@TarenGarond you know what i take it back hp2 is part of the unreal series

minecraft is a weird example, as you suggested, the client and server are isolated from eachother, if the server runs at 1/5 the TPS (ticks per second) (its also worth mentioning MSPT, milliseconds per tick, which is the measure of how long each tick takes to calculate, useful for lag scale testing and benchmarking) the default is 20 btw so 1/5 would be 4, the game will run 4 times slower on the server end, so mobs will move 4 times slower and etc... however the player will still be moving normally, its also possible you'll experience rubber banding as well just because of the nature of lagging, but there are some very cursed things you can do because of this. similarly your client can be experiencing 2fps while the server can be running at 20tps perfectly, this is really annoying from the player side but the server can be practically idling, for instance, idk about newer versions but in 1.17 if you place about 125000 composters and place a piston and start clocking it at a 5gt interval (fast observer clock) the client will absolutely kill itself, however basically nothing happens to the server. Why the client kills itself is a mystery to me but the suggestion that the client for some reason checks 125k composters every piston activation (on the client side) is fucking hilarious. In recent versions the lighting has been decoupled from the server thread and up until you could artificially slow down the lighting thread so much that it just quit processing updates all together, this allowed you to get cursed lighting sources as well as objects that should emit light, not emitting light (portals for instance) though this specific issue was patched fairly shortly after 1.16 iirc, the threads are still decoupled though. excuse the long winded rant, im a bit of a technical player and have seen some shit so i know a bit about the game lol.

The minecraft client's tickrate is actually tied to FPS, indirectly. The game attempts to tick every frame. It will do a max of 10 ticks per frame. This means that at 1 FPS, your game will run at half speed. 0.5 FPS, quarter speed. No clue what the fuck mojang was thinking.

@@DefineOutside yet the server is still independent from the client lol. Mojang does a lot of stupid shit.

IIRC the Quake III engine not only has separate threads for server & client, but they have to use the OS's network stack to communicate, as if the server was a dedicated instance on another system makes sense for a multiplayer focused game, saves a lot of unnecessary code, and apparently worked fine for the singleplayer games that ran the engine as well.

@@liquidextal iirc OSes are just smart enough to detect programs using network stack to communicate on the same machine and run the communications through internal messaging structures instead of full network stack.

@Hoovy Simulator 2 host_framerate is a descendant from Goldsource. In there, if it's not zero, the engine overrides the "delta time" variable used for game logic with that command's value. So if you set it to 0.1, Goldsource would consider each frame to have taken 0.1 seconds. If you're running at 60FPS, which is 1/60 ≈ 0.0166 seconds per frame, this would result in the game logic running at 0.1/0.0166 ≈ 6 times faster than intended. Infact, if your FPS is a constant value like 60, you can set host_framerate to an equivalent value like 1/60 and the experience will seem basically the same. That's all for Half Life 1's Goldsource though. In Half Life 2's Source, I'd imagine it's the same thing, but in relation to the ticks and the tickrate lol

i think that would actually cause more non-deterministic behavior since objects getting iterated on later would be using a slightly higher DT

@@Pinsplash DT is from my understanding the time from the start of the previous frame to the start of the current frame, it is same for all calculations in the frame.

so just the length of the previous frame?

@@Pinsplash yeah, i've only ever seen it as the length of the previous frame

@Pinsplash Yes, the "delta" refers to the time elapsed since the previous frame. If your framerate is at a fixed 60fps, then your deltatime value every frame will be 0.01666666. This is generally useful, because it means that if your framerate is halved then your deltatime is doubled, meaning that objects will be moved twice as far per tick to compensate for the fact that each tick is happening half as frequently. However, it is not perfect by itself. Extremely high frame rates can lead to very tiny deltatime values which might cause weirdness due to floating point precision issues when fed into a highly sensitive physics engine. Very low framerates can result in collision detection issues because objects are moving too far in a single frame to correctly detect collisions with surfaces. On one frame they're on one side of the wall, the next frame they're on the other side, no chance to check for a collision in between. This is often exploited in older games like Donkey Kong 64 where they deliberately lower the framerate by spamming projectiles so they can clip through doors.

I use delta time as well, you ever run into the problems of grabbing window (grab like when you move a window) the delta time gets all fucked up

I fixed it once , so I get what going on

@@SuperShortAndSweet Yeah, that happens since windows, normally, just stop rendering and stop "thinking" completely when you move them around (to save on resources I guess). Applying the fix I mentioned helps with that, but of course it isn't perfect. One method that I saw to fix it from the root is to fake the window itself; basically making the app borderless but rendering the window with the engine, and adding all the functionalities real windows have, making it look exactly like the normal window but it isn't, and you can move it around without causing issues (since engine window movement doesn't really freeze the game when doing it).

​@@Chillaxowo i think what is happening is windows grab event is constanstly beening called, and there is speed or something tied to the handle event function, you making boarderless is smart fix, i think thats why it works, another thing, ive heard filtering out the event completely also works

The issue with simply relying on deltatime, even failsafed implementations, is that the physics will be non deterministic. For example collision will be checked more frequently so interactions will still play out differently on different hardware.

didn't they just fix it by adding more preset framerates?

I remember not being able to play Skyrim because my frame rate was too high and the horse would always go way off course in the beginning

When you turn off the fps limit in Skyrim the game just goes mad

Who said they save entire state of the game

It takes a snapshot of whatever the server state was during that tick.

(afaik, i might be wrong) Source saves specific variables defined in the game code named "DATADESC" for the server. When loading the save, Source restores the datadesc, and calls every entity's (Restore()) function.

Pretty sure this isn't talking about that, I play minecraft after all :P randomTickSpeed is simply the amount of block updates(plants, liquids etc) per an ACTUAL tick The minecraft equivalent is the carpet mod

I mean he seem to basically know nothing about it as his explanation why you go faster with higher fps is totally wrong XD

@@TarenGarond its not totally wrong, but to say his explanation was oversimplified to the point of being maybe wrong is true

​@@Sockren I disagree! He talk about the developers needing to know the hardware and extremely strongly insinuate that the frames/game-logic would "run away uncontrollably" as in old IBM-PC games if the game would run on faster hardware, this is not true as game-logic/frames is limited by being "v-synced"(Quite sure max FPS is half console frame output frequency). FPS limiting is talked about right after the GoldenEye "explanation" as "another solution"... And "delta time" is mentioned later which GoldenEye also uses and he didn't mention anything about it!!! As I'm a GoldenEye n00b I don't know the exact reason why you run faster with higher FPS but it seems to be some rounding error or some oversight(Or simply not caring about small differences) thingie going on, It is very very clearly not the same reason old IBM-PC games runs fast!

well sadly thats what people in the goldeneye speedrunning community think is happening. the game is rendering less triangles which means more frames. and because of how the game works it makes you move faster. its not a big difference but its big enough to be a speedrun strat.

Do you know more precisely what happens in this "quite complex acceleration logic" , or know somewhere one can read about it? I've wondered about this stuff for some while now, I've searched a bit on Google in the past but haven't found anything(Might just be a search n00b though XD).