on_fast_replace event please

[bobingabout]

As per here:
viewtopic.php?f=23&t=65462&p=410120#p402765

is there any chance of an on_upgrade or on_fast_replace or on_upgraded, or even on_player_ and on_robot versions of them, that presents us with a read only version of the previous entity's information along with the same information as on_robot_built_entity and on_player_built_entity?

As stated, upgrade just calls the fast replace event, and fast replace doesn't maintain any custom information like inserter hand positions, so it would be good to be able to check a previous entity's information and copy it onto the new entity.

[Rseding91]

I would implement this but so far I can't find a way to make such an event where both the original and the new entity are in a valid state for mods to touch.

[bobingabout]

I would implement this but so far I can't find a way to make such an event where both the original and the new entity are in a valid state for mods to touch.

Read only on the old entity would be fine. But assuming that still isn't possible...

As previously discussed in source access on discord... if it isn't possible for a single event to give both entities information, is it possible to instead trigger an on_pre_fast_replace event before the old entity becomes invalid that gives us the old entity information, and have the modder be dependant on storing the needed information (entity type, surface and position, hand positions, filters etc) then looking at a following on(_robot)_built_entity event to see if entity type, surface and position match to determine if we're looking at the same entity?

[Recon777]

I would implement this but so far I can't find a way to make such an event where both the original and the new entity are in a valid state for mods to touch.

Read only on the old entity would be fine. But assuming that still isn't possible...

As previously discussed in source access on discord... if it isn't possible for a single event to give both entities information, is it possible to instead trigger an on_pre_fast_replace event before the old entity becomes invalid that gives us the old entity information, and have the modder be dependant on storing the needed information (entity type, surface and position, hand positions, filters etc) then looking at a following on(_robot)_built_entity event to see if entity type, surface and position match to determine if we're looking at the same entity?

Hey, Bob. So, they fixed it! What ended up changing? Was it a new event or something else that brought about the fix? I didn't notice it in the change log. Just happened to notice it in game because a friend of mine attempted to use an upgrade planner on an inserter and it actually worked!

[bobingabout]

I would implement this but so far I can't find a way to make such an event where both the original and the new entity are in a valid state for mods to touch.

Read only on the old entity would be fine. But assuming that still isn't possible...

As previously discussed in source access on discord... if it isn't possible for a single event to give both entities information, is it possible to instead trigger an on_pre_fast_replace event before the old entity becomes invalid that gives us the old entity information, and have the modder be dependant on storing the needed information (entity type, surface and position, hand positions, filters etc) then looking at a following on(_robot)_built_entity event to see if entity type, surface and position match to determine if we're looking at the same entity?

Hey, Bob. So, they fixed it! What ended up changing? Was it a new event or something else that brought about the fix? I didn't notice it in the change log. Just happened to notice it in game because a friend of mine attempted to use an upgrade planner on an inserter and it actually worked!

They didn't add an event. I guess they changed their mind about if it should retain settings on fast replace or not. Apparently it already did keep settings IF you replaced with the same entity, such as when you placed a fast inserter over another fast inserter, but facing a different direction.
I don't want to name names, but I brought up this topic in source access, and there was a bit of a debate between 2 devs if it should or shouldn't keep settings. Debates can be a good thing, it's not always an argument.

[kryojenik]

Just running into a desire to have this as well.

Particularly when dealing with custom / compound entities that don't have settings to "keep in place". Need to inspect the current situation and record state to apply to the newly placed entity(ies). I also noticed that robots do not fire on_robot_pre_mined befire the on_robot_mined_entity if the entity is being upgraded. Only when being destructed.