Factorio Forums

I did not want to create a forum account at first however I discovered you do not receive any notifications through the mods panel so here is the repost of this link https://mods.factorio.com/mod/LogisticT ... 0009793b2d



While scouting for mods I stumbled upon this one, after reading about your encoding issue I came up with the following; Instead of bit masking.

Add a set of virtual signals for example L1 - LnMax and C1 - CnMax to represent a chain of similar types in a row, where nMax is the maximum number of sections in a pattern like: LCCCCCCLLLCCCCCLLLCCCCLLLLLLCCCCCLL. A pattern like that only needs nMax to be 9 to produce the signals C2=6, C4=5, C6=4, C8=5, L1=1, L3=3, L5=3, L7=6, L9=2.

Virtual-signal sprites could display Loco n, Cargo n, Fluid n, H-oil n, L-oil n, Petrol n, ETC n where n is the section number. The value of the signal returned to the circuit network is the total amount of that type in that section.

This will provide a somewhat more human readable interface and it means you don't have to deal with bit masking with combinators during gameplay. You can have (2^31)-1 entities of the same type grouped in a section and, unless factorio internals are less restricting than the circuit network, also (2^31)-1 sections if you are willing to create that many sprites per type or ignore the idea of individual sprites after a certain number. If that's not enough you can also include negative integer values to double that but it will reduce readability significantly again.

Preferably nMax should be tune-able ingame and virtual-signals generated as needed, if a sprite exists use that, otherwise a default.

If you need assistance creating images in bulk, there is a powerfull plugin for GIMP that will allow you to do bulk operations through a GUI:

https://alessandrofrancesconi.it/projects/bimp/
""With BIMP you can apply a set of manipulations to an entire group of images! It provides an easy to use interface and a lot of batch functions""

I hope this will help you a bit!

wak

I see no reason to change binary encoded signals.
They are a simplistic elegant solution that doesn't clutter the virtual signal tab while being easily processable into combinator circuits.

PS:
If you want to make it human readable use a the 1.5 combinator circuit shown in my designs.

Whether you do something with my suggestion is completely up to you.

To the best of my knowledge I thought you had reason as I encountered the following lines and references to them several times across the topics listed here.

Constant Combinator: (signal output)

train composition: position of wagons & locomotives in parked train (all stops)
binary encoded signal of train composition up to 31 carriages with lsb at the train stop. More information about binary encoding here

Known Issues:

trains longer than 31 carriages don't display train composition signals
Nothing I can do about that, the circuit network is signed int and can only display 31 bits. If you know a better encoding that isn't limited by either bit width nor number of signals let me know.

As far as the clutter in the virtual-signals tab goes, you could create your own tab for this purpose to hold all the clutter. Perhaps hiding this tab from the end-user if possible, if not, you can also create subgroups inside the tab and you at least have some separation.


You could even opt for a combination of my suggestion and your original limited signal to provide backward compatibility.
Or include a setting ingame that allows people to control whether the output signal is binary encoded limiting the train length for circuit operations or as per suggestion to provide support for up to 2^31 wagons per section/group/type.


Personally speaking, I made a memory cell in my factorio build using combinators that will allow you to to store any value that is not 0 for any combination of signals in a single memory unit, each memory unit you can read and write to using an 31 bit unsigned integer for the memory address. So this memory cell can theoretically be expanded to hold a maximum of 2^31 different sets of signals and their values if I would ever need it if the game doesn't crash before that time.

This game unlike other games that allow wire-contraptions already provides signed integers to us and we can even do arithmetic's on them out of the box, I don't see a reason why anyone would choose to not utilize this feature. Binary encoded integers are elegant indeed and they also serve their purpose where needed.

The only place where I use encoders/decoders is when I process encoding tables for displays so they can display any value I desire through 1 wire, up to 31 characters in each row/column for each given set of signals transmitted to the display, signal set depends on how many lamps are used to compose a single character.

A binary encoded signal is simple in use once you get around the idea however your signal is unable to provide the quantity of data for the composition of my 500+ wagons in a train. I was considering to use your mod but in its current state this will not suffice for my needs. I had the impression you wanted to improve this feature so here are my 2 cents.

I don't need the signal to be human readable, but its a nice side-effect of extending the number of wagons you could manage through the circuit network, including the cargo type of the wagon also allows people to have better control over processing whatever is inside. You probably don't need that many section numbers for the sprites, as most people will likely only build an Ln-Cn(-Ln) type train already grouping the wagons by type as much as possible.
That would boil down to (nType + 1) * nType sprites for a basic set of signals where you don't have duplicate section types in a train. If you then would want to support people with higher or more complicated needs you add another nType sprites more without a number indication that serves as default for higher numbers, and have a setting ingame so people can adjust how many clutter signals they wish to utilize.

wak

To combat clutter you could also provide a setting that chooses to utilize vanilla signals in a very basic way, where signal 0 represents the front/first section, and signal z could represent section number 36, without specifying any types at all

You missed the part about "limited by number of signals". Your solution is limited by how many Ln and Cn signals you make.

PS: You seriously use trains longer than 32 of the same length that have locomotives at different positions?

mrvn wrote:You missed the part about "limited by number of signals". Your solution is limited by how many Ln and Cn signals you make.

PS: You seriously use trains longer than 32 of the same length that have locomotives at different positions?

Every solution is limited in one way or another. This one should not reach any human limits in the near foreseeable future and allow for a wider range of use then the current implementation.

All my trains are of C-L-C(-L) type no matter the length. I'm currently using vanilla train stops combined with circuit network to automate loading and unloading of trains, the first wagons on each train carry composition and request data. However apart from being extremely tedious to set up, using vanilla items I'm very limited to the set of symbols I can use as each of those items can never be transported through rail.


P.s. Anyone have a better solution?

wak wrote:

mrvn wrote:You missed the part about "limited by number of signals". Your solution is limited by how many Ln and Cn signals you make.

PS: You seriously use trains longer than 32 of the same length that have locomotives at different positions?

Every solution is limited in one way or another. This one should not reach any human limits in the near foreseeable future and allow for a wider range of use then the current implementation.

All my trains are of C-L-C(-L) type no matter the length. I'm currently using vanilla train stops combined with circuit network to automate loading and unloading of trains, the first wagons on each train carry composition and request data. However apart from being extremely tedious to set up, using vanilla items I'm very limited to the set of symbols I can use as each of those items can never be transported through rail.


P.s. Anyone have a better solution?

Do you realize that trains have a wind resistance and the wind resistance of a cargo wagon is much higher than that of a locomotive? By putting your locomotive in the middle you are considerably slowing down the train acceleration and top speed.

By the way I find your encoding highly impractical. With the current signals you can add a fuel inserter at every position, wire them up to activate if "locomotive & 1<<n > 0". With your encoding you would have to add up the Ln, Cn, Fn (fluid wgon), An (artillery), and a bunch of others when playing with mods. Figuring out if there is a locomotive at position 10 becomes math homework. I think the only use for train composition is refueling so that should remain simple.

mrvn wrote:

wak wrote:

mrvn wrote:You missed the part about "limited by number of signals". Your solution is limited by how many Ln and Cn signals you make.

PS: You seriously use trains longer than 32 of the same length that have locomotives at different positions?

Every solution is limited in one way or another. This one should not reach any human limits in the near foreseeable future and allow for a wider range of use then the current implementation.

All my trains are of C-L-C(-L) type no matter the length. I'm currently using vanilla train stops combined with circuit network to automate loading and unloading of trains, the first wagons on each train carry composition and request data. However apart from being extremely tedious to set up, using vanilla items I'm very limited to the set of symbols I can use as each of those items can never be transported through rail.


P.s. Anyone have a better solution?

Do you realize that trains have a wind resistance and the wind resistance of a cargo wagon is much higher than that of a locomotive? By putting your locomotive in the middle you are considerably slowing down the train acceleration and top speed.

By the way I find your encoding highly impractical. With the current signals you can add a fuel inserter at every position, wire them up to activate if "locomotive & 1<<n > 0". With your encoding you would have to add up the Ln, Cn, Fn (fluid wgon), An (artillery), and a bunch of others when playing with mods. Figuring out if there is a locomotive at position 10 becomes math homework. I think the only use for train composition is refueling so that should remain simple.

Be that as it may, those facts and opinions are not related to the problem or solution.
For you my method of encoding is impractical because you probably do fine with whatever it is you do now, for me this is desired behaviour because I can use those signals to influence the rail network and have the loading/unloading controlled by circuit.

wak wrote:

mrvn wrote:

wak wrote:

mrvn wrote:You missed the part about "limited by number of signals". Your solution is limited by how many Ln and Cn signals you make.

PS: You seriously use trains longer than 32 of the same length that have locomotives at different positions?

Every solution is limited in one way or another. This one should not reach any human limits in the near foreseeable future and allow for a wider range of use then the current implementation.

All my trains are of C-L-C(-L) type no matter the length. I'm currently using vanilla train stops combined with circuit network to automate loading and unloading of trains, the first wagons on each train carry composition and request data. However apart from being extremely tedious to set up, using vanilla items I'm very limited to the set of symbols I can use as each of those items can never be transported through rail.


P.s. Anyone have a better solution?

Do you realize that trains have a wind resistance and the wind resistance of a cargo wagon is much higher than that of a locomotive? By putting your locomotive in the middle you are considerably slowing down the train acceleration and top speed.

By the way I find your encoding highly impractical. With the current signals you can add a fuel inserter at every position, wire them up to activate if "locomotive & 1<<n > 0". With your encoding you would have to add up the Ln, Cn, Fn (fluid wgon), An (artillery), and a bunch of others when playing with mods. Figuring out if there is a locomotive at position 10 becomes math homework. I think the only use for train composition is refueling so that should remain simple.

Be that as it may, those facts and opinions are not related to the problem or solution.
For you my method of encoding is impractical because you probably do fine with whatever it is you do now, for me this is desired behaviour because I can use those signals to influence the rail network and have the loading/unloading controlled by circuit.

I call it impractical because it doesn't simply tell me what is at position 12 in the train. Sure you can decode the output you suggested but it requires a lot of combinators to deciver what is at position 12 if you assume trains can have any composition (and not just the two or three one usually uses).

Given that you need more signals to carry more info how about just extending the bitmasks with an option in the settings. Default to 1 to give just the signals we have now. Set it to 4 and you get the current locomotive (L0) signal for bits 0-31, L1 for 32-63, L2 for 64-95 and L3 for 96-127. That way normally no signal clutter occurs. But people that need composition for longer trains can enable them and decoding them remains fairly trivial.

mrvn wrote:....

I call it impractical because it doesn't simply tell me what is at position 12 in the train. Sure you can decode the output you suggested but it requires a lot of combinators to deciver what is at position 12 if you assume trains can have any composition (and not just the two or three one usually uses).

Given that you need more signals to carry more info how about just extending the bitmasks with an option in the settings. Default to 1 to give just the signals we have now. Set it to 4 and you get the current locomotive (L0) signal for bits 0-31, L1 for 32-63, L2 for 64-95 and L3 for 96-127. That way normally no signal clutter occurs. But people that need composition for longer trains can enable them and decoding them remains fairly trivial.

Now I see why it would become impractical for you.
When presenting me the question "what is at position 12?", I also have trouble giving a clear easy answer to that using my suggestion, your simplified suggestion is perfect to answer this question easily I must admit.
However usually, at least I, will not compose my trains as a single wagon for each product. So, the question I'm asking is: "how many wagons in a row form a collection of the same type?". My trains have a block of locomotives mostly only capable of going in 1 direction only, and several blocks of wagons. Each block is dynamic in size and configurable on what to carry, there is only one block per type at maximum, I simply need to know its length. After a train has reached destination it will be reconfigured to do whatever job is next in the queue. A job in the queue consists of an request-order and this is either to have a certain amount of finished product collected from a factory or to deliver a certain ratio and amount of resource products to a factory.
My railnet is a meshed-loop configuration, all trains go from nearest endpoint to furthest endpoint and back and repeat. The trains will each do whatever it is that comes on their path unless they have specific orders. Their info is updated on-the-fly as needed, each station evaluates this and is able to modify this where needed, this data is stored in the first set of wagons at the front so this is my fixed point that will always be the same on each train.

I came here originally because I was looking for a mod that would do a similar kind of thing but I've come to a point where I don't need the mod anymore. All this is circuit regulated and build-able using vanilla components. I made a private mod that provides dummy items for the purpose of data exchange/storage, these can be crafted/destroyed in assemblers on each station. I used vanilla items before but this comes at the cost that it limits the places where I can use this and the logistics involved in that gives too much overhead.

Thanks for thinking along mrvn, I hope Optera uses your suggestion as mine is probably too complex for general use in comparison. For now I will stick with what I got and build further on that.