Permit some slow game.item_prototype values to be RW

[Honktown]

Specifically, place_result would be the first one I would like to see be RW:

If someone wants to replace entities (upgrade behavior, values, etc) in a a game-transparent way, they normally can mostly do that, however, now they have to add a new recipe, prototype, and monitor as many events as necessary. In the case of on_built_entity and on_player_built_entity, the entity can have the prototype mining_result be the original item, while control events/tables have to have checks for every situation when an entity can be placed (including created by mod or revived from ghost). One would always have to find_entities_filtered across surfaces and convert them over.

This is related to changing a single value of an entity:
viewtopic.php?f=25&t=80508

My thought process is that entities placed/mined are probably integers that refer to entities in a const struct. The only modification would then be to make the entity referred to non-const. Certain other things I could imagine are pseudo-compiled or literally compiled into const functions after the data phase, for performance reasons (maybe burner leech awareness is more flexible). If that's the case, then it would sound silly to compile the mining/place results logic, as the only difference is what gets placed, and every entity has different error conditions.

Things to watch for: a robot would bring the original item required for building, and on placement it gets changed. I don't see any problem here, as place_result is an item_prototype spec, the item is not actually changing.

Robot building would be related to https://forums.factorio.com/viewtopic.php?f=28&t=80552 . Implementing both of these would make the item and entity placement/blueprinting process completely transparent as far as I can see.

Opening up a few values to RW might be worth thinking about, as there are some that are probably not hard-coded into performant functions. A quick glance over the wiki makes me think of burnt_result, emissions multiplier, rocket_launch_product. Entities could have a few values RW. Speed: it needs to be calculated all the time anyway for movement logic if it's not compiled directly into entity-specific movement functions (armor can change speed on a per-entity basis for example, so there's at least one very indirect cost there). Infinite_resource: the resource entities can be one-time replaced normally, but it still requires a new prototype and proper map_gen settings and other things of which I'm sure I'm not aware. New resource entities would have to be watched for, too, as they're discovered, while a RW entity prototype value would be a one-time difference. Minable properties, heal_per_tick (not ups friendly), and entity prototypes damage or attack prototype... all sorts of things could be RW that already have dynamic components, drastically streamlining modifications.

I'd like to hear if someone else has ideas (good or bad) or currently-fixed values they wished were RW.

[posila]

Prototypes get loaded at the startup of the game and during lifetime of the game won't change. That's an invariant that's never gonna change.

Things to watch for: a robot would bring the original item required for building, and on placement it gets changed. I don't see any problem here, as place_result is an item_prototype spec, the item is not actually changing.

I am not sure if I am interpreting this correctly, but it seems to me you assume an item captures state of its prototype when the item is created? Most items are just ItemID (which is PrototypeID of ItemPrototype) and count. There is optional pointer to extra data for items that have some dynamic content (armor, blueprints, damaged items, ...) but it is assumed most items don't have extra data.

[Honktown]

...That's an invariant that's never gonna change.

Damn. That actually sucks kind-of a lot.

Things to watch for: a robot would bring the original item required for building, and on placement it gets changed. I don't see any problem here, as place_result is an item_prototype spec, the item is not actually changing.

I am not sure if I am interpreting this correctly, but it seems to me you assume an item captures state of its prototype when the item is created? Most items are just ItemID (which is PrototypeID of ItemPrototype) and count. There is optional pointer to extra data for items that have some dynamic content (armor, blueprints, damaged items, ...) but it is assumed most items don't have extra data.

An item is an item is an item. Only the functions need to know what an item can do, embedded into the function or by pointer to (currently const?) prototype information. I assume when a blueprint is created, it stores the entity (obviously) and maybe the item required for building, and when a blueprint is placed, the game either uses the stored item in the blueprint or determines which item is required for building (either an optimized path or however place_result is stored).

Brings up an interesting question, what does a robot do if more than one item has a place_result for the blueprint entity?

[Honktown]

Nevermind on the question, I see there's a function to retrieve items which can place it in the luaentityprototype. Nice touch.