I've found new issues:

First, the modules in the old building are not inserted into the new one.

Second, it can happen that more buildings are marked for deconstruction than new buildings are available in the logistic system. In my base I bring the new buildings via the train, sometimes only a single item at a time. As soon as this building is moved from the train into the a provider chest, several old buildings get marked for deconstruction. The problem is that the ghosts vanish before the next replacement building arrives with the train. Maybe you could place the infinite ghost like the ones from the blueprints. Then you could also include the modules.

Edit: I just discovered that the recycle recipes give 100% of the ingriedents back instead of only the half. Maybe you should also reduce the amount of scrap metal, the assembler 1 gives me 200 plates if dilapidated but requires only around 20 to craft (in the base game)

I'll look into the first and "edit" issues.

The bot replacement algorithm is a bit more complicated and will take some to work on. I ran into the problem you describe in testing. The current solution is simply to limit the bot replacements to 1 per interval, which is currently 6 seconds. So if it takes longer than 6 seconds for a bot to deconstruct an entity and retrieve the replacement, you'll have a potential situation where more than one old entities are competing over the same replacement. one thing you could try yourself is to increase the interval in the config file. The only disadvantage of this is that if you have lots of entities getting old faster than 1 per interval, your bots won't be able to keep up, although you'd have to have a very large factory for this to be a problem.

I'll see If I can figure ways to improve on the current system to be more robust.

See change log. I think I've addressed everything here. Please let me know if you spot any more issues. Thanks for the feedback!

Thanks for the great mod! :)

I just updated and started my world. After some time i get the following error:
Error while running event on_tick(ID 0)
WearAndTear/control.lua:235: attempt to perform arithmetic on field 'dob' (a nil value)

Just a guess: With the 1.0.9 update you added the cleanup utility where you use the global.replace_list table. This table was present before this update, hence there could be entries left, that do not have the "dob" field yet.

Yes that was probably it. I'll see about adding a migration file when I get back. You should be able to fix by adding

global.replace_list = {}

Somewhere near the top of the control.lua. Load your game, wait a few minutes and save. Then delete the above line from control.lua and load your game again.

Resetting the list helps.

I played now for several hours in my small world. It seems that all buildings are now replaced correctly. I did not see any gaps. I will test this also in the world where my train brings the buildings one after another, there it is easier to see if all works fine.

Assemblers keep their modules when they are changed to aging or old and when replaced by bots.

Assemblers with fluid input dont keep their orientation after being replaced by a bot. Changing from new to aging works

Edit: I could see that oil refineries and chemical plants lose their modules when degrading and being replaced.

I'll take a look. Hopefully get something pushed out today. Thanks again for all your feedback and testing!

EDIT: hmmm I just tested several different fluid machines including oil refineries and the modules are not being lost when degrading. Can you give any more information?

(orientation on assemblers is fixed and will be in next release)

Greetings, i created a small world:

https://www.dropbox.com/s/u31mz9os2a2ym59/Wear%20and%20Tear%20Test.rar?dl=0

I use the version 1.0.10 and modified only the config to reduced the required time from 60 to 2 minutes for degrading and deactivated the weartear.explosive_endings.

Every time I place efficiency or speed modules in the chem plant or refinery, they get lost once the building degrades.

I hope it happens for you in this world. Otherwise this bug would be very strange. What additional information do you have in mind? Should I uncomment all print statements and search for some kind of error message?

Then I have a small suggestion, could you add a way to restrict buildings from aging to the config file. For example the virtual miners used in the mining vehicles from erandel's aai mods crash the game as soon as they are replaced by the aging_xxx version. Or the dynamic-assembler mod stops working, when the building gets changed to the aging version.

Keep up the good work :)

Okay I think I've finally slayed this bug. The problem was I was relying on the vanilla "quick-replaceable-group" to update entities, which always correctly swaps out any modules, recipe, etc. But some entities are not properly tagged as quick-replaceable in the vanilla game, including chem plants and refineries. You can see this by trying to place a new chem plant on top of an old one. It won't let you. My game was working because I had other mods installed which added quick-replaceables to these entities. I've added logic to detect if there's a quick-replaceable list and if not, manually re-insert any modules and everything appears to be working.

TLDR: It's fixed now and will be uploaded in next release shortly.

I'll see about adding a "do no age" list to deal with incompatibilities.

See change log.

Module issue = fixed.
Compatibility with erandel's aai and dyanamic assembler = fixed
do_not_age_list = done

Hurray :)

I will test it now.

Edit: So far everything is working, I like the smoking solar panels :)

Edit2: I just launched my other world and the error with the "dob" field occured again (line 263 in control.lua).

The dob thing is the same problem as before. Honestly I'm not sure its worth the trouble to fix it as I would need to get into migration files that skip updates. (Not sure how works). It only effects people who had an old save from 3 updates ago and of those only with a save file that had in-progress bot work orders. I'm guessing that's just one person and you already know how to fix (reset the replace_list table.)

Seems legit