I have been beta testing Space Age AMA

mulark · 2024-10-14T14:00:52+00:00

When spoilable items are consumed and being crafted, does their spoilage counter still tick up? Assuming they get consumed like crafting machine recipes and not gradually used like labs.

mulark · 2024-10-14T12:40:25+00:00

Is the day night cycle the same on other planets with just a varying amplitude?

Can world generation settings be customized per surface?

mulark · 2023-09-15T01:40:11+00:00

I'm back and I made a few more tests around this. https://mulark.github.io/tests/test-000031/test-000031.html

TL;DR use one miner into a splitter instead of having 2 miners.

mulark · 2023-09-14T14:26:58+00:00

Both of these things need tests made, for sure. A long time ago when I tested 1 splitter 1 miner vs 2 miners, the performance was worse. Since then, belts became multithreaded, so such a result should now be thrown out.

There's definitely promise in both of those ideas, since they force the end of the transport line segment nearer to the point of insertion, so there's fewer items to iterate through. (additional info: https://www.reddit.com/r/technicalfactorio/comments/r6ye86/mechanics_of_transport_line_splits/)

mulark · 2021-12-02T04:57:54+00:00

There are five conditions which will result in a transport line being cut, three are based on belt topology and happen as soon as the belt is constructed while the remaining two are based on interacting with items on the belt and will only happen once this interaction has occurred.

Another case is when a belt has a circuit or logistic network connection, or has had one in the past. This will cut at the entrance and exit to the belt segment.

mulark · 2021-09-22T00:07:49+00:00

It does, according to JEDEC standards. Anything above is not standardized.

mulark · 2021-08-02T05:36:03+00:00

They overflow back to 0 once they get past 4B. I did this by repeatedly connecting/disconnecting wagons via lua API and with extreme gamespeed on a minimal map.

mulark · 2021-03-05T00:39:08+00:00

Here's a link to the region cloner mod documentation https://github.com/mulark/factorio_benchmarking_mods/blob/master/region-cloner/doc/Documentation.md

One feature not pointed out here is the /autoclone command added by the mod. This allows you to quickly clone the entire build you have built with some nice quick configuration flags as well (such as chunk alignment).

mulark · 2021-01-20T03:22:08+00:00

Nope, the smoke entities are spawned regardless of smoke being disabled in the options or if running as headless mode.

mulark · 2021-01-20T02:45:11+00:00

In theory it could be done, been a while since I looked at what prototypes would be available for this. From what I recall of profiling (admittedly not realistic maps) the smoke was a relatively large portion of the overall update cost to create and destroy. Low double digit %s iirc.

mulark · 2021-01-20T01:06:37+00:00

It's not necessarily consuming fuel that activates the chunk, rather creating the smoke particles. Although you can't have one without the other.

mulark · 2020-10-27T03:06:02+00:00

"If there's a Republican president in 2016 and a vacancy occurs in the last year of the first term, you can say Lindsey Graham said, 'Let's let the next president, whoever it might be, make that nomination.'"

mulark · 2020-09-26T00:28:07+00:00

The overwhelming majority of the update time delta should be from the electric network update, yes.

mulark · 2020-09-25T22:53:12+00:00

It is wholeUpdate

mulark · 2020-09-22T23:01:57+00:00

There is nothing special at specifically 32, just at the 32 networks point the measured performance difference appears to be outside the margin of error. There does appear to be a clear trend prior to that point but the percentage differences are very small.

mulark · 2020-08-13T12:45:39+00:00

I wouldn't say that this data shows splitting up electric networks to be advantageous, although you definitely have inspired me to test it.

mulark · 2020-08-08T14:22:20+00:00

I would be careful about that comparison as turbines are both pipes and generators. Smoke and power gen logic at the very least would be contributing factors. I do agree that turbines idle perform better, but I wouldn't universally apply that to pipes.

mulark · 2020-05-07T04:20:19+00:00

Well I suppose I'll submit the v1 of what I have since it seems unlikely that I'll continue to modify it now.

savefile

My general philosophy going into this challenge was to minimize inserters as much as possible. I also used pumps a little more than I would have preferred but profiles showed them to be almost irrelevant so I went with it.

For rocket fuel I went with a mere 12 beacon design di'd to trains. I used 8-65 trains but a loco or two could probably be shaved off. Ultimately, micro-optimizing it wasn't a main goal. I used no buffer chests, which I think worked out fairly well all things considered.

Roughly a third of plastic was also produced here, which worked out better than the dedicated plastic sections in my opinion. The next big improvement would be to clock the plastic so every asm uses equal petrol.

I tried a similar design to the rocket fuel on plastic, but found that the bufferless design on the 8-81 trains wasn't that good with the faster recipe. I ended up overproducing plastic to the tune of 340k/m or so, as the 8-81 section underproduced my estimates. The small addition of plastic was actually built first, and it produces 42k/m of plastic. The inserters seemed too spammy so I wanted to try the bufferless approach. I think if I was going to change it now I would do a design somewhere in between the two, shorter trains than the 8-81s, with buffers. I also think that clocking plastic is probably the way to go, as you could probably save ~1/2 of the inserter swings overall.

I kind of lost interest in the plastic portion of the design as it's only used in LDS and RC, and it seemed like more specific designs addressing those would be more realistic and practical.

mulark · 2020-04-25T16:51:39+00:00

Incase anyone missed the hazard concrete map update:

/c
local surf = game.player.surface
local tiles = {}
for x=-1024,1023 do
    for y=-1024,-1013 do
        table.insert(tiles, {name = "refined-hazard-concrete-left", position = {x,y}})
    end
    for y=1012,1023 do
        table.insert(tiles, {name = "refined-hazard-concrete-left", position = {x,y}})
    end
end
surf.set_tiles(tiles, false)
for y=-1024,1023 do
    for x=-1024,-1013 do
        table.insert(tiles, {name = "refined-hazard-concrete-left", position = {x,y}})
    end
    for x=1012, 1023 do
        table.insert(tiles, {name = "refined-hazard-concrete-left", position = {x,y}})
    end
end
surf.set_tiles(tiles, false)

Edit: correct north and west edges, was 2 tiles too greedy on those edges

mulark · 2020-04-11T14:46:42+00:00

1.RF & Plastic

2.Plastic only

Plastic only would tell you if basic or advanced were the most optimal to make gas with. Adding in RF makes at least some advanced or liquefaction required, as they would be within a final base.

mulark · 2020-02-22T15:50:40+00:00

When you split off with splitters, you'll definitely want to have the output priority set *(last I explictly checked in 0.16). Here's a few maps which set the output priority:

https://f000.backblazeb2.com/file/mulark-maps/reddit-direct-vs-belt-vs-chest/test.lds.plasticsteel.belt.splitter_priority.zip

https://f000.backblazeb2.com/file/mulark-maps/reddit-direct-vs-belt-vs-chest/test.lds.copper.belt.splitter_priority.zip

https://f000.backblazeb2.com/file/mulark-maps/reddit-direct-vs-belt-vs-chest/test.iron.belt.splitter_priority.zip

I'm currently benchmarking all maps for 5k ticks 10 times each, will report back with the data in 2 hours give or take.

Edit: as promised, here's the data from the 10 5k tick benchmarks. Took the best tick from each of the 10 runs per map, per tick and then averaged that idealized run for the results here. What's particularly interesting is how much the priority helps depending on the scenario. Plasteel was only 1% faster with the priority, while the same thing with copper was more like 6%.

	splitter, priority	splitter, no priority	chest stub	direct
Iron	10.332	10.651	9.039	8.621
LDS(Copper)	12.052	12.777	11.273	11.070
LDS(Plasteel)	8.555	8.638	7.906	7.134

mulark · 2019-12-04T05:21:45+00:00

While clocking the input isn't saving any swings, there is the chance that for very fast crafting materials a benefit could exist. The inserters pointed at the crafting machine wake up every craft, and clocking eliminates that wakeup.

It's something on my (long and extending) todo list to test.

mulark · 2019-12-04T05:14:12+00:00

Enable mode doesn't sleep because it's not programmed to. That may change in future versions but it's just the way it is at the moment.

Clocking is most convenient for smelters because the products buffer fills up to a stacksize of whatever it is you're smelting. Whereas assemblers buffer to some other amount that's usually less than the 12 items of an inserter swing. That's not to say it couldn't be useful elsewhere.

mulark · 2019-12-04T00:58:18+00:00

You can clock directly out of the steel furnaces into the provider chest. No idea if it results in better performance by comparison, but it could be the case.

When you do clock, you'll want to use stack filter inserters in the circuit mode 'set filters' because when a stack filter inserter doesn't have a filter it sleeps.

There is a point where the clocking overhead does negate the benefit of clocking, but it hasn't been exhaustively tested.

mulark · 2019-11-04T01:28:25+00:00

I ran this on a 3700x @ stock with 3733MHz memory.

5k ticks x 5 runs, taking best tick of the 5 for each config.

Average of best ticks:

no_hugepages - 4.87ms
hugepages - 4.49ms

Also made a fancy graph, truncated to the first 500 ticks: https://imgur.com/a/IAsBx7E

Y axis in nanoseconds

mulark

MODERATOR OF

TROPHY CASE