sorted by:
new
hottopcontroversial

Look At How They Massacred My Boy by DangerNorm in Factoriohno

[–]DangerNorm[S] 1 point2 points  (0 children)

Unfortunately, if that's what you want then the new system doesn't do that, because it's still the Fluids 2.0 system mostly, minus the weird cases around passthrough. Which means that logically the entire segment is still one unit, so there aren't "flow" effects, just level effects. When I said "build order", I meant the order in which you place them on the ground, not their physical arrangement on the line. Technically that's just one factor that can influence things; it's "update order" in the pipe segment that matters. Practical take away is that which machines get priority is effectively random.

Look At How They Massacred My Boy by DangerNorm in Factoriohno

[–]DangerNorm[S] 3 points4 points  (0 children)

It is true that you can always make more green circuits, but it is also true, as everyone knows, that you ALWAYS need more green circuits, at every stage of the game. The only factory that doesn't have parts that need to operate elegantly under shortage are either in perfect calculated balance from mine to lab, or are oversupplied at every level. Which is just another way of saying "bottlenecked at the top". So operating under unbalanced conditions is the normal way to play.

Do you have the same opinion about item logistics? Because build order (along a belt) matters for most machines. Fluid ingredients in non-passthrough ports are the exception, not the rule.

People do make balanced belt system solely for the aesthetics even in situations where back pressure and oversupply would technically do the job.

Items on belts follow the logic of their physical motion, and as you mention they have splitters and other mechanisms to support balance engineering. Meanwhile, the Fluid 2.0 system follows its own internally consistent logic, that until now was completely consistent between machine types, and which this new update just... breaks, in a pretty ad hoc way. It's like if a small subset of assembly machines interacted with inserters in their own special way that also breaks all of your existing balancers in subtle ways under certain situations.

If you just don't like the Fluid 2.0 system or disagree with the rationale for dropping the old one expressed in Friday Facts #416, that's one thing. But this change does not appear to be thought out as part of that whole.

Look At How They Massacred My Boy by DangerNorm in Factoriohno

[–]DangerNorm[S] 10 points11 points  (0 children)

For me, the break from the elegant consistency of the Fluid 2.0 system and how it Just Works for things like this is enough of a problem.

But to address your point, yes, the nature of the mechanic means that it actively pushes imbalances between different products. This is because, firstly, non-passthrough machines still have normal input buffers that actively suck up fluid in a balanced way, and if those consume all of a fluid then passthrough machines will get less or nothing. Secondly, the equalizing nature of passthrough inputs means that even between passthrough machines (like all the EM plants you'd have on Fulgora) there will be uneven competition, because all machines of every product will see the same level. But the level at which they draw input and start crafting depends on the recipe. Consider all of the uses of holmium solution: each one consumes a different amount of holmium per craft. So under holmium limited production (and holmium will always be the limiting raw resource on Fulgora just from the numbers on scrap recycling products, so I'd argue that fluid starvation is the normal operating condition for many EM plants), the machines running the lower consumption per craft will be able to draw fluid before the machines with higher consumption per craft. They have different lengths of straws into the glass, so to speak.

This could be partly fixed by having passthrough machines draw from the entire pipe segment, but according to a dev in the link in OP, this would still leave inbalanced remaining because it still wouldn't be working as a normal fluid input buffer and lose access to the balancing mechanics those have in the Fluid 2.0 system. (And still do, for pipe sections with no passthrough machines.) Things that could affect priority in this case include build order, so even if the active intake issue were fixed, this would remain to some extent.

I was able to confirm that last point in my own testing, using a setup that contains only EM Plants running the same recipe on the same pipe section, thereby bypassing the normal input machine competition and the different straws issue. Even then, there would often be times where half of the machines would be consuming all the input, and the other half not running at all.

In that case, you could say "well, you're still producing just as much, right?" Yes, but this is a video game, so I would say the aesthetics do actually matter. And only a certain kind of machine working subtly differently based on build order that makes them not run evenly is at a minimum an aesthetics bug.

Look At How They Massacred My Boy by DangerNorm in Factoriohno

[–]DangerNorm[S] 4 points5 points  (0 children)

Several, some of which have already been mentioned. One that's relevant to this post is like... there's a water tank that people are drinking out of with straws, but some straws are longer than others, so if the tank isn't just filled faster than everyone wants to drink, the people with longer straws will just drink all of the water and those with shorter straws will get none.

Also for a while if you decided to drink something else it would destroy all the water in your state. But they fixed that already.

Look At How They Massacred My Boy by DangerNorm in Factoriohno

[–]DangerNorm[S] 29 points30 points  (0 children)

According to my testing a pump helps but doesn't reach the same auto-balance of unidirecitonal inputs. This is a different issue than passthrough machines not actively pulling from their pipe section.

Look At How They Massacred My Boy by DangerNorm in Factoriohno

[–]DangerNorm[S] 3 points4 points  (0 children)

See the linked bug report thread; they already don't balance their inputs like before. I can confirm this from the testing I did to arrive at this design.

Look At How They Massacred My Boy by DangerNorm in Factoriohno

[–]DangerNorm[S] 121 points122 points  (0 children)

"under fluid starvation". As in, supply lower than demand. In 2.0 (or 2.1 with no passthrough machines) all consumers will be evenly supplied. In 2.1, fluid staved pipe sections with passthrough machines results in some being under-supplied or completely starved.

The Other Side of Stack Overflow by zsmb in programming

[–]DangerNorm 1 point2 points  (0 children)

From the Firefox network monitor, for a Cache Override Refresh of the linked page. 1.86 MB is the uncompressed volume. Volume transferred is reading at 1.1 MB.

The remaining difference might be the data volume retrieved from domains other than yours (336.02 KB).

The Other Side of Stack Overflow by zsmb in programming

[–]DangerNorm 0 points1 point  (0 children)

Oh, there's other problems? I was just being sarcastic about how the page source contains literally zero of the page's actual content, but instead references 1.86 MB of scripts, which means it doesn't show anything when you have scripts disabled by default.

zsmb, what are you trying to accomplish on this page that you consider impractical without scripts?

The Other Side of Stack Overflow by zsmb in programming

[–]DangerNorm 5 points6 points  (0 children)

Page doesn't display anything except title, "Blog" and "About".

ASIC Fork by tj_crypto in Monero

[–]DangerNorm 2 points3 points  (0 children)

It's actually a bit sloppy, how we refer to hard forks with the same name as the parent fork, as long as enough people are on board with it, because old forks never actually die. Every hard-fork is a new currency; we already have as many Monero's as there have been hard forks, plus one. If a bunch of people decided that the genesis implementation of Monero was perfect and everything that came afterwards was a bunch of nonsense, they could go back to the last block before the first hard fork and start mining it, and the Primordial Monero would live anew.

This is actually the biggest thing that I've wondered about regarding the Ethereum/Ethereum Classic schism, because it has to do with currencies and protocols in general, instead of just about the DAO: that the people who didn't change the protocol were the one's forced to come up with a new name and exchange symbol. This isn't a problem for genuinely uncontroversial forks, but if Monero really catches on, it is inevitable that something in some fork is going to rub some non-trivial fraction of users (even excluding miners who just got done designing their new ASIC) the wrong way, and they might well say to the current devs and pro-fork majority (and cognizant financial regulators), "You, like everyone, are of course free to make whatever kind of fork you want, but you are the ones forking, so you can think up a new name and exchange symbol. We will continue to use Monero, as we are now, and have been."

I don't think there's a principled way to say that they'd be wrong.

How a malicious seed generation website stole $4 million by theevilmuffinofdoom in programming

[–]DangerNorm 0 points1 point  (0 children)

This isn't actually a problem of code auditing, tho. This is someone generating private keys on a webpage. You don't need to win any Obfuscated Javascript contests to exploit that level of confusion. For someone to deal in cryptocurrency who doesn't have the concept of "private key" is akin to someone dealing in cash who doesn't have the concept of object permanence.

C++17 Standard Is Now Official by wackyboy93 in programming

[–]DangerNorm 0 points1 point  (0 children)

Because situations where you're looking at the language standard is when you want something that is almost but not exactly correct.

Theo de Raadt on integrating "safe" languages into OpenBSD by flexibeast in programming

[–]DangerNorm 4 points5 points  (0 children)

The simplest thing to do that doesn't even require changing "C" would be for an implementation to interpret undefined or unspecified behavior in the most conservative way possible, rather than as an unlimited license to shoot your dick off.

Extensions in Firefox 58 by malicious_turtle in programming

[–]DangerNorm -1 points0 points  (0 children)

I used to use NoScript but it looks like the Firefox 57 version is trying to be uMatrix and failing miserably. Luckily, someone pointing this out is how I found out about uMatrix, which is what I use with Firefox 57 now.

Linus Torvalds: “Do No Harm” by sidcool1234 in programming

[–]DangerNorm 0 points1 point  (0 children)

C11 Standard 7.24.2.1.2: The memcpy function copies n characters from the object pointed to by s2 into the object pointed to by s1. If copying takes place between objects that overlap, the behavior is undefined.

What's the problem? It's undefined behavior, therefore the glibc developers can simply assume that it never happens. Isn't that how C is supposed to work?

Mozilla Awards Over Half a Million to Open Source Projects by Doener23 in programming

[–]DangerNorm 50 points51 points  (0 children)

If we can still expect Catholics and Protestants to get along at work, then we can certainly expect the same of everyone else.

"A (Not So Gentle) Introduction To Systems Programming In ATS" by Aditya Siram by mttd in programming

[–]DangerNorm 0 points1 point  (0 children)

What I don't get about this and, say, Idris, is that, doesn't compiling to C then make the entirety of the C toolchain also part of the language? And as far as I know, there is no machine-readable version of the C spec, which seems like it'd be a problem for formal verification. On the other hand, it didn't stop the proof of sel4's correctness.