[1.1.6][Modding] Entity placeable_by Hidden Dependency on Item's Order

[DedlySpyder]

I recently switch my Generic Logistic Chest mod to using placeable_by instead of using my own implementation of this logic for ghosts, upgrades, and pipette. This mod allows the player to place a "generic" chest and switch it to any other logistic chest (specific "replacement" chests under the hood). The replacement chests have a placeable_by of the generic chest.

This all works fine in a vacuum, but if another mod changes the sort order of the items, and the replacement chests end up further ahead, then the whole mod breaks when trying to use blueprints. From what I can tell, the robots will try to build a ghost from the first item in the LuaEntityPrototype.items_to_place_this array, which appears to be sorted solely by order.

Can placeable_by have an optional priority order so we can manually arrange this array? By default anything without a priority would be at the end of the array using the current sort, so as to not break anything that current relies on this. At very least I would like something to say "this is number 1" for one of them, since only the first one really seems to matter.


This can be seen with my mod at version 0.5.0 and aai-containers. On my own the mod works, with aai-containers blueprints cannot be built. I updated the order in version 0.5.1, but I'd much prefer some explicit way to specify this for the future.

Mod link: https://mods.factorio.com/mod/Generic_Logistic_Chest
AAI Containers: https://mods.factorio.com/mod/aai-containers

[eradicator]

As far as i understood what @Rseding91 said in this thread there can only be one item that bots use to build an entity. The array is meaningless. And if you rely on that it's probably easier to just make sure (data-final-fixes?) that your entities are placeable by exactly one item.

[Klonan]

moving to modding interface requests

[DedlySpyder]

As far as i understood what @Rseding91 said in this thread there can only be one item that bots use to build an entity. The array is meaningless. And if you rely on that it's probably easier to just make sure (data-final-fixes?) that your entities are placeable by exactly one item.

I did see that, but there is only 1 entry in the placeable_by property for these entities (even with aai, that just changes the sort order and other properties).

I only need 1 item in the array, but Factorio is merging in the items that have a place result on its own.

moving to modding interface requests

I do believe this is a bug and not a new request.

If I set placeable_by to 1 item, the game is overriding it under the hood. The current property is unreliable if I also have an item that places it.

[eradicator]

I only need 1 item in the array, but Factorio is merging in the items that have a place result on its own.

If I set placeable_by to 1 item, the game is overriding it under the hood.

After final-fixes all data stage data is pre-processed and normalized into it's runtime form. Data stage entity prototypes only contain part of the list, not an override. Runtime stage LuaEntityPrototype.items_to_place_this has the full list. And if you want to influence the order of that list that's a request.

I can see use cases for allowing multiple items to place an entity, so i'd even +1 the request. But if for your case you really just want one item then... have you tried just removing place_result from all item prototypes in data stage?

[DedlySpyder]

What this is depends on what the goal of placeable_by is. Is it just another way to say place_result, but from the entity side of things? Or is it actually different.

If it's supposed to be an override (which is how the wiki reads to me), then this is a bug:

Determines which item is picked when "Q" (smart pipette) is used on the entity, determines which item is needed in a blueprint of this entity.

https://wiki.factorio.com/Prototype/Entity#placeable_by


My situation needs the items to be useable as is, so I can't just remove them. For the moment I am just manipulating the sort, but that's not optimal.

[eradicator]

What this is depends on what the goal of placeable_by is.

Given that there is only a single vanilla usage - the curved rail - the goal is most likely to allow bots to build entities that can not be hand build (very useful indeed!). And whoever implemented it probably thought "if i make it an array then maybe in the future bots can be expanded to choose from a list of allowed items", except that nobody has upgraded the bots yet.

If you have several items that place the same entity you don't really need placeable_by. Except for the "order" problem. But that too would be solved if bots were array-aware wouldn't it?

[DedlySpyder]

If you have several items that place the same entity you don't really need placeable_by.

Except that then blueprints are just chosen by whichever is first in the sort order, so if you want any kind of control over that you'd need something.

And yes, all of this would be solved if the bots were array-aware and could use any arbitrary number of items to place an entity, but that is likely a much larger change than just letting us specify "THIS is the one I want for pipette and blueprints", aka, first in the array.

I just don't want this bug/request turned down because it reads as I need to change how bots work, manipulating the array works for my use case if the bot change is too much.

[Deadlock989]

What this is depends on what the goal of placeable_by is. Is it just another way to say place_result, but from the entity side of things? Or is it actually different.

I use it in a couple of situations (a turret, a pseudo-lamp) where the entity is considered a variant of another entity. When I say variant, I mean it is functionally identical to the main entity with at most one relatively small difference in properties, maybe even just purely visual. Because the variants cannot be placed directly by any item, the entity needs some method of specifying that it can be revived from the "main" entity's item that it is a variant of. For me, the wiki section is correct: if I pipette the variant I get the correct ghost item in my hand. Perhaps some hotkey or a scripted event on placement than handles which entity actually exists in the world. For blueprints, the correct variant is "blueprinted" because blueprints contain entity info and the variant entity is therefore represented in the blueprint, but the ghosts still need to know which item is used to revive them.

I admit I'm confused about what the mod described above actually does, it sounds like it is a generic chest that can be cycled between variants. I would have thought placeable_by works just fine for this case but maybe there is some wrinkle I'm not understanding.

[DedlySpyder]

I admit I'm confused about what the mod described above actually does, it sounds like it is a generic chest that can be cycled between variants. I would have thought placeable_by works just fine for this case but maybe there is some wrinkle I'm not understanding.

I think the difference between our uses is that the generic chest variants can be placed by items in my mod. The items have place_results and are added to the placeable_by items under the hood (LuaEntityPrototype.items_to_place_this). This can mean that I am setting placeable_by to one item, but it's not working because it then adds the other item and sorts by order. So, if the variant (implicit) item is a lower order than the item I manually set, it will not work.

The player can't craft the variants, but I have a control that will let them scroll through the options in their cursor and change to the other items. But I change it back when they are done, so they (should) never have the variants in an inventory.

[Rseding91]

I'm not quite sure I understand what the issue is here or what you're asking for as a fix. But did you know about the item prototype flag "primary-place-result"?

[PFQNiet]

I'm not quite sure I understand what the issue is here or what you're asking for as a fix. But did you know about the item prototype flag "primary-place-result"?

I know it exists but it, and "can-extend-inventory" have absolutely no documentation on the wiki so I have no clue what they do or what they're for.

[Rseding91]

I'm not quite sure I understand what the issue is here or what you're asking for as a fix. But did you know about the item prototype flag "primary-place-result"?

I know it exists but it, and "can-extend-inventory" have absolutely no documentation on the wiki so I have no clue what they do or what they're for.

When set on an item; that item always comes first in the items-to-build-this on an entity. So you can force a specific item to be the one that the game tries to use to build something.

[DedlySpyder]

...

When set on an item; that item always comes first in the items-to-build-this on an entity. So you can force a specific item to be the one that the game tries to use to build something.

Awesome, this covers my use case then.

[Anachrony]

When set on an item; that item always comes first in the items-to-build-this on an entity. So you can force a specific item to be the one that the game tries to use to build something.

I don't suppose there is a way to do the opposite. If multiple things are "placeable_by" the same item, and you blueprint them, force it to build the default thing that it places and not the other entity/tile. I often run into variations of this situation when I use placeable_by, but some of them I can work around in scripts. However, I have a problem with my Safe Waterfill mod that I'm not sure I can work around.

To get around the issue of water tiles instantly destroying anything on land, I have it place a tile with no collision, and then have a script decide to either replace it with water, or revert it to the original tile, based on whether that tile could collide with anything. This works when the player places waterfill, but if I blueprint the water and have bots place it, then it places the water tiles directly, destroying stuff and defeating the purpose of the intermediate tile. I can see the benefit of having the blueprint place the right thing normally, but in this case I'd prefer it to place the thing that the item says it places, and not other placeable_by things. I think my only option right now is to allow a mod setting that makes water tiles un-blueprintable, so bots can't place it at all. I'd rather have a way for bots to still be able to place waterfill without killing stuff.

[Anachrony]

However, I have a problem with my Safe Waterfill mod that I'm not sure I can work around.

I did find a workaround here, which is that in this case it always create a tile-ghost entity first before it creates a tile, so I can intercept it there.