Factorio Forums

TL;DR
Extend the numerical input parser/validator to also accept hexadecimal values (using the 0x prefix). No changes are requested in the display of these numbers (and internally, a number is just a number anyway)

Detail
Say I have a map with a lot of outposts. I want to provide all these outposts with supplies, but I don't want to have an excess number of trains running around. So I assign each outpost a number and put the outpost's number onto a circuit when supplies run low. My main base then automatically sends a train to the requesting outpost (assume for the moment, there's a mod that provides this exact functionality - it isn't there yet, but it's been hinted at). However, just using sequential numbers will lead to problems. Say both outpost 3 and 5 are requesting supplies: wire values add up, so the base sees an 8. How is the base supposed to know where to send the supplies?

Enter bitmapped fields.
Instead of assigning values 3 and 5 to these outposts they get assigned bits 3 (1000 binary, 8 decimal) and 5 (100000 binary, 32 decimal). Now when both outposts request materials, the circuit sees 40 (101000 binary) and there's no room for confusion.

Why hexadecimal inputs?
Small numbers are easy enough, anyone familiar with computer programming will know the sequence of powers of 2 for the first 10 to 16 bits by heart (in a distant past, even Factorio used powers of 2 for stacksizes! ). It gets a bit more difficult beyond that, when you're up to the 28th outpost or so. Remembering and accurately entering 134,217,728 is a lot harder than entering 0x800 0000 (and the steady sequence of 0x1, 0x2, 0x4, 0x8 followed by a number of 0's makes it easier still)

Why no changes to display of numbers?
I realize this suggestion is probably only interesting for a rather niche audience and this niche audience will likely be perfectly capable of recognizing what bit a displayed decimal value corresponds to.

Or you use a address line (on signal 0 for example) and a reply line and cycle over all outposts.

at the outpost you use a combinator signal 0 = Outpost ID output everything input-count and transmit that output over the reply line.

then when there is a train ready to depart you cycle over all outposts and you can check each individually and put the train sending logic at the departure station

I think hexadecimal input would be useful in many other applications of combinators.

Agree with you that it is a very specialized need. I think that it would add complexity that would not nessisarily be needed.
As for your outpost 'problem', I would've recommend having the outposts on separate circuits, so the values do not get mixed up.

TuckJohn wrote:Agree with you that it is a very specialized need. I think that it would add complexity that would not nessisarily be needed.
As for your outpost 'problem', I would've recommend having the outposts on separate circuits, so the values do not get mixed up.

Does it add any complexity, though? If you don't know that hexadecimal numbers are written with a "0x" prefix, then you would literally never know the feature existed at all.

Exactly, it changes nothing for players that don't know/need/use it.

And the outpost problem is just one example that made me think of this, I'm fairly certain minds far smarter than me can come up with lots of other ways to leverage a feature like this.

Boogieman14 wrote:Exactly, it changes nothing for players that don't know/need/use it.

And the outpost problem is just one example that made me think of this, I'm fairly certain minds far smarter than me can come up with lots of other ways to leverage a feature like this.

Yeah, bitmasking is kind of a big deal.

Tinyboss wrote:
Yeah, bitmasking is kind of a big deal.

but useless without bit-wise operators

With the current operators doing bitwise operations give no advantage to binary over tertiary or decimal.

Given that Combinators now support many bitwise operations, it would be very useful to be able to enter, "0xff" or "0xff00" or "0xFE800000" or such as the constant second-argument of an arithmetic or decider combinator, or as the values on a constant combinator. Currently I have to flip over to the windows calculator and convert these values to decimal, and they become opaque blobs that then need further labelling (for non-trivial powers of two, at least) for future maintainability of the circuits.

Yes, please! This would be hugely useful when trying to implement more computer-like systems. Decimal is great for many things, but computing isn't one of them.

I agree that it would be nice to be able to toggle between decimal and hexadecimal entry of numbers. But it should also be possible to toggle the display.

Dear development team,

I would like to suggest three things:

• I want to be able to enter numbers in this form "2 ^ 24" and have it be converted to 16777216.

• I want to be able to enter numbers in hex form (eg, 0xFF is 255).

The points above would help tremendously with complex circuitry.

• I would like to have a toggle in the options to display circuit numbers in hex form, to aid in debugging.

Thank you.

Why in hex? Not very useful. Is for 0xABCDE76 the 15th Bit set or not? If that will be implemented I would add binary input.

ssilk wrote: Tue Jul 21, 2020 3:42 am Why in hex? Not very useful.

Because hex is very compact and people with programming background usually can convert between bin and hex on fly.

So, I vote for both 0xFF and 0b11111111.

P.S. Bit 17 of 0xABCDE76 is 1100 and bit 15 is 1101. Now try to find them in the 1010 1011 1100 1101 1110 0111 0110.

It’s about comparability. Let’s say you want to program a LTN station, what’s easier?

Compare the wagon-mask with 0x0020000 to find the 17th wagon unloader. And 0x0040000 for the 18th. You need to think it all the time: 1, 2, 4, 8, then the next digit...

Or compare by using 0b0000 0000 0010 0000 0000 0000 0000 for the 17th, then copy that into buffer, go to next stop, paste, remove one 0 at front and add one 0 at the end. I would prefer this method, because I can’t make stupid mistakes.

... Ah. Now I see the sense of the other form you want to make inputs. “2^17”, “2^18”... and for bitmasks you can say “2^17 + 2^18” ...hm. Yes. I still think binary has it’s usecases, especially when taking an output and copy/paste it as input for something else.

BTW printing such numbers seems to be much more complex... but that’s normally not needed, and that is a completely different story - very old suggestions about seeing the actual non-abbreviated value and so on.

ssilk wrote: Wed Jul 22, 2020 4:32 amYou need to think it all the time: 1, 2, 4, 8, then the next digit...

You don't need to think about 1, 2, 4 and 8. Think in groups of 4 bits. You can look at the number 0xABCDE67 and see that unloaders for wagons 19 and 18 are active and for 17 and 16 are not (C=1100). And wagons 15, 14 and 12 are active too (D=1101). It takes a little practice to remember mapping between hex digits and their binary representations. But then you can read and write hex masks almost instantly.

In fact, binary is much more error prone to me. I always make stupid mistakes while counting those digits, especially if they aren't grouped.

That's why I suggest to add both formats. Both have their upsides and downsides.

bormand wrote: Wed Jul 22, 2020 5:52 am

ssilk wrote: Wed Jul 22, 2020 4:32 amYou need to think it all the time: 1, 2, 4, 8, then the next digit...

You don't need to think about 1, 2, 4 and 8. Think in groups of 4 bits. You can look at the number 0xABCDE67 and see that unloaders for wagons 19 and 18 are active and for 17 and 16 are not (C=1100). And wagons 15, 14 and 12 are active too (D=1101). It takes a little practice to remember mapping between hex digits and their binary representations. But then you can read and write hex masks almost instantly.

In fact, binary is much more error prone to me. I always make stupid mistakes while counting those digits, especially if they aren't grouped.

That's why I suggest to add both formats. Both have their upsides and downsides.

This. Hex translates easily and directly to binary, is more compact, and more readable and usable in nearly all cases. Memorizing the sixteen binary representations each hex digit encodes isn't difficult (and can be pretty easily worked out from first principles anyway), and anyone who wants to encode binary or hex numbers almost certainly knows how to do it.

I think the player cannot memorize sixteen representations if he uses them occasionally. Yes, he will know how to convert it using exernal tools, how about embedded tools? If we would have two display modes, why not to add the third one?

BTW every bit can be numbered, therefore no problems locating 15th bit.

I would prefer a converter combinator which gets a value as input, has a setting for the target digit system (2/10/16) and outputs the value converted.

This has the advantage that it can be put everywhere in the circuit where a specific value is needed in an other digit system.

Is this not possible as a mod?