Cargo Container receiving priority should be higher than assemblers

Its bothered me for a long time, but would it be possible to set receiving priority higher on cargo containers for items? It would solve the need for scripts that occasionally unclog assemblers that are full because refineries are dumping ingots into them before other available cargo containers.

Also, it would be nice if we had some built in logic in assemblers to make an executive decision to remove ingots from their own inventory when those ingots are blocking the addition of materials needed for the current item in the build queue.

 

Just gave this a test, and yup, it is kinda dumb.
I usually use an inventory management script though so I don't usually notice this.

 

Well, to the rescue! The system is actually very simple, and quite powerful if you know how to use it.

Firstly, it runs on a "Push/Pull" system, where something that produces something, and its production inventory fills to a certain point, it sends out a "Push" request, and then delivers it to the CLOSEST eligible non-full inventory.
When a block is trying to produce something, it then tries to send out a "Pull" request, and again, takes it from the closest possible inventory.

Your assemblers clogging up can be a completely different problem. If you try to produce very large quantities, then there is sometimes a bit of "left over" from the last order, and that slowly builds up over time, especially if you are producing many different things.

 

Ah, I didn't know about the distance thing.

 

I am not sure if it is physical distance or conveyor distance, but this is a pretty easily mitigated problem that can be fixed with ingenuity, sorters and some smart.... ENGINEERING

This way you also have more control over it, you can couple a Refinery directly to an assembler, remove pulling on the Assembler, and you got yourself a steel plate factory only taking input from the output of THAT specific refinery.

 

I like my conveyor systems to have a high degree of generality, I find the idea of a dedicated assembler for a single component a little distasteful
Also it doesn't hurt to think about the general accessibility of the game once in a while. Just because the game is "about engineering" doesn't mean we should ignore mechanics whose default behaviours are needlessly obtuse.

 

@101m4n Actually that is exactly why we should. If the mechanics got changed, people who make this kind of builds suddenly have to spend even more space, while just a bit of planning can even without sorters make a really, really, really neat inventory management system.

It is by no means an obtuse system at all, it also encourages some smarter building. Separate Refineries and Assemblers with a Cargo container (or multiple) and then on the other side, closer than those cargo containers you place other containers. You can even have dedicated containers for each and every material you are building, if you use an assembler for each, or only run assemblers building specific sets of materials, automatically sorting it without ANY! sorters build at all.

Also this little dedicated assembler for a single component is something I have done before... Especially for stuff like steel plates...

But honestly, I am not even sure if refineries even push to assemblers in the first place. I know where some of the problems of comes from, simply because the logic for the pull requests is not really that smart for assemblers, and they never push out their materials when full.

Do also remember, you might like generality, but not everyone does. Others like to have a set of rules that they know will consistently behave like this and make interesting builds with (Redstone... Good example of a simple system with some rules that allows you to do interesting things, but why not just include a visual scripting system instead that could do the same but only fill one block? WE NEED GENERALITY, no in Redstones example, the limitations of it is as equally interesting to the redstone builders as what you can do with it)

 

@Scorpion00021 sorry about this argument brewing between me and sio, you know the old addage "arguing with an engineer is like wrestling a pig in the mud" if not, look it up. It's good for a laugh and emarrasingly true
Anyway TLDR;
Put a large cargo container between your refinery and your assembler, the ingots should go there. Alternately, grab yourself an inventory management script and save yourself the hassle TIM has a decent guide to go with it too, you can find it on the workshop.

@sioxernic You totally misunderstand what I mean by generality. The cpu in your pc has generality because any task can run on any core, if you had to have a core for each application you wanted to run, your PC would not only be slower on any single application but if you ran out of cores, you would be SOL. Not only that, but many tasks don't need much CPU time, so the processor would be would be horribly underutilised pretty much all the time. Same thing applies to a bank of assemblers in your conveyor system. If you have 20 assemblers each for one type of item, then if you need a lot of one item, not only do most of those assemblers go un-utilised, but you are stuck waiting for one assembler to do all the work. From an engineering standpoint It's an objectively bad solution, no two ways about it. That's what I meant when I said generality, any assembler can assemble any item. If you want to go full ham on the engineering rhetoric then conveyor sorters are objectively bad too because they don't do anything a well written script can't, and a programmable block is cheaper.

As for obtuse mechanics, games require communities. New players are not born with an understanding of all the games idiosyncrasies and may find anything that doesn't work intuitively by default off-putting. Engineering a solution provides a feeling of accomplishment and thats what SE is all about. But not if it is just to get past some bug (or poorly thought out feature) that shouldn't have been there in the first place. At the end of the day, if someone comes to the game, and the game does something they consider to be dumb, they are less likely to stay. And that's bad for the community, end of story.

As for redstone, are you kidding? When I played minecraft I was deep into computational redstone with the RDF (may she rest in peace) and then later with the RDFs spiritual successor ORE (the open redstone engineers), look em up. And I can tell you, we were forever bitching about how broken and needlessly non-deterministic the redstone update system was. Plots were littered with broken ALUs and processors that were half finished when an update came around and trashed them. There ended up being a massive shift away from the piston based logic towards using only comparators torches and repeaters. Not because they were more satisfying or better or anything, but because they relied on fewer of those "rules" you mentioned, and thus broke less often . Again, an objectively good engineering decision.

This applies to conveyor sorting too. Say keen decides to ditch the distance thing and set up some different kind of system. If you chose to go general (cough scripting cough) and avoid relying on those flimsy rules, then your system would still work, if not, then well, the jokes on you...

 

I never argued for having an assembler per part I usually have a dedicated steel plate assembler simply because... I need a lot of steel plates. Putting it closest to a single refinery allows me to continuesly produce steel plates for as long as I have Iron Ore, and any overflow of Iron Ingots just goes straight to another cargo container without any weird setup.

This is where better communication about these mechanics can be important, like pop ups the first time you start placing an assembler/refinery down for the first time.

That was mostly because the original rules did not work particularly well, which is why they needed an update. Redstone still has a lot of really weird interactions they were never meant to have due to sloppy coding as far as I understand.

And weirdly enough, the current system is extremely simple. If players were better informed they could take advantage of it. Otherwise, since this is still an Engineering game, there is ways to either obtain the information (community) or experiment. I have had hours of fun trying to figure out how stuff worked, how I could take advantage of things, etc.

Even if I am a big proponent of scripts, I'll still say there are definitely problems with how fast and easily scripts move large quantities of items. I would honestly personally prefer that any item movement by scripts should REQUIRE Sorters, but that's my opinion. I'd prefer things to be a bit more janky so as to not just have an easy to plug in system that does everything for you. Everything should require setup and thought. Everything should require something else. Most scripting functionalities require some block to access the information.

 

Hey guys, I do understand the mechanic that cargo tries to go into the nearest inventory (least conveyor distance traveled). My point in the original post was that as far as I'm concerned, there is NEVER an instance where it is desirable for refinery output to simply fill nearby assemblers automatically, especially when they already pull any material that they need. The current implementation either confuses newer players or encourages solutions where people are using hacky scripts to manage cargo flow to prevent these sorts of issues.

 

An "ignore push requests" setting on any blocks with inventory would probably do it, with it's default state being on for assemblers.

 

I would love a map tab only for configure the logistic system

 

Is why Keen gave us sorter blocks.

"I don't want to take the time to set them up." Then don't complain if things do not follow the route you wished it would take without using them, or planning effectively your production areas.

 

Perfectly reasonable chain of logic for a real life situation. But that's not how you design games. When you are designing a game, you have to incentivise use of game features, not punish people for not using them. That though implies that there was any design that happened at all here, more likely the programmer responsible for writing the conveyor code was strapped for time and didn't think about it. Anyway, lets proceed as if the current behaviour is an actual design "choice". In the case of conveyor systems, this means making the default mode of operation intuitive to new players. At the moment refineries will push to assemblers even though assemblers pull their own resources when they need to, there is no situation in-game where this can be considered "intuitive" behaviour, except perhaps on grids with no dedicated storage at all.

There are a thousand things like this in game, they are the result of lack of attention to detail, or devs being strapped for time. Nothing more. Stop defending them.

 

Actually it can be considered perfectly intuitive behavior. It is an inventory, the inventory is an input... Refineries output to inputs...
Perfectly logical and intuitive behavior.

And some of those "mistakes" is actually what makes a game more interesting, especially in terms of exploring its mechanics... A game that has super clear cut and super intuitive mechanics can actually quickly become boring... A basic game such as the original CS 1.6 actually had a lot of small little mechanics most players never knew. That is what makes the difference between a good player and a bad player.

But let's talk about Redstone again... Many of its "flaws in programming" actually became full fledged features later on, staying unchanged because they added quite a bit... (BUD's for example). MySpace having a fully customizable page was originally an oversight and a bug, but it stayed. That little turn/real time based puzzle game... Well originally some enemies simply ignored the turnbased system and just moved because of a bug... That ended up being the main feature... A lot of jankiness in MineCraft...

Even if it is a time constraint or a bug, I see absolutely zero problems with it, especially because as I mentioned earlier, you can make some interesting builds with it, and the sorter is there to give you full control.

 

@sioxernic You still don't understand my point at all...
Are you actually reading what I'm writing?
When you design a game, you don't want your players to feel like they are being punished for not using features, rather you want to reward them when they do use them.
At the moment a player might; start with no cargo container, then notice that their assembler is jamming up, then build a cargo container. Only to find out the items still go to the assembler, and the assembler still jams up.
Their reaction to this won't be "wow this is cool and interesting", it will be "wow this is stupid".
They may think, "there's this conveyor sorter I might be able to use to fix this", but if they are a new player they more than likely won't notice. Instead they will resort to manually moving stuff to the container. And it will end up being just another one of those many annoyances this game has.

Pure straw man. Making ingots go to cargo containers before assembler inventories doesn't negate the usefulness of sorters, not by a long shot.

 

Yeah, that is the goal, but that is not always feasible. If everything is clear cut, simple and just working, there is no problems to fix, and the engineering part disappears.

Yeah, if they never get told about it.

It also breaks the simplicity of the system.
The power system is extremely simple now. It runs on a simple first come first serve priority system, with certain systems allowed to draw less power.

 

Wow, another straw man. No, it really doesn't... We are just talking about one very annoying edge case here, not removing all thought from the game. Sorters would still have value after fixing this...

So, simplicity at the cost of all else? Even common sense? I have news for you; most problems don't have simple solutions. There are always edge cases and it does nobody any good to just ignore them...
If the best argument you can come up with is just that "it breaks simplicity, and I don't like that" then we really don't have much to talk about...

 

@101m4n I guess so, I can see where you are coming from, but I have seen countless threads about making everything easier, combining functionalities, etc.

Just saying, this is not a massive problem by itself, and to be honest, I'd rather see a different solution to the issue of clogging (clogging happens either way with building large quantities) and that is an auto purge from the assembler. If it is full of materials and the assembler does not have enough materials to build something, then it should purge itself and re-pull the required materials.

That fixes your issue, and it keeps the conveyor network nice and simple. It also fixes another related issue. Two birds, one stone.

EDIT: Yeah, simplicity is great. What is even better is when a multitude of simple systems creates something complex.

 

Sorter blocks alone dont resolve the issue. Sorter blocks allow us to move cargo to certain groups of containers, but asseblers would need to be able to pull from cargo containing ingots. If the assemblers are able to pull from a certain container group, then the container group can also push incoming cargo to the assemblers. Thats why I would like to see recieve priority implemented.

 

@Scorpion00021 Oh wow, I didn't think of that...
That makes this even more in need of a rethink.

 

Actually @Scorpion00021 your way of how you want to do it is backwards, not saying it is wrong and not trying to start an argument. Maybe is because I have years of real life experience connecting machinery as to my method of "madness".

 

@Scorpion00021 Yes, Sorter block alone actually resolve the issue, because you can guarantee that the first available cargo is a cargo container, no matter what, by using sorters as one way gates.
I almost always make a one way system.. Ore Container to Refineries, Refineries to an Ingot Container, Ingot Container to Assemblers, Assembler Container to a Component Container
But you can do it even easier.
A simple system with the cargo container in between refineries and assemblers... All you have to do...