JakenVeina

Someone needs a lesson in contrast.

TL;DR, I would do the following:

• Build a a 3->2 balancer across those 3 belts on the left. These 2 outputs, together, will be your feed of 2000.
• Split a belt off of each of the other 4, and merge them together.
• Split that into 2, and merge each of those into one of the 2 belts of the 2000 line.

The long version:

In my experience (and this may well be a product of my build style, and may bot quite be applicable to you) belt balancing is not an issue that needs to be addressed. Belt capacity and throttling leads naturally to self-balancing.

Example: in the Steelworks build I did recently, I had two different sets of machines needing to consume Steel Ingot: Constructors for Steel Pipe and Constructors for Steel Beam. Currently, the factory is clocked for a max belt of Mk1, since I can't really afford the power for more, right now. My foundries produce 90 Steel Ingot/min, so that means I need 2 belts worth of Steel Ingot transport. I ended up building 12 Foundries, in 2 groups of 6, each outputting to a separate Mk1 manifold, so I've got 2 belts of 45/min each.

On the consumption side, I need 21.068/min to make Steel Pipe and 68.932/min to make Steel Beam. So, I still need 2 belts of bandwidth for Steel Beam, but only 1 for Steel Pipe. To make this happen, I split each of the Steel Ingot lines into 2, let 1 from each split go onward to Steel Beam, and took the other from each split and merged them, for Steel Pipe. All dumb splitters.

Now, you might say "well, that just gives you 45/min going to both Steel Pipe and Steel Beam, you just made it that the two separate Foundry lines can now mix. But this doesn't account for (what I call) "back-pressure".

The magic of back-pressure is that it makes dumb splitting (splitting evenly, instead of with ratios) irrelevant. With my setup, the Steel Pipe constructors only need 21.068/min but are getting 45/min. However, as long as the clock rates are set correctly on those machines, they will only consume 21.068/min, and the extra 23.932/min will eventually back up, and flow over to Steel Beam anyway.

Essentially, it's the balancer vs manifold debate. Upside is, you don't have to deal with crazy balancing calculations, when you've got odd ratios like you have. Downside is, the system doesn't reach full efficiency until it "primes" up all the back-pressure.

The one caveat to back-pressure is if you have "re-combination" farther down the line. In my example, if I were going to take those Steel Beams and Steel Pipes and combine them together in some other recipe, then it might be impossible to build up enough back-pressure to balance everything out. Sort of like having an air-bubble in the system. You can solve this by either manually priming the back-pressure, or just swapping to a Smart Splitter with an Overflow output, in the right spot, to allow the "bubble" to bleed out.

Nope, no trains in this playthrough. Everything forbthis facility is mined one-site.

It does indeed do something! ;)

What graphics API are you using? DX11? DX12? Vulcan? I suspect maybe this affects which file is applicable? I'm actually running DX11asba workaround to a crashing issue that came up in 1.0, and doesn't seem to be fixed yet.

If there's no Engine.ini file in /Windows, I'd say you're safe to just create one, and see if that works. If the file's there, but empty, that really shouldn't matter, just drop the settings in there.

Even if they do, it's still a win for Musk. He got what he wanted out of the deal. He got the ability to rewrite the feed algorithms as he saw fit, and steer a large portion of online public discourse towards getting Trump re-elected. Tough to say how much of a factor this was, but it definitely contributed. The money he lost on Twitter, he'll make back.

We all laughed at him for setting the platform on a course of destruction, and that may yet still happen, but he got the last laugh out of it. Props to him, I guess.

If only it were that easy to snap your fingers and magically transform your code base from C to Rust. Spoiler alert: It's not.

How utterly disingenuous. That's not what the CISA recommendation says, at all.

That’s the first blocky build I caught you doing, ha!

Hey, now, it's still a work-in-progress. ;)

Sooooo, you can "fix" this, you just have to get into the weeds of Unreal Engine a bit.

Firstly, of course, you have to have Lumen enabled, which is a normal setting in the Graphics section (or whatever it's called) of the game menu.

However, to get the illumination to be actually meaningful, like it used to be, you need to change an engine setting to increase the illumination radius. THEN you need to adjust a bunch of other engine settings to get rid of the terrible graininess that generates. Or, more accurately, tone it way down.

Gimme a minute to go look up the settings I'm running with...

EDIT:

So, here's the settings I'm running with. I got this set in particular out of a reddit thread. Out of a handful of different sets I tried, this is the one that worked the best, for me.

r.Lumen.Reflections.Allow=1
r.Lumen.Reflections.SmoothBias=0.8
r.Lumen.ScreenProbeGather.TracingOctahedronResolution=10
r.AOGlobalDistanceField.MinMeshSDFRadius=10
r.LumenScene.SurfaceCache.CardTexelDensityScale=2500
r.SupportReversedIndexBuffers=1
FX.BatchAsync=1
r.OneFrameThreadLag=0
r.Lumen.TraceMeshSDFs=1
r.LumenScene.SurfaceCache.CardMaxTexelDensity=0.5
r.Lumen.DiffuseIndirect.SSAO=1

The important one is r.AOGlobalDistanceField.MinMeshSDFRadius that's what drives the brightness. The rest, feel free to play with, until you find a combination that works.

To apply these settings, you can do one of two things.

A) use the in-game console, triggered with the "" (back-tick) key. In the console, you change one of these settings by typing the name, a space, and then the desired value, I.E. r.AOGlobalDistanceField.MinMeshSDFRadius 10`. These changes aren't saved, so you'll lose them when restarting the game, but it does enable quicker testing. Although, they ALSO don't take effect right away. Only "new" renders will use the settings, stuff that's already rendered will stay the same. I.E. you have to walk a decent bit away from the thing you're wanting to look at, then back.

B) Head to %localappdata%/FactoryGame/Saved/Config/WindowsNoEditor/Editor.ini and paste the settings in at the end of the file, after adding the line "[SystemSettings]". Within the .ini file, the format for a setting is different, instead of a space between the name and value, you use an =, like I have above. There's also an Engine.ini file within a Windows folder, instead of WindowsNoEditor and I honestly have no idea which one serves which purpose, so I just made the edits in both.

As if the new notepad wasn't already enough of a downgrade.

I dunno, I still think this is on YT. There's a reason it's stupid easy to bypass geolocked content on basically any other platform, and it's because of what you say: the platforms don't actually care. They BENEFIT from having more content to give you. YouTube is making a distinct effort to go detect geolock bypassing here, where other platforms choose not to.

If I had to guess, it's really that they want to discourage VPNs entirely, as it fucks with their primary business of data collection.

It actually took me multiple trues to get into Stardew. The whole "track down everyone" quest is intimidating for a lot of people.

Up to you if you think it's worth keeping at it, for the possibility of getting hooked later.