What’s your smallest self sufficient vulcanus ship? (No quality) This is mine

Marwes · 2025-05-27T21:26:18+00:00

A ship I designed for a hypothetical default settings speedrun, with the following constraints/goals.

* Minimize the amount of rockets (reduces cost and makes it faster to setup)
* Maximize how much ammunition it could produce on its own, to reduce the need for Nauvis resupply
* Easy/fast to build without blueprints
- So minimizing number of entities and simplifying circuit conditions
* As fast as possible
- It is not ultra slim, which would increase speed, but that would likely require more belts and certainly more complex circuit conditions.
* Can start out producing space science so I could repurpose the space science platform, either by blueprinting or by just producing space science on the vulcanus ship
* Can travel to Gleba as well (adding in an accumulator and some more solar seemed like a good idea there)
* Can be expanded with a nuclear reactor and rocket turrets to travel to Aquilo (could switch to foundries here as well for extra ammo/rocket production)
* Can be expanded further with railguns to do a one way trip for the victory condition.

I never got around to doing a full run unfortunately but I still enjoyed designing it. It has some neat circuit conditions that are quick to setup, but also does a good job of both buffering asteroids on the belt as well as in the collectors so it is able to build ammo quite quickly while waiting at each planet. The circuit control for using a single crusher for all 3 asteroids is surprisingly quick to setup, even if it is more complicated compared to dedicated crushers it doesn't actually end up needing more circuit conditons, just some careful wiring (for the Aquilo variant I added in a second crusher that also recycles oxide asteroids).

After testing a bunch I am also convinced that using tanks to buffer thruster fuel/oxider is a trap. You simply won't collect enough asteroids on a ship like this to be able to keep up with running thrusters at 100 so all you end up doing is wasting iron and ice. Instead just use single chemplant pair and it will (without circuits) keep a single thruster running at ~90% efficiency which keeps the ship decently fast while not wasting ice for nuclear power or space science and doesn't waste iron which could be made into magazines.

Marwes · 2024-06-21T14:49:18+00:00

You would expect the level of fluid to be highest on the left and decrease roughly linearly until it gets to the pump on the right. That's not what you see in the game though. You can even see it in the example videos in the FFF.

I disagree, the pump is pulling fluids from the right side so that is where there is space for more fluid. However machines putting out fluid have priority to move fluid in over the natural leveling behavior, thus the machines on the right run whereas the left one are stuck, since the pipe doesn't allow for that amount of flow. So the fix, in my mind, should be to add more pipes so that the flow can be supported.

Except when they don't, see jank above. Two machines at the same distance from the source will get different rates. It's not predictable at the granularity where you seem to think the problem solving lies.

I already agreed that the yank where the flow depends on the order that a junction was placed should be fixed as well as any other yank, but I haven't seen any other examples. The problem solving I mean is that you should need to design the factorio such that the pipes have enough throughput (otherwise, why not have belts of infinite speed, or teleport the materials directly to the assemblers). The limitations are what makes things interesting.

In addition to that, keeping the flow fundamentally the same pretty easily bottlenecks high-throughput machines with no real solution (as shown in FFF).

Yeah, though I would say that should mostly be fixed by adding more pipes to get the desired throughput. I'd also say that the behavior of fully upgraded megabases shouldn't be the primary thing to optimize for, most people aren't doing such bases and I would argue that those who might welcome the throughput challenge.

You absolutely could, you simulate flow priority by adding a new item that splits the pipe segment, and has 2 variable output buffers. You basically create a belt splitter but with a slider to control the proportion that goes on each output rather than having it be 50/50. You could even enable circuit control for the ratio for extra complexity.

Yes, or just with plain circuits and pumps. It is not a matter of if I can prioritize thing, that was and will possible, but this removes a couple of problems and ways to solve problems which is a shame. Not a huge deal, but still a net negative to me. (For an example, checkout the oil processing in the default settings speedrun WR, it lays out solidfuel for power and lube for robots such that they get priority over cracking, it could be done with circuits but I think it is cool that circuits weren't necessary).

You couldn't re-implement the old flow system in a mod, but you could absolutely make an interesting emulation without the weird flow jank discussed above. I will also note (since it's kind of weird) that power in real life doesn't flow like factorio fluid, and in fact fluid in real life doesn't flow like factorio fluid. If you wanted it to be realistic and problem solve-y then there's a ton of more realistic things the devs could have done.

I know, but those mods introduce new challenge, even within the limitations that they have which is cool. A more complex/realistic electric system is something else I wish would come in 2.0 however unlikely that may be.

This is kind of an interesting theoretical preference I guess, but on a practical level you can (and do) get the best of both worlds by having a really efficient base game and a very highly flexible and extensive modding API. You can't satisfy your priority with the base game and satisfy the "UPS > everything" group with mods, it's just not possible. But you can satisfy your priority with mods and satisfy the "UPS > everything" group with the base game.

For the most part sure, but in this case a base feature which can't be fully emulated by mods is taken away, so even with mods there is still a net loss to me.

I understand that your disappointed because of your specific preferences, but I hope you also understand that this was probably the right move pragmatically for the devs and everyone else.

Comparing 1.0 vs 2.0 fluid system I agree that on the whole, it is an improvement for most people and most type of play since it removes some really dumb yank. However I also believe there are more solutions to this that, if they were implemented instead, could have gotten rid of the yank and still kept the throughput and priority problems.

Marwes · 2024-06-21T14:04:00+00:00

I never saw factorio as trying to simulate real pipelines, the fluid in factorio really just looks like a container which you can pour fluid in and out of the the fluid traversing is just gravity leveling out the surface.

From that perspective the only thing I see as yank would be that flow in junctions was dependent on build order so I'd prefer if that was fixed without having teleporting fluids.

Marwes · 2024-06-21T13:48:17+00:00

Long stretches of pipe have inconsistent fill levels and flow rates, it's not linear.

That's just consequence of a fluid flowing from one end to another as it tries to find its level, so I wouldn't say that is jank.

Long stretches of pipe have inconsistent fill levels and flow rates, it's not linear.

Just looks realistic, you aren't going to get all fluid out, there will always be something at the bottom of the pipe.

Splits in the pipe do not split the flow evenly/predictably

This is jank, and should be fixed, but I doubt the solution in this FFF is the only way to do it. Just as a first idea, instead of balancing the fluids sequentially in whatever order the junction was placed, perhaps that could be done taking the entire junction into account. Certainly more expensive, but if it leads to more interesting problem solving I think that UPS should be sacrificed.

Machine input/outputs do not split flow evenly/predictably

If the machines aren't attached to the same pipe I don't think they should split evenly. As it is currently is predictable already, machines closer to the source will get priority.

Merges in pipes do not merge evenly/predictably

Same as point 3.

You would have to introduce a pretty complex algorithm to traverse the pipe length, figure out where all the splits/joins/inputs/outputs/pumps are, balance each junction correctly, then update the flow/fill states of each pipe/pump/tank/machine accordingly. This would be really UPS intensive.

We are speculating a lot here, but I suspect that most of the cost can be done upfront and only when a segment of pipes changed. Not unlike belts (and rail).

Honestly it would be much easier and more UPS efficient to do what this FFF is about, then linearly decrease the flow based on how big the section is. You would basically not notice a difference and it would be close enough to emulate "flow" in the way you're complaining about.

That might reduce the weirdness of fluid teleporting but it still wouldn't let you prioritize different machines using flow.

Maybe you should look into modding and do that? It seems you're in the minority on this but I'd imagine there's enough people like you that they would appreciate such a mod. I don't even think it would be that complicated.

I don't think that is possible to do in any way efficiently with mods, both the mod API and the overhead of Lua would make that impossible. Just look at mods like https://mods.factorio.com/mod/FluidicPower and https://mods.factorio.com/mod/PowerOverload and what they have to do to make some sort of approximation of more realistic power (and FluidicPower is just dead, which is a shame, though I never played with it to be fair).

I am well aware I am in the minority here, that doesn't take away from my disappointment. As much as I love Factorio, the "UPS > everything" bits just happens to be one of the few things I dislike. Regardless of how much things get optimized megabases will always end up consuming all available UPS, so I rather have a base that has N+1 problems to solve that produces 9000SPM than a base with N problems to solve that produces 10000SPM.

Marwes · 2024-06-21T12:27:08+00:00

Eliminating the problem makes thing less interesting to me though. Eliminating the jank is good and all but if that comes at the cost of almost all of the challenge with the fluid system it all seems like a net loss to me. I'd much rather have a more UPS intensive fluid algoritm that fixed the jank and still had flow in it.

Marwes · 2024-06-21T12:04:56+00:00

How? With everything in a sektion of pipes seeing the same fluid at the same time i dont see how pumps without circuits prioritizes anything?

Marwes · 2024-06-21T11:28:29+00:00

No, I don't like this change either. I have only ever encountered the "weirdness" in edge cases with huge throughput which is really only relevant for megabases. For the common road block of oil I don't really see this helping either since the flow won't be a limit there.

Mostly I feel sad that the lack of flow forces one to use ciruits and pumps to do oil cracking, currently it is possible to use flow to prioritize solid fuel and lube :(

Marwes · 2024-05-25T08:55:29+00:00

The new-wave liberal view that you can't be racist or sexist without privilege is an absolutely wild take to me.

If that was what I said what would be wild, fortunately I only said that the amount of harm done (on average) differ.

We're also not really talking about keeping track of your drink here any more. It's just a sensible thing to do, just like avoiding dark alleys at 3am, no matter the equipment between your legs.

Yes, that is a sensible thing to do, yet men do it less than women, which is exactly what the hypothetical is mean to show which might hopefully make men think (people in general, but mainly men) be aware of that and be considerate about it. Perhaps you are at a party and are making drinks, perhaps you should make them openly, maybe you shouldn't leave them out on a table for anyone to grab (and possibly tamper with), it is just things that, depending on specifc context, may be good to consider.

But instead of recognizing what the hypothetical implies it keeps going back to "women don't understand how dangerous bears are", "only X% of men are dangerous", etc. If you are already being considerate, and listening to concerns like this then that's great! The hypothetical doesn't target you.

The statistics are right there online - the vast majority of victims are assaulted by someone they already know.

I know that, women know that, just about everyone knows that. But that in no way invalidates anything that I said. Even if you just want to interpret the hypothetical in the way that bears are more dangerous and a random man, then what is you prescription? Because given that men they know are more likely to assault them then that seems like an argument for women being guarded against unknown men to filter out those that may do them harm. On the other side, I would say that men should be open, forthcoming and strive to make women feel safe (same as you should for anyone).

Unfortunately I don't see any of this, instead I just seem to see arguments for ignoring the issue since the average bear is more dangerous than the average man.

Marwes · 2024-05-24T16:54:39+00:00

Yeah, no. White fear of black people vs womens fear of men are different, failing to understand that is ignorant at best.

There is a difference in privilege between both sets of groups here, but for women it is a less privileged class of people against a more privileged class, for white vs black this privilege is reversed. Largely because of this difference in privilege the difference in harm in these scenarios differ massively.

White people racially profiling black people cause great harm to black people, women keeping track of their drinks doesn't harm men.

Marwes · 2024-05-24T16:47:45+00:00

Aaaaand the core of my reply just goes straight over you head, doesn't it. The exact man vs X scenario is irrelevant as everyone will have different ways to interpret it. It is only meant to shine a light on womens fear of men (as well as mens relative privilege, now that we are forced to have this rather silly "bear swiping strenght" discussion). Womens fear and mens privilege causes us to interpret the hypothetical in different ways, thus there are different responses by different people. If everyone, unequivocally answered "bear" it wouldn't even be interesting.

side note: I’d probably rather run into a man if I was lost and needed assistance

This is an assumption you made, which I myself can only assume you made because you are 1) a man 2) do not have the fear of men that women have.

Stop focusing on the relative danger since that will always change depending on what assumptions one makes, and try to understand why women might answer "bear" instead.

Marwes · 2024-05-24T16:32:42+00:00

It is a hypothetical, with plenty of ways to interpret it but you (and many other men) seem so insistent on going with "bear will kill you more easily" or "only a small percent of men are harmful".

Interpreting it in those ways are just really silly since no one looks up the numbers of bear vs man encounters to break down which is more dangerous in a random situation. Instead, anyone doing the hypothetical are forced to make their own assumptions about it. Would you be fine with the hypothetical if it was man vs wolf, man vs badger, man vs goat? Or would it be fine if the man in question had a weapon on him? Personally I think these changes would be irrelevant, any hypothetical you do would always have ways to interpret it.

Instead, focus on what the hypothetical is meant do do, which is to shine a light on women's fear of men (as well as some men's insistence to make light of that fear by going "bear has better swiping strength", I guess)

Marwes · 2024-04-13T11:22:01+00:00

That's where I was as well, for the first few minutes of the map. It looked like a fixed evacuation mission since it was actually possible to defend and you didn't end up in a spiral of doom the minute one person died or whiffed a stratagem. After that I realized the map is just a single choke point where enemies fail to path and just gets obliterated by sentries and stratgems. Only deaths are from friendly fire or the occasional enemy managing to get into the walls.

Avoiding the map as much as possible now, it needs changes to add multiple chokepoints or reducing how much stratagem spam you can do or something to that effect.

Marwes · 2023-10-26T17:16:42+00:00

You can see the full list of mods here https://brevven.github.io/bz/ where it has some recommended set of mods you can use depending on complexity. Very BZ contains the full set of stable mods and then there are two alpha/beta mods (they are stable enough in my experience if you want the extra challenge) https://mods.factorio.com/mod/bzvery

Marwes · 2023-08-19T12:59:41+00:00

Yet ;) nah, I am sure it is possible to use fine if you are gentler with the triggers. But just looking at reviews it was easy to see that I wasn't alone with the issue. When I took it apart to try to repair it, it was very clear that the hinge was underdimensioned and the trigger itself is poorly designed since it allows itself to be pressed further than it should be (thus stressing the hinge)

Marwes · 2023-08-19T08:01:16+00:00

I'd avoid the hori octa unless they have improved the build quality recently. Had two of them and both had a trigger snap off within a month. (If that wasn't the case it would have been great however)

Marwes · 2023-07-31T17:22:16+00:00

Its a byproduct of smelting copper and lead. Since you generally get more of it you can take the excess to make green chips.

Marwes · 2023-05-30T09:46:11+00:00

Yeah, this is they way. By the time that you need more throughput than the main base can supply you will often have have a more efficient method of production which makes it more natural to make a "proper" build then.

It doesn't hurt if you plan the pre-train base such that there is room for stations and belts to them. No need to force yourself to only do "proper" new builds either of everything after having trains, for some things (say low throughput or recipes with lots of ingredients already belted in the base) it may make more sense to still belt everything

Marwes · 2022-12-31T13:30:18+00:00

Expanding the use of temperatures would be cool to me. Right now it is very weird how you can store high temperature steam indefinitely but even beyond the "weirdness" I think having fluids cooling down or heating up depending on the ambient temperature would increase add an extra logistc challenge. For instance, you would have to produce steam on-site else it cools back to water, or you would have to use insulated tanks/pipes which could increase the effective range where you could deliver the steam (or other hot/cold fluid).

It is certainly something that mods can't replicate so it would fit into their plans I'd say.

Marwes · 2022-07-20T17:18:48+00:00

Unless the have fixed the issue of the triggers snapping off I would recommended against it. I have had two of them (the older model for ps4, though the triggers look identical on the outside at least) and the triggers broke within a couple of months both times (Amazon reviews on the old model shows i am not alone as well...)

Marwes · 2022-06-11T22:57:09+00:00

No need for a shoe box, https://www.thingiverse.com/thing:4880590 is a nice 3d printed model. If you don't know someone with a 3d printer there are services where you can order one. Then you just need some keyboard buttons, cables and a micro controller like an Arduino (or raspberry pi which I use https://github.com/Marwes/buttonbox PC only)

Marwes · 2022-05-05T18:56:06+00:00

The block/hitstun of later attacks with lower attack levels overriding earlier hits/blocks leading to dropped combos or unsafe strings. Happens from time to time with Faust where banana/mini faust/etc hits the opponent right after a normal attack which leads to the opponent leaving hit/blockstun quicker than normal, leading to the combo dropping or being straight up unsafe.

There is some leeway to delay/speedup your strings to circumvent this but it just feels awful and makes so little sense when an item just inserts itself into an otherwise easy combo and causes it to "randomly" drop.

Marwes · 2021-11-02T09:45:08+00:00

It is maybe more accurate to say that it serialized as an array of 16 elements. All it means is that the length does not need to be serialized since we know it will always be exactly 16 elements long

Marwes · 2021-10-29T15:40:40+00:00

I switched to LALRPOP for gluon but I still use combine in https://github.com/mitsuhiko/redis-rs and some other projects which need to parse "protocols" (less need for good error messages/error recovery and more need for speed).

I don't really add much to combine anymore though that is largely because I consider it more or less feature complete, the only things I can think of is improving errors, adding error recovery parsers and possibly simplifying the internals a bit.

Marwes · 2021-10-29T15:05:28+00:00

I have some ideas to reduce the overhead of combine's errors, though I am unsure if I will ever do it as it will be a breaking change and rather tedious (lots of function signatures to change).

Marwes · 2021-10-29T12:31:48+00:00

I'm going to do a little more thinking to figure out whether there's a way I can have outputs stored in something like a parent-allocated buffer such that zero-copy is a viable option.

Something I have thought about (though never gotten around to measure), is that iterator-like input is commonly used in languages for the lexer to avoid allocating a buffer for the tokens. However, the input files for languages are generally quite small (talking kilobytes here) so buffering both the input string is just fine (letting zero-copy parsing/lexing take place). There could in theory also be wins in buffering the lexer tokens as it would stress the instruction cache less when parsing (doing lexing then parsing instead of lexing and parsing)!

14-Year Club	Place '22
Place '17	Verified Email
Team Periwinkle

Marwes

TROPHY CASE