• 47 Posts
  • 190 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle



  • 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.











  • 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.











  • The biggest hole in WASM right now is being able to DO anything really useful in it, natively. The only thing you can do natively right now is use the CPU. Can’t manipulate the DOM. Can’t access local storage or cookies or networking APIs, etc. You can call out to arbitrary JS code, but that’s it.

    This is great for some of the big JS libraries that have very CPU-heavy workloads they can optimize in WASM and call to from JS. Like frequently parsing and re-parsing HTML. Or doing game physics calculations.

    I haven’t heard word one about WHEN any of this will be available. Which is particularly troubling, given how long people have been begging for it.

    Of course, none of this stops you from using WASM in the real world, to do quite a lot of things. You’re just gonna have to deal with JS interop, still, do do anything really useful.






  • A quality apology consists of 3 things:

    • An explanation of what you did that was wrong, and why it was wrong
    • An explanation of what you’re going to try and change about yourself, to avoid the same mistake
    • An expression of remose. I.E. the word “sorry” or “apologize”.

    Your proposed apology has all those elements, so you’re already ahead of most folks. But there are a few suggestions for improvement in this thread that I think are also good.

    “if you felt so, I apologize”: I don’t read this as you apologizing for how the other person feels, since you clarified that earlier. But I think it’s fair that others might read it that way, so you’re better off eliminating the ambiguity. You’re apologizing for what you did, without considering that others might (validly) consider it inappropriate.

    “I’ll try to control myself around you”: similar deal, it should be clear that this is about you, not them. And when it comes to swearing in a workplace, it’s pretty-darn common to consider it inappropriate and unprofessional, no matter who you’re around. Maybe part of your apology needs to focus on how the behavior is unprofessional, and you simply needed help recognizing that, as you’re (possibly?) new to the professional working world.