[A13] A2B: conveyor belts & co. [v0.13.2]

Started by A2Bcorp, February 21, 2015, 01:23:14 AM

Previous topic - Next topic

1000101

#30
You don't have to worry about spoilage and item degradation in the current release but, you do have to worry about repairing sections as the conveyors are non-passable.  This means if a fire or some other damage occurs, you don't be able to reach anything in the centre of your loop.  Also, your ore extractors can share loaders however, having the extra loaders does help your pawn haulers and improves conveyor efficiency.
(2*b)||!(2*b) - That is the question.
There are 10 kinds of people in this world - those that understand binary and those that don't.

Powered By

noone

Quote from: 1000101 on March 22, 2015, 04:33:44 AM
First, loaders get a toggle option for "wait for full stack" which will ... wait ... for a full stack ... before sending it down the line.

Hi 1000101,
Happy to know you find the A2B system useful - always glad to hear this. As per the "full stack" suggestion, I think this extra button would be confusing, and could also cause serious problems (i.e., what if your colonist is hauling more than allowed in the current state, etc ...). I think this is a fair request though, but I guess I would try to implement differently: i.e. the belt do by default stack items "on the move", if they encounter a jam. That way you won't fill the belt system as fast, but there's no need to worry about anything on the user end. Note that this is already in place for the Unloaders (I think?) when dropping items on the floor.

Quote from: 1000101 on March 22, 2015, 04:33:44 AM
Second, a "soft" selector-splitter hybrid which has one filtered output and two unfiltered outputs.

That, I am much less in favor ... ;) While I can see the benefit in some cases, it would also be a very confusing element - and I think that a 2x3 system is "alright" in that case ... and that's a great design, assembling basic logic blocks in something more fancy !

Quote from: passi965 on March 23, 2015, 05:57:01 AM
And i know that Conveyor belts sort of act like walls, so the conveyor belts are to small to support a roof (and let through heat) but high enough to be inpassable.

This should be fixed in the next release, hopefully. I.e. belts will not act like walls anymore, with all of the consequences that this implies - no thermal isolation, etc ...

obrien979

I have downloaded the newest verison and installed it in the MODS folder, however when I activate the MOD and start the game, I do not have a construction option for them. 

Can anyone help?

Brandon

rditto48801

Quote from: obrien979 on April 11, 2015, 09:48:26 PM
I have downloaded the newest verison and installed it in the MODS folder, however when I activate the MOD and start the game, I do not have a construction option for them. 

Can anyone help?

Brandon
They are not unlocked be default.
You have to Research them first. (which oddly enough does not seem to be mentioned in the OP)
They should have their own "A2B Belts" selection/group under Architect once researched/unlocked.
Always (less than) eager to stockpile 3 metric tons of steel to replicate a useful gun.

Dr. Watson. Proving that being wrong is one step closer to being right.

A2Bcorp

#34
Hey everyone,

We at A2B are happy to announce the A10 release of our system. It has been thoroughly reasonably tested. Please report any bug/usability issues !

The update also include a few changes: a symmetric selector, the belts will freeze in cold weather, and more research to improve the cold resistance, decrease the wear-and-tear speed of the belts, reduce the heat flash of the teleporters, etc ... Also, belts don't act like walls anymore !

Our engineers are currently working (more like day-dreaming at this stage) on implementing two changes: 1) food ought to get bad on the belts over time (unlike now) and 2) teleporters should be replaced by underground belts.
The point 1) is a tricky one and might take a lot of time. Point 2) looks more promising for a not-so-far away implementation.

Enjoy !

dareddevil7


A2Bcorp

Dream no more, belts are already cross-able ! It's costly, and pawns will only do it if they absolutely have to. And they will take their time doing so, to avoid getting their feet stuck in the belt. But still, they are cross-able !

Note that the planned "underground" belt system should look rather pretty and take less space than the teleporter pair, so this would eventually be the best way to do it.

dareddevil7

Quote from: A2Bcorp on April 17, 2015, 11:42:03 PM
Dream no more, belts are already cross-able ! It's costly, and pawns will only do it if they absolutely have to. And they will take their time doing so, to avoid getting their feet stuck in the belt. But still, they are cross-able !

Note that the planned "underground" belt system should look rather pretty and take less space than the teleporter pair, so this would eventually be the best way to do it.
[ All My ($) All My ]

1000101

ERP!  Can we have the old selector back?  The one with two inputs and two outputs?  It was essential to some of my designs and frankly, the new one is just ... erm ... yeah.  :(
(2*b)||!(2*b) - That is the question.
There are 10 kinds of people in this world - those that understand binary and those that don't.

Powered By

A2Bcorp

Interesting. Could you explain why the old design was better for your belt system ?

You ought to be able to replicate it by adding a merger just before the Selector, and only connect one of the Selector exit (if only one is available, all items will go there). Same effect as the old Selector, but in a 2x1 structure.

1000101

#40
Well, the two-in-two-out allowed for many combinations of logic and when used with other basic blocks, complex systems could be built.

Namely, the option of which orientation input comes from holds a huge importance in the logic structure.  Basically, the original selector was an Or-NE (not-equal) gate now, it's just a NE Gate.

Take this example:  There is absolutely no equivalent way to build this with the new selector.


Also, the two inputs allows for controlling where the outputs are actually going and how it's pathed due to inputs being 90-degree adjacent to both the Or and NE outputs.  Now the input is 90-degree adjacent to the NE outputs and opposite the equivalency output.

This selector would fall into the "edge case" of usefulness for me.  I've actually invest huge amounts of time in my colony design to make sure my conveyor system is efficient. I don't see how this selector adds to the efficiency and, actually, quite the opposite - it's a disaster since now there is NO way to prevent the log-jamming where my 2x3 near-miss method while isn't the most ideal solution in my mind, it's (a) impossible with the new selector and (b) used the core components we are all familiar with.

Really, I can see no logical reason to remove the original selector and replace it with this one.  Perhaps adding a new selector of this type, but not replacing.  Personally I see the original selector as far superior to the new one.  After seeing the A10 update I am tempted to download the source and strip out the selector and replace it with the original one or maybe leave it for edge case, but I can't think of a time when I would ever use this new selector without being forced to.  To wit, the original, better, one is gone.

Further, real-life conveyor belt system use side-offloading mid-line and only end-offload at the shipping docks.  Generally the systems are built in a large horse-shoe layout bring finished products to the same (or near) place which the raw materials are loaded onto the belt.  The original selector was perfect for this and is 100% natural in this regard.  Viewing it in this context, the new selector doesn't make sense at all.  No matter which direction my belt flowed, I could always offload left or right and straight forward.  But the important part is that the reject path is the forward one and the acceptance is one-sided.  This means it needs to inputs.

I did notice that this selector is similar in concept as my hybrid proposal as far as inputs and output go (by numbers).  Not in layout or functionality though.

Maybe it's just me, but I see no logic in this change and for me, it is a severe blow to the usefulness of the mod.
(2*b)||!(2*b) - That is the question.
There are 10 kinds of people in this world - those that understand binary and those that don't.

Powered By

A2Bcorp

Thanks for that feedback, much appreciated.

The Selector was made symmetric recently in the wake of including symmetric Splitter and Mergers. Some users were highly in favor of a symmetric Selector because it would give them more freedom in their design.

We still maintain that in the current state of affairs, the "old Selector" would be equivalent to a Merger+ New Selector together, with two inputs connected to the merger, and only 2 exits connected to the Selector. So, your 2x3 blocks example could still be build as a 2x4 blocks (with an additional straight belt between the two top left blocks).

This being said:
- The selector is binary (items can be selected or not), hence only two exists are warranted.
- Having the exits back-to-back is probably not the best (as you say), given that belts "usually" flow in one global direction (rather than meet head-on).
- Having two "2" exists offers possibly more flexibility, but this is technically the role of the Splitter.
- We don't like un-happy people. There will always be unhappy people, it's just a matter of minimizing their number ;)

Long-story short, we at A2B are now leaning towards reverting back to the old Selector (2 in's+2 out's). While both designs can be "recovered" in both cases by combining different blocks, an additional "input" seems useful in more cases than an additional "2" exit would be. Especially as the old Selector still was suitable for splitting-off to the left or two the right (either by selecting all-minus-one-item, or one-item-only).

If anyone else vividly disagrees with reverting to non-symmetric selector, raise your voice ! Otherwise, we will go ahead with the downgrade in the next release - that should also include undergound belts (these will eventually replace the teleporters/receiver pairs, but will be introduced along-side them first because they are not perfect just yet) !




mcduff

Quote from: A2Bcorp on April 17, 2015, 11:42:03 PM


Note that the planned "underground" belt system should look rather pretty and take less space than the teleporter pair, so this would eventually be the best way to do it.
*happy dance*

1000101

Quote from: A2Bcorp on April 19, 2015, 07:42:10 PM
Thanks for that feedback, much appreciated.

- snip -

Thanks for considering my input.  :)  I would suggest having the new selector as a second selector option.  It's one more part and it does have it's uses (although I still think they would be edge-cases) and some people, as you point out, do want such a thing.

I can understand why you wouldn't want to do the hybrid selector-splitter as some people could be confused though I can't imagine why, it's just an overflow valve.

I'm not sure how I could rebuild my 2x3 configuration with the new selector as the logic is dependant on two inputs into one selector (the new selector and merger would not work because it would just be splitting back into itself).

Anyway, can't wait to see what else you cook up and I hope I didn't come off as demanding or otherwise disrespectful to your work and vision of what your mod should be.
(2*b)||!(2*b) - That is the question.
There are 10 kinds of people in this world - those that understand binary and those that don't.

Powered By

Famous Shoes

As one of the folks who was leaning towards a selector that pushes matches left and right, the point (for me) was user experience, not specific cases. One issue with having only one, asymmetric selector is that some selectors need negative lists and some need positive. I originally suggested just having two asymmetric that were mirror images of each other, that way a user would only need one type of list (positive or negative) throughout a system; reducing errors, time spent faffing about with check boxes, and allowing users to make better use of the copy/paste list functionality from good old EdB! The other issue I see with asymmetrics is they're space hungry for simple systems while saving space in complex systems. If it were me, I'd optimize UX for the former over the latter--us nutcases with horribly complex nonsense can abide (assuming of course you prefer not to optimize both, you know, by giving everyone everything all the time.)

For what it's worth: I'd say have either a selector that splits left and right, or two asymmetric selectors (mirrored), or all three, but not a lone asymmetric, regardless of other types.

And @69, if that Rube Goldberg example isn't an edge case, I don't know what is.  ;D