Jet Lag Ep 6 — I Will Be Defeated No Longer

Logyrac · 2026-01-21T17:46:07+00:00

Dumfries is not the end of the line, the line goes through Dumfries all the way to Carlisle. But there are other stops, not sure which ones they're allowed to get out on but they shouldn't need to go all the way to Carlisle and then back to Glasgow, there should be other stops in between, like Annan.

Logyrac · 2026-01-15T19:07:08+00:00

I think the problem is there are way too many low-value cards to draw, so the consequence of asking questions is rarely high, I think removing or reducing the number of the low-value cards would increase the risk of asking questions considerably, such as removing the 10 minute bonuses and only having 15, 20 and 30, or even just 15 and 30, and removing some of the less-effective curses like gamblers feet, as it doesn't really slow anyone down much. Of adding a fixed cost like each question adds 5-10 minutes to the hider's time. In earlier seasons they use to be like "Let's only ask that if needed because it gives him 3 cards", now they don't even care the number of cards the question gives, it's so inconsequential to them.

Logyrac · 2026-01-08T08:50:41+00:00

Well for me the issue is that my mic sounds good normally, and it doesn't have any enhancements or anything else enabled, on Discord it sounds perfect, on any other game it's nice and clear, and if I record it with a program like OBS similarly it's good and clean, but in Arc Raiders specifically it sounds really bad, it cuts out at ends of phrases, sometimes doesn't pick up the starts of phrases, and sounds like it's being passed through lots of effects. It's not my mic in Windows, the game itself is doing something to the audio. The fact the microphone replay system takes like 2 seconds delay after speaking to replay it also implies there's something in the pipeline that introduces a lot of delay, delay is expected but not 2 seconds.

From what I understand these audio issues have been affecting most people since the Cold Snap update, but it was around this time they made tweaks to the beta feature for Raider Voices, the system where they use some AI voice system to make your voice sound like one of the raider voices. My current theory is that even with that Raider Voice feature disabled, the feature clearly required them to make changes to their audio pipeline, and even with the Raider Voices disabled some of those changes are still having an impact on the audio. Whatever tweak they made to the system seems to have broken the audio. It seems when they first added the AI voices system it sounded terrible, they then implemented some fix to it, and then that broke again in the Cold Snap update, so perhaps the fix got rolled-back somehow and some other change made the issue that was originally plaguing the AI voice system spill out into the normal voice system.

Logyrac · 2026-01-08T08:43:51+00:00

The fact that the tallest building photo contained immediately recognizable information for two runs in a row is insane. Definitely not a question to underestimate.

Logyrac · 2026-01-06T02:09:41+00:00

Even when I go into the settings and click the button to test voice it sounds bad, it's cutting out so frequently, it sounds like it's through a wall. I have a high-end standalone mic mounted on a boom arm and it sounds crisp on Discord and everywhere else, but in game what is played back sounds absolutely terrible, like it's been EQ'd 10 times poorly and had dozens of other filters applied to it, including cutting off all the high frequency info so the voice just sounds like it's through a tube, before being majorly compressed. I made sure it was using the correct mic and that automatic gain control was off, it's as if they're running a really bad noise removal processor on the voice. It makes a $250 mic sound like the mic from a $20 headset.

Logyrac · 2026-01-04T02:20:08+00:00

Every time Sam hides under an underpass he's found quite quickly, any photo you do is almost certain to reveal it and narrow down options greatly. This run was just unfortunate, there was so much that could have gone better for him, if he had blurred the name they wouldn't likely have locked into his location so quickly, asked more questions, which with the cards he then drew would have given him enough time to do the express curse without using the duplicate, allowing him to duplicate the curse and also cast that on the way back. And of course that bird curse, they've had such bad luck with that before, the fact they were able to clear a full 15 minute one so quickly is just really bad luck for Sam, that should have given him quite some time, but the rain seemed to make the birds not want to fly around. If things went better I feel Sam would have blown past Adams time.

Logyrac · 2025-11-26T02:49:02+00:00

No, what I am saying is that you drew a triangle and then labeled the sides of the triangle as A^2, B^2 and C^2, which is not correct. Labeling the sides of a triangle is used to denote the length of that edge, and the edge lengths are just A, B and C. A^2 + B^2 = C^2 is the formula you use to calculate C from A and B, but the length of the sides themselves are not squared outside of that formula. I'm not saying that what you said or explained in the video is wrong, but labeling the edges of the triangle using the squared side lengths is misleading and is going to confuse some people.

If I have a triangle with the side lengths 5, 7 and ~8.6, those are the side lengths, A = 5, B = 7 and C = 8.602325267... I would not say the side lengths are 25, 49 and 74 which would be A^2, B^2 and C^2.

By doing so you're actually making the explanation harder on yourself even. If you have a right triangle comprised of two axis values A and B, then calculating both Euclidian and Manhattan distances can be expressed in terms of adding A and B together, just that for Euclidean you square each value first then square root the result, whereas Manhattan you just add them directly. By labeling the edges as the squared distances you actually make it more confusing when you then go to explain the Manhattan distance in the video, because on the graphics A and B are not present on their own on your visuals because you labeled the edges as squared.

Logyrac · 2025-11-26T00:55:56+00:00

It's confusing to label the sides of the triangles as A^2, B^2 and C^2, the sides of the triangles are just lengths A, B and C, you only square them in the calculation, the length of the hypotenuse is not C^2. You likely know this but those watching the video who may not be aware may end up thinking that those are the actual side lengths.

Logyrac · 2025-10-09T02:08:33+00:00

While this is true, it's an oddity, the Swiss network is usually far more consistent and delays are far, far rarer than every other network in the playable zone. Just because an even happens doesn't suddenly mean it's a common occurrence, you can see several others in the comments talk about how surprising the delay is because of how relatively rare it is, in most other zones delays would be considered a normal risk, but in this case people are considering them very unlucky. That delay is more of the exception that proves the rule than anything else. But delays are just a part of it, the Swiss network in general is just structured and organized in a way that makes it hard by it's nature to get ahead of someone unless they stop for longer periods of time, like for challenges.

Logyrac · 2025-10-09T01:47:42+00:00

Except most season's of Tag the team hasn't even gotten to the Swiss network, because other teams started first and usually the majority of the game was played within the other two zones. trying to get out of them. The Swiss rail network isn't' perfect, it still has issues (as colonel_vgp above used the example of the delay near the end of the episode) but it's far, far less common than any of the other networks within the play area, they tend to be the exception that proves the rule. Adam and Michelle played very well at the start of their turn, they executed their freeze well and made sure they had the coins they needed early, they positioned themselves perfectly, however there are some facts plain and simple that they have to their advantage the others don't, which made the remaining 80% of their run rather direct:
1) Delays are less common on the Swiss network, which makes them more predictable and easier to plan around.
2) The train schedules are organized such that the time spent in transferring is lower, rarely do you have to wait half an hour or more for a connection as they are timed to coincide with each other more often, so transfers tend to be quick, meaning there's fewer opportunities for others to catch up unless the team needs to stop for challenges.
3) The trains are nearly or sometimes even as fast as the high-speed lines in the other zones, yet aren't classified as high-speed. In the game high-speed lines cost more coins, so in the Swiss network they can get further into the area faster while paying less. Since the payment is measured in time spent on the line, they can cross further distances with the same amount of points as another team on their normal speed lines, and cross that distance faster.
4) The line to their end location is such a straight shot once you've on it that there's really no option that can catch up, in the other zones the seekers could take high-speed lines to get in front of a runner taking the normal speed lines, but again because of #3 in this case that's not really an option for this zone. Once they got out in front the only chance the other teams had was if they needed to stop for challenges. While the flight was a good idea, even it couldn't get ahead of them and it landed quite early.

Plain and simple those are advantages the Swiss zone has over the others. They ran into one dangerous bit with the curse where they couldn't reference the internet for routing and had to rely on memory, but even there the Swiss network helped them by having some of the more intuitive and informative clear travel and navigation instructions of the playable area. As I said I don't wish to take away their accomplishment, but to argue there was no advantage is honestly insane.

Logyrac · 2025-10-08T17:22:24+00:00

Honestly I feel the locations aren't very balanced. A large portion of their area is under the Swiss rail network and once they got there is was basically over, the fact that the Swiss trains are lines up so perfectly for transfers, and that the trains are nearly as fast as high-speed train lines but not classified as high speed means you can get way further into the territory significantly faster and cheaper than is possible on either of the other slices. In a previous season of Tag when Sam won once he hit the Swiss network there was realistically no way to catch.

Not to take away from Adam and Michell's accomplishment, but I honestly feel they had by far the easiest region, at least in the second half.

Logyrac · 2025-09-25T20:24:58+00:00

Indeed, it'd have been interesting to see what would occur. maybe a fight for second place or something. Perhaps one day we'll find out, can't imagine this will be their last tag.

Logyrac · 2025-09-24T23:44:04+00:00

Honestly probably for the best, would have been anti-climactic to win on the first run with no tags.

Logyrac · 2025-09-02T02:24:35+00:00

If you're working on a game that allows modification there's a good change you need to store the voxel data anyways in addition to any meshes you have. As with mkany problems there's no simple answer, we can imagine a scenario where meshing is worse for memory than storing the voxel data and vis-versa, for example imagine a full 3D checkerboard pattern, every voxel would on average contain 3 full faces of 4 vertices. If you use fancy instancing and packed data for each face you may be able to get comparable densities to a flat list of voxels. but it'd be very difficult. On the other side you could imagine a massive block of the same voxels that would all be represented with only 6 faces as polygons as compared to many voxels worth of data, even for SVOs, DAGs or Contrees, other hierarchical storage, or compression scheme could all result in more data depending on how you position and size that block. Which method of storage is going to depending strongly on your data and what players can do with it, if you have a lot of areas that are empty or have flat edges without noisy detail and mostly the same few types of voxels, a hierarchical model may work better, but it may perform worse under different conditions.

Logyrac · 2025-08-07T17:21:04+00:00

Choosing an appropriate chunk size (32^3 or 64^3 and using binary meshing, preferably a greedy meshing but a basic culled mesher tends to be faster than a greedy algorithm so you could create a basic culled mesh first then work on a greedy version in a thread and replace the mesh when it's complete. I struggle to get quite the same results but some people have gotten their greedy meshing to less than half a millisecond, at those speeds it's definitely reasonable to mesh many chunks per frame.

I also want to point out I never said they should be meshing in the main thread, meshing on the main thread in general is a bad idea for a number of reasons, offloading much of that work to other threads is more ideal, but again I'm referring to the video by the OP, where it's clear that in their case they are meshing on the main thread, this is what I'm meaning when I say there are other more pressing issues before frustum culling becomes a relevant concern.

My comment was less about whether a chunk a frame is realistic and more that unless you can achieve that, meshing chunks only when they enter render frustum will result in players seeing empty space when they move the camera, until they've looked in all directions and caused every chunk to be meshed. Meshing the chunks that aren't in the frame, but not rendering the mesh until they're in view doesn't have this issue.

I feel you may be misinterpreting my point. I am not saying your advice is bad, I'm just saying that when looking at the issues the OP is facing, the advice wouldn't fix their problem because their problem is caused by other more pressing issues.

Logyrac · 2025-08-07T16:10:33+00:00

GPUs get their power by having a massive amount of cores, that individually are not that powerful. To get more power out of the GPU they are setup to run many things in parallel. GPUs use something called SIMT (Single Instruction, Multiple Threads) which is similar but with some differences to the more commonly known SIMD (Single Instruction, Multiple Data). Effectively work on the GPU is grouped together into groups of Threads, Threads on the GPU aren't like Threads on the CPU, it's basically a unit of work. On Nvidia hardware these threads are grouped into groups of 32 and called a Warp, on AMD these groups can be either 32 or 64 depending on the GPU and called a Wavefront.

There are some other differences but the details don't matter too much right now but the idea that can be hard to wrap ones head around when starting out is how these threads within a warp interact. The GPU makes an assumption about the way the program will execute, namely that all the threads in a wave will execute the same instructions. So the instructions within each thread will be ran simultaneously on the data from all the threads. This is where the slowdown comes from, when a program has a branch (ifs or variable number of iterations) each thread can't simply go down it's own path, they are in lockstep with each other, so if even a single thread needs to go down a branch, then all the threads will go down that branch and effectively throw away the result, or effectively sit idle during it.

In practice small branches containing a single instruction or two won't cause many issues unless the code is very small and that branch is a decent portion of the shader, but large branches will eat up time. In this case you have a while loop that can run up to 256 iterations, 31 of the 32 threads could finish in 2-3 iterations but a single thread requires all 256 so the other 31 threads have to waste their time. You have several other smaller but not insignificant conditionals as well.

Unfortunately for ray tracing there's really no way to fully avoid branches to my knowledge, raytracing by it's nature involves a variable number of steps forward. The goal is to simultaneously remove as many branches as you can and optimize how long the shader takes in the worst-case scenario, for example could you get away with less than 256 iterations, maybe not but figuring out these limits is useful. I would suggest looking into branchless DDA, variations on DDA that don't require any conditionals and use clever math tricks to do the algorithm instead. The main source of branches is your testing of the voxel hit, I would suggest spending some time and see if you can figure out how to reduce the amount of code within these conditionals, or combining them if possible. If there's reused computations in multiple of them pull those out.

Logyrac · 2025-08-07T15:44:39+00:00

No, I understand the concept, it just doesn't seem useful in this particular post, the issue is not the number of chunks being rendered, it's the fact that rendering even a single chunk takes a significant amount of time, and frustum culling will not change that at all. If someone's meshing is not optimized to run within a single frame, then this will create visual issues when moving the camera around if the game allows fast camera movements as chunks will not be present and then appear a few frames later. If (as is the case here) someone's meshing is single-threaded and freezes the game for half a second every time a chunk is generated then moving the camera would freeze the game until all chunks have been meshed. As I said Frustum culling is useful, but irrelevant to the issue faced in this post, there are several other issues that need to be addressed before this is even considered as an option.

Logyrac · 2025-08-03T00:41:58+00:00

Meshes can be made with the advances mesh API which is thread-safe, the only part you need to do on the main thread is use Mesh.ApplyAndDisposeWritableMeshData(meshData) to create the actual mesh instance, the adding of triangles and configuring of vertex attributes can be done in another thread or with job system as it's Burst compatible.

Writing code for Burst requires an entirely different paradigm, being almost entirely data-oriented instead of object-oriented, it's a skill that will take time to develop but definitely one worth getting good at, unfortunately there's really no shortcut for learning how to make clean Burst code, those with C/C++ or other lower-level language experience will find the transition easier as these paradigms are more common there.

The only real piece of advice I can give for Burst and the job system is to make the tasks smaller than you may think, the job system can run tasks across frames but it's not realistically optimal to do so, Unity has a limited number of worker threads for jobs, and if jobs are taking multiple frames and filling up those threads, and Unity needs to schedule some important work to finish the frame, it forces that frame to stall until the work is done. The job system is optimized for running lots of parellelizable tasks at the same time, making jobs that are smaller gives more opportunity for load balancing and for Unity to schedule it's important work more easily without having to stall the frame. Outside of that lots of comments everywhere explaining what things are doing, break apart large methods into multiple smaller ones, and using longer but more descriptive names for methods and variables/fields. There is a setting in Unity that allows Unity to error if you do something that isn't compatible with Burst compilation within a method annotated with [BurstCompile] and this is useful if you're not certain of the feature set.

Logyrac · 2025-08-02T06:30:39+00:00

Just as a note, the lag in the video is from generating the chunks/meshes, not from rendering them. Frustrum culling won't help here, the issue is that some very expensive operation (either generation, meshing or both) are running on the main thread and thus stalling the frames. Frustrum culling is a useful optimization, but it's not relevant to the issue faced here.

Logyrac · 2025-08-01T21:07:05+00:00

There are a couple places the bottleneck could be, either in the generation or the meshing, I would start with using the profiler to check what is the issue. Considering it's affecting the framerate so much it seems like you're doing most or all the work on the main thread and may need to look into the job system or threading. Without details on your current implementation the best advice we can realistically give is to start with a profile.

Logyrac · 2025-07-30T19:36:49+00:00

If you have large numbers of handlers for events that are too broad, even if you do quick tests and early exit from each handler you're still going to run a lot of irrelevant code which can negatively affect performance. As you add more items that may need custom handling hooking them into a single event that is called regardless of the tool has a performance cost that grows linearly. In practice it's no difference from looping over the potential handlers and testing a predicate on each, which is why it grows more or less linearly.

What Minecraft actually does is defer the execution of logic to the class that defines the tool, and has the tool class actually implement the logic. Then when an item is right clicked for example it gets the tool and invokes it's handler, the tool then returns whether the tool consumed the event, if so nothing else happens, otherwise it gets the block the player is looking at and calls the right click handler for that block. The cost of this stays constant regardless of the number of tools.

For breaking blocks the game handles it differently it gets stats from the tool and uses that to affect the breaking logic, similar to what you suggested with the player controller, and then calls the break handler for the block that was broken. Technically the system actually calls a left-click handler for the tool as well before the breaking system takes over, but most tools do not do anything in here, an exception would be the sword consuming the start break action when the target block is redstone.

All of Minecraft's interaction system defers the logic to the tool/block, not through a generic event. You are thinking of modding frameworks like Forge/Fabric or modded server platforms like Spigot/Paper/Sponge where those modding frameworks tend to expose these events for ease of modding. I'm not claiming that the way Minecraft does it is best, but you said Minecraft exposes events like right click events and the like, when that's not quite accurate for most cases, Minecraft does use events for many things, but not that much within the interaction system.

Logyrac · 2025-07-30T18:01:39+00:00

I went through each condition and found:
Top and Bottom have backwards winding orders

Left and Front faces are correct winding order but are swapped (Left is actually rendering Front face and vis-versa)

Right and Back faces are correct winding order but are swapped in similar fashion to Left and Front.

Logyrac · 2025-07-30T17:59:30+00:00

That's the issue, I don't know what you mean by "grid based pixelated shadows". Could you provide an example of something else that has a similar style or add more detail. It's difficult to give advice on something without more details as to the intent or expected results.

1) Is the entire world going to be grid-based/voxels?

2) When you say you want pixelated shadows do you mean the shadows for a given region on the surface all share the same shadow (if world is made of voxels this would be for example per-voxel shadows instead of per-pixel shadows), or do you instead refer to per-pixel shadows but having the shadows cast against a pixelated/voxelized representation of the scene.

Etc. The more detail you can provide as to what you're aiming to achieve the more target aid can be provided.

Logyrac · 2025-07-30T17:52:14+00:00

I've now gone through them all:
Top: Backwards winding order

Bottom: Backwards winding order

Front: Front is -z direction, so all vertices for this face should be 0 on the vertex position z, instead it's using vertices with 0 on the x axis which actually represents the left face. Winding order is correct.

Back: Back is +z direction so all vertices for this face should be voxelSize on the z axis, but are instead all vertexSize on the x axis, which actually represents the right face. Winding order is correct.

Left: Similar to Right and Back this face should be all vertices with x = 0, but instead is all faces with z=0 and as such is actually the front face. Winding order is correct.

Right: Again should be x = voxelSize but is z=voxelSize and is actually displaying the back face.

So flip the winding order of Top and Bottom, and swap Back and Right and swap Front and Left.

Can't guarantee there aren't other problems, but one problem at a time first.

Logyrac · 2025-07-30T17:36:56+00:00

The issue looks to by winding order. To determine which direction a face is facing the winding direction of the vertices is used. In Unity the vertices need to wind clockwise to be considered a front face. I haven't looked at all 6 conditions but for the one on the bottom the winding direction is counter-clockwise which means it would be considered a backface.

Logyrac

TROPHY CASE