[MOD 0.17] Deadlock's Crating Machine

[Deadlock989]

Hi ssilk,

I agree with some of your points. This was my first mod and I only started modding Factorio because I wasn't happy with any of the other crating/palleting mods. So the balancing is a matter of personal preference. I'm not trying to please everyone.

The issue with putting more items into a crate is that belts become more and more powerful. 50 items in a crate means a yellow belt has the throughput of 50 yellow belts. I don't think that's balanced, or at least, it's not the way I want to play. So it's not changing. There are constants available in the code which are easy to change if you want your own local version. I'm not exactly sure what you mean by a "one-belt factory" but it sounds OP to me.

Not having any inventory compression - e.g. no locomotive advantage - is deliberate and it definitely won't change. Belts and inserters already get a huge boost from crates, so inventories don't need one as well. Things don't magically get smaller when they go into a box. There are plenty of other mods which boost inventory capacity and buff cargo wagons. Likewise, I certainly don't think bots need any boosting. These are opinions.

I'm not reducing the size of the machine to 2x2 after a year or more of the mod being out there. It would break too many saves. Nor am I doing any more work on the graphics for this mod.

I agree that too much wood is required. The mod was originally designed so that any of the three vanilla chests could be used, i.e. you could have iron or steel crates as well. But that just led to massive crafting tab bloat and super-confusing recipe/icon situations, so it got left by the wayside. In most of my savegames I'm swimming in wood and desperate to get rid of it. Then I built my first crate-driven 1000 SPM base and spent god knows how long destroying forests ... I don't have an immediate solution to it but to be honest I've moved on from crates.

I absolutely don't see the need to crate chests. Effectively you're asking to crate crates. They're not the TARDIS. This isn't Inception.

This mod is in caretaker mode only. Someone else can do a better job if they like.

[mrvn]

I don't think he mend crating filled chests but crating empty chests. So you have a smaller downstream of empty chests compared to your upstream of crated items.

As for train: Even if you can't fit more items into a cargo wagon the loading and unloading gets sped up. And with trains staying in station for a shorter time you can send more trains per minute to each stop and therefore throughput is improved.

[ssilk]

The issue with putting more items into a crate is that belts become more and more powerful. 50 items in a crate means a yellow belt has the throughput of 50 yellow belts.

Well, I respect your opinion, but I think you are focusing to the wrong aspects.
It's ridiculous to use 50 yellow belts. Instead I would use 16 blue. That would cost of course much more, but the aspect you forget here is the belt speed: Things get faster from A to B. This is important, cause the problem with all the crates on the belts is the ridiculous amount of storage you become, just with the items on the belts.

So even when you make a long calculation in the docs, where you explain how you calculated the balancing, I would even then use blue belts, cause when you use a boxing-like-mod my experience shows clearly, that then the target must be to have more or less clean belts. Produces just in time. Not more than needed.
You need fast transport either by blue belts or robots, cause you should try to avoid long queued up items on belts or in chests.

I don't think that's balanced, or at least, it's not the way I want to play. So it's not changing.

Well, that depends on, what you want to play of course. I think it changes everything.
[/quote]There are constants available in the code which are easy to change if you want your own local version.[/quote]
That was my reason to write that article, cause I experimented around with it. I recomend eventually implementation into settings - even knowing that changing needs restart.

I'm not exactly sure what you mean by a "one-belt factory" but it sounds OP to me.

Well, "one-belt" is wrong, the rigth term is single-belt-factory. I found this one:
https://www.youtube.com/watch?v=zMXfplW7xyk
https://www.reddit.com/r/factorio/comme ... t_factory/
I have tried to play such a game with boxing and - well - that was a very interesting game... sorry, the old saves don't run anymore with 0.17.

Not having any inventory compression - e.g. no locomotive advantage - is deliberate and it definitely won't change. Belts and inserters already get a huge boost from crates, so inventories don't need one as well. Things don't magically get smaller when they go into a box. There are plenty of other mods which boost inventory capacity and buff cargo wagons. Likewise, I certainly don't think bots need any boosting. These are opinions.

Well, I have different opinion on that: There is no big boost, cause in most cases you cannot use the full capacity then, cause it will find other bottlenecks of your factory, which limits the throughput. It is not just "if you increase the wagon capacity you have a big advantage". That's not the case.

I'm not reducing the size of the machine to 2x2 after a year or more of the mod being out there. It would break too many saves. Nor am I doing any more work on the graphics for this mod.

I understand that.

[Deadlock989]

So even when you make a long calculation in the docs, where you explain how you calculated the balancing, I would even then use blue belts

That back-of-an-envelope calculation does use blue belts.

Belt speed is secondary here. What matters is throughput. Yellow, blue, pink with epileptic strobing, doesn't matter - the crate size multiplier also multiplies the throughput of all belts. With a crate size of 20 for iron plates, yellow belts start to deliver the equivalent of 300 plates/s. Blue belts, 900 plates/s.

Belts are like canals. It literally doesn't matter how long the canal is, as long as it is full of barges end-to-end. Items effectively arrive instantaneously as long as you can maintain compression. What crates change is the throughput, and they already change it massively. I don't want to be the author of a mod which gives players the ability to deliver 100 times as many items at once at little extra cost. It's not just belts: all inserters become mega-stack-inserters. This mod is not underpowered in any way. If anything, it would be ridiculously OTT if it weren't for the massive pain in the arse of cutting down a continent sized forest to run even a small megabase's worth of belts.

It was really finished a year ago and I won't be making any big changes. I don't even use it in my own games any more. I'll help shanemadden fix bugs - he has taken over Stacking Beltboxes and if he wants to extend the full API from that to Crating as well, he's welcome to, but I would totally understand if that didn't seem like a good use of his time.

Otherwise it's GNU GPLv3 and all that implies.

[MavePlcavDH]

Nice Mod, it really helps me a lot.
However, I meet a bug caursing game crash when I enable this mod with Yuoki industry and BigBags.
The error message:

Error while loading recipe prototype "deadlock-packrecipe-y_rwtechsign" (recipe): Difficult normal:Value outside of range in prototype tree at ROOT.recipe.deadlock-packrecipe-y_rwtechsign.ingredients[1].amount

The error woun't appear when I disable BigBags.

BigBags can increase the stack size of some items. So I think maybe Yuoki's item stack size cause the error. I really hope you can fix the problem.

[Deadlock989]

Nice Mod, it really helps me a lot.
However, I meet a bug caursing game crash when I enable this mod with Yuoki industry and BigBags.
The error message:

Error while loading recipe prototype "deadlock-packrecipe-y_rwtechsign" (recipe): Difficult normal:Value outside of range in prototype tree at ROOT.recipe.deadlock-packrecipe-y_rwtechsign.ingredients[1].amount

The error woun't appear when I disable BigBags.

BigBags can increase the stack size of some items. So I think maybe Yuoki's item stack size cause the error. I really hope you can fix the problem.

That's a new one.

How much of an increase in stack size are we talking about? It sounds like we have three multipliers going on here - the Yuoki stack size, multiplied by BigBags, then multiplied again by Crating to make the packing recipe. If that goes over 65,535 then it's an illegal recipe. Can you give me some numbers?

[mrvn]

So even when you make a long calculation in the docs, where you explain how you calculated the balancing, I would even then use blue belts

That back-of-an-envelope calculation does use blue belts.

Belt speed is secondary here. What matters is throughput. Yellow, blue, pink with epileptic strobing, doesn't matter - the crate size multiplier also multiplies the throughput of all belts. With a crate size of 20 for iron plates, yellow belts start to deliver the equivalent of 300 plates/s. Blue belts, 900 plates/s.

Belts are like canals. It literally doesn't matter how long the canal is, as long as it is full of barges end-to-end. Items effectively arrive instantaneously as long as you can maintain compression. What crates change is the throughput, and they already change it massively. I don't want to be the author of a mod which gives players the ability to deliver 100 times as many items at once at little extra cost. It's not just belts: all inserters become mega-stack-inserters. This mod is not underpowered in any way. If anything, it would be ridiculously OTT if it weren't for the massive pain in the arse of cutting down a continent sized forest to run even a small megabase's worth of belts.

It was really finished a year ago and I won't be making any big changes. I don't even use it in my own games any more. I'll help shanemadden fix bugs - he has taken over Stacking Beltboxes and if he wants to extend the full API from that to Crating as well, he's welcome to, but I would totally understand if that didn't seem like a good use of his time.

Otherwise it's GNU GPLv3 and all that implies.

I think you missed the part about keeping lees items on the belt to avoid the ridiculous buffer capacity.

Every belt holds 8 crates, each crate holds 20 items. So a 1000m yellow belt takes 160000 iron plates to fill. Now 3 yellow belts take 480000 to fill while a blue belt still only takes 160000 items. Same throughput but you only have to produce 1/3 the amount before the items arrive.

But seriously guys. That's all startup costs. Once the belt is full it doesn't matter if its 3 yellow belts or one blue belt. And if you are actually using 3 yellow belts worth of throughput then half a million iron plates quickly becomes irrelevant.

And if you are not using the full throughput then consider using circuit logic to fill the belt only to a degree or don't stuff so much items into the crating machines in the first place. If you don't produce it then the belt can't buffer it. If you put one crate per second on a belt you get 1 crate a second on the other end, as Deadlock mentioned. The time for the first crate to arrive is just startup cost.

Where this becomes really fun is when you combine different crates on the same belt. Put up wires between your factory complexes so they can request items. And then you put crates of different items on a common belt in the ratios the factory complexes requests. Each complex can then take off a few crates. So you don't use a yellow belt to compress 20 iron plate belts into one. But to compress a bus full of all items that hardly moves into a single belt that's partially full.

[Deadlock989]

Nice Mod, it really helps me a lot.
However, I meet a bug caursing game crash when I enable this mod with Yuoki industry and BigBags.
The error message:

Error while loading recipe prototype "deadlock-packrecipe-y_rwtechsign" (recipe): Difficult normal:Value outside of range in prototype tree at ROOT.recipe.deadlock-packrecipe-y_rwtechsign.ingredients[1].amount

The error woun't appear when I disable BigBags.

BigBags can increase the stack size of some items. So I think maybe Yuoki's item stack size cause the error. I really hope you can fix the problem.

That's a new one.

How much of an increase in stack size are we talking about? It sounds like we have three multipliers going on here - the Yuoki stack size, multiplied by BigBags, then multiplied again by Crating to make the packing recipe. If that goes over 65,535 then it's an illegal recipe. Can you give me some numbers?

OK this is not a straightforward one at all.

Yuoki provides an object called a "Techanic Sign" which is handed out as an extra result in a whole bunch of recipes as some sort of reward or trading token (I don't know anything about Yuoki Industry but this is just from reading the code). It has a stack size of 100,000.

Big Bags then applies a multiplier to every stack size in the game willy-nilly, I don't know what the default is, but let's say it's 5. That's a stack size for those tokens of 500,000.

Crating breaks stacks up into 5, so the ingredients for a stack could easily go over the magic 16-bit value if any of these zany items have been added to a vanilla recipe.

I can't do anything about the design of these other mods - IMHO it's madness to be assigning stack sizes to things which are way beyond the limit of ingredients for a single recipe - but I can add a check to make sure that the numbers are sane when Crating makes a crate, and to abandon it if it can't deal with it.

[Deadlock989]

The stack size overflow issue is fixed in the latest version on the mod portal - items with humongous stack sizes are skipped and a note is put in the log.

[Linver]

in the 0.17.35 u must update "player" entity name to "character" like this https://www28.zippyshare.com/v/1r6YxI5w/file.html
(for who want continue playing meanwhile)

[shanemadden]

1.4.9 update to fix for Factorio 0.17.35 should be published in a moment.

[Mernom]

It's too bad to hear that the mod is not in development anymore. I've never used it, but I love the beltbox mod.
I'm currently working on a compatibility mod for Space Exploration (AAII version done), and not having a function to add tiers is a bit rough... SE adds a space tier of items which have identical states to T3 items, but is allowed to be built in space (normal versions are blocked).
I guess I'll gonna have to make my own machine... Wish me luck.

[Deadlock989]

It's too bad to hear that the mod is not in development anymore. I've never used it, but I love the beltbox mod.
I'm currently working on a compatibility mod for Space Exploration (AAII version done), and not having a function to add tiers is a bit rough... SE adds a space tier of items which have identical states to T3 items, but is allowed to be built in space (normal versions are blocked).
I guess I'll gonna have to make my own machine... Wish me luck.

You can use the DCM API to add crating unlocks to any technology you specify, see the readme. So you could create a Space Crating technology or whatever, and then add the space-specific crating unlocks to that.

Edited to add, for some reason the readme doc is missing from the zip file, probably because the part for beltboxes is a bit out of date. Everything still applies for crating though. It's attached.

[Mernom]

I need a new machine as well though.

[Deadlock989]

I need a new machine as well though.

Then copy an existing one and modify it.

[ssilk]

So even when you make a long calculation in the docs, where you explain how you calculated the balancing, I would even then use blue belts

[...]
Belt speed is secondary here. What matters is throughput. Yellow, blue, pink with epileptic strobing, doesn't matter - the crate size multiplier also multiplies the throughput of all belts. With a crate size of 20 for iron plates, yellow belts start to deliver the equivalent of 300 plates/s. Blue belts, 900 plates/s.

Belts are like canals. It literally doesn't matter how long the canal is, as long as it is full of barges end-to-end. Items effectively arrive instantaneously as long as you can maintain compression. What crates change is the throughput, and they already change it massively. [...]

I think you missed the part about keeping lees items on the belt to avoid the ridiculous buffer

... deleted explains calculations that you need a third less items for startup before first items arrive ...

That was exactly the point that I was aiming for: there is a big difference between aiming belts for throughput or for transport. Throughput is: when you fill the belts fully compressed and all items you put onto a belt are used on the other side immediately. With “transport” I mean when a belt is not fully compressed, because it is a mining-field for example: it has a limited production capacity and in that case it makes sense to bring the items from a to b ASAP.

So, that was basically the argument with the express belts. I changed the defaults and added some combinator logic to limit storage-on-belt and was fine.

I found a week ago your mod https://mods.factorio.com/mod/deadlock- ... es-loaders
Haha, I seriously had overseen it. For the game I’m currently aiming for I think it’s perfect. And cause I’m aiming for a game that brings trains to their limits I’m thinking about expanding the creating machine to crate already compressed items.

... so normally I would stop here, but I wanted to explain this thought a bit more.

That would increase capacity of the chests by factor 10 - I think. But it’s really complicated to handle - and in that it is a “fair” usage: the idea is to compress the belts coming from big mining fields, bring them all together in the outpost station and there to compress them a second time into the boxes. Then load the trains (uncompressed currently ~12 trains per minute on four stations) bring them to the smelters and uncompressed everything. And so on.

I think in the end it should increase throughput a lot and also increase FPS. And it adds a new level of logistic, cause you need to transport all those empty wooden chests back by train. I think also, that - I mean compressing really much items - this is the (only) way to enable really big factories without getting always to the limits. For example I need to increase the rail network all the time, fix deadlocks, repair belt-bottlenecks and so on and with this compression all that is not needed and you can concentrate much more on expansion. And - last argument - this new type of “double compression” is much more worth playing around with, because it increases the number of possible factory-setups such a lot. I mean - think for example to a smelting area: compressed boxes come in, are unpacked to compressed items and splitter to several smaller belts, then unpacked. Alone the way you can now feed the smelters! Feed them directly from belt, or feed them by loader or directly from the decompressor? That gives you so many new opportunities to create a cpu-friendly, space efficient smelting facility, it’s incredible!

Any comments?

[Deadlock989]

If people want to experiment with values in their own local copy of the mods to produce inventory compression, stacked crates, crated stacks, crated crated stacked stacked crate stacks, anything they like - I'm all for it.

[mrvn]

I would like it if one could crate stacks and uncrate to stacks. That doesn't mean there should be a density increase. I see a few options:

1) additional recipes for stacks of items -> crate of items and crate of items -> stacks of item with the same item count as without stacks. You could crate coal at the mine and then uncrate them to stacks of coal at the smelter for more dense fuel.
2) replace recipes with items -> stacks of items -> crate of items and crate of items -> stack of items -> items. So you need both a beltbox and a crating machine.
3) additional recipes for crates of stacks of items. No need to unstack items to crate them and to restack items after uncrating. But no conversion.

[Deadlock989]

I would like it if one could crate stacks and uncrate to stacks.

One can. Both mods have all the hooks you need to do this for yourself. A handful of lines of code should do it. But it isn't going into the base mod. This is at least the third time I have told you this. I will ignore any fourth, fifth or sixth repetitions.

[mrvn]

I would like it if one could crate stacks and uncrate to stacks.

One can. Both mods have all the hooks you need to do this for yourself. A handful of lines of code should do it. But it isn't going into the base mod. This is at least the third time I have told you this. I will ignore any fourth, fifth or sixth repetitions.

And I never ever, not once, asked you do add anything like that to the base mod. So you telling me you won't do something I didn't ask for is pointless. Thanks for stopping.