"Global Variables" (was: Inserter Stack Size Circuit Signal)

[golfmiketango]

Sometimes (for example when implementing the Madzuri Smart Train Loader everyone's been buzzing about lately) we encounter good reasons to supply the inserter stack-size as an input, i.e., to a combinator, or to one of the various "smart" factorio things.

We can certainly do this, now, with a constant combinator, or simply with a bunch of duplicated, hard-coded settings, as they do in the -root tutorial linked above.

The problem is, let's say we export this blueprint and share it with somebody -- which constant should we stick in our blueprint? Obviously there is no good answer except to tell our friend that he'll need to reconfigure the settings before using it.

Truth be told, I can pretty much live with that status quo... but what I can't live with, is the idea that I'm going to deliberately create a bunch of train-stops (or other things) that will each depend on me to twiddle a bunch of frobs every time I science my way up to a higher inserter stack-size bonus... I'll never remember to do that!

Worse, due to the ways it's likely going to be used, my builds will probably not completely break, but just misbehave in subtle ways, due to spooky modulo arithmetic side-effects, so, hard to debug, easy to forget, etc. F that noise, in short.

Sure, we can run green wires on power poles to all of our stations or whatever, to centralize the thing down to just a single combinator, but, I dunno, I'd never do that, personally, since I'd just end up blowing it up in some kind of military exploit.

So for me, although Madzuri's loader looks like a terribly appealing idea, in practice, it seems like a bad tradeoff vs. the old-fashioned "splitter" train-balancer (which, with some stupid braiding tricks I am able to make reasonably compact without hopelessly unbalancing the buffer storage distribution, anyhow), until I've exhausted all the stack-size-bonuses in the tech tree.

Admittedly, for now, presumably most players don't spend a lot of time going through the tech tree, but that's kind of a bug, as recently noted in fff-129, and therefore liable to change in the future.

So, how could this be fixed? Simple. Just supply the current inserter stack-size bonus as a circuit signal along with all the other fancy abstract ones. Now our blueprints keep working, our stations keep working, we don't have to build a bunch of constant combinators or run around to all our stations every time we nerd it up in the lab, etc...

Thanks for your consideration!

[ssilk]

In programs this is called a global constant; every part of the program can access it. Here I would call it "Global signal".

Other useful global signals:
- Robot stacksize
- Max size of the world in tiles (X and Y)
- Current day/night status, time of day.
- Current real time (unixtimestamp / seconds today). That signal is special, cause it is an event from outside and must be saved with the replay.
- Evolution factor
...

Good idea.

[ratchetfreak]

They should probably coming from a special combinator.

Once you have that you can make that combinator emit local values as well like local polution, amount of certain items in the logistics network, items missing for construction, items missing for requester chests, number of bots (working) in the network, ...

[golfmiketango]

In programs this is called a global constant; every part of the program can access it. Here I would call it "Global signal".

Other useful global signals:
- Robot stacksize
- Max size of the world in tiles (X and Y)
- Current day/night status, time of day.
- Current real time (unixtimestamp / seconds today). That signal is special, cause it is an event from outside and must be saved with the replay.
- Evolution factor
...

Good idea.

Well that very much broadens my idea but I'm all for it.

One thing I could really use in my campaign are a counts of logistic and construction robots, and roboports, deployed in the logistic network -- that's not really global but per-logistic-network, I suppose -- also a bit tricky to think about "detecting," since those two networks are not the same.

On sort-of similar lines, I really like the idea of a "logistic circuit proxy" which outputs the contents of a logistic network as if it were one big smart-chest. I think there might be a mod for that somewhere but imo it really belongs in the base-game.

I think there's a lot of bikes in this shed once we start to look at it.

[Peter34]

In programs this is called a global constant; every part of the program can access it. Here I would call it "Global signal".

Other useful global signals:
- Robot stacksize
- Max size of the world in tiles (X and Y)
- Current day/night status, time of day.
- Current real time (unixtimestamp / seconds today). That signal is special, cause it is an event from outside and must be saved with the replay.
- Evolution factor
...

Good idea.

I'd like to be able to "read" the current percentage progress of the tech research, so that I can make a fancy Lamp-based display that shows the progress.

[ssilk]

@ratchetfreak: I would just extend the constant combinator for that usage. It just has more signals then and you need to link those "virtual signal" to one specific like the "A"-signal...

@golfmiketango: When I understand the FFF about the new circuit network correctly, then this will be the case with 0.13.

@Peter34: I'm sure there are a million more possibilites to send signal.

I just had a idea to play around: Each of such "global signals" must be researched first.

[golfmiketango]

I just realized, the perfect way to implement circuit-y "detectors", i.e., entities that tell you what items are in a certain place: radars! Its totally obvious once you think about it.

Classic examples for why you might want this ability: to detect the presence of the player at a PAX station, or an enemy on the wrong side of your security barriers.

Only problem is, assuming it existed, it begs the questions: can we have teeny-tiny radars? Or better yet, radars that ignore everything but a subset of their standard range?