Permit some slow game.item_prototype values to be RW
Posted: Tue Jan 28, 2020 2:58 pm
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.
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.