THanks Aradplaug
Here's a summary of the extra features:
ALIEN LOOT, UNIVERSAL SPARE PARTS, AND INHIBITOR TOXIN
Aliens drop alien goo as loot. (a lot of it). This goo is quite useful. It's a key ingredient in producing universal spare parts. Universal spare parts can be used to refurbish any "old" machine into a brand new one. Refurbishers (and recyclers) are special assembling machines which scan chests that feed them and automatically set it's recipe to recycle/refurbishing anything brought to it. In this way you can 100% automate all of the machine replacements in your base.
Alternatively, you can use any leftover alien loot to manufacture inhibitor toxin. Feed the inhibitor toxin into a special boiler, it will dump toxic emissions into the atmosphere. These emissions, once built up to sufficient levels, will slow down or even temporary halt evolution process. This is an effective way to prevent the enemy from overpowering your base, giving you more time in marathon games. The bug GUI can be clicked for more information. To prevent waste, you should generally continue dumping toxins into the atmosphere until the bar completely fills up. Colors of GUI bug are as follows.
Red: No effect. aliens are evolving at normal speeds.
Yellow: aliens are evolving, but at slower speeds.
Green: alien evolution is suppressed.
Orange: Although you have developed sufficient toxin levels, aliens are resisting the effects and are evolving anyway.
[MOD 0.15] Wear and Tear (plus automated maintenance)
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
***Update: 1.3.7***
Inhibitor toxin is now quite hazardous, both to you, and to the enemy. Best keep your distance from toxin emitters. The good news is: you can now use the emitters as part of your defensive system.
Inhibitor toxin is now quite hazardous, both to you, and to the enemy. Best keep your distance from toxin emitters. The good news is: you can now use the emitters as part of your defensive system.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
***Update 1.3.8****
I decided I should make the inhibitor toxin a little easier to work with, especially as a weapon. So.....
- You can now toggle the vents in the toxin boilers on/off. Mouse over the boiler and press CTRL-V. When the vent is closed, toxin will not be released into the atmosphere. It will instead build up inside the boiler, just like steam in the steam boiler. Now this deadly steam toxin can be transported to other locations and used against the enemy.
- Ordinary pipe sections now have vents. Or, more specifically, END-pipe has vents. You can toggle these vents open/closed the same way. (mouse over and press CTRL-V). So..... boil the toxin, transfer the deadly steam to your borders via pipe, and open the vent on that pipe. Stand back watch the carnage....
- Just for the hell of it, I decided to extend this functionality to all gases. Any gas that's in a pipe can now be dumped into the atmosphere be pressing CTRL-V on the pipe to open the vent. Warning: Dumping raw gas into the atmosphere is really bad for the environment. Don't let liberals catch you doing this. heh
I decided I should make the inhibitor toxin a little easier to work with, especially as a weapon. So.....
- You can now toggle the vents in the toxin boilers on/off. Mouse over the boiler and press CTRL-V. When the vent is closed, toxin will not be released into the atmosphere. It will instead build up inside the boiler, just like steam in the steam boiler. Now this deadly steam toxin can be transported to other locations and used against the enemy.
- Ordinary pipe sections now have vents. Or, more specifically, END-pipe has vents. You can toggle these vents open/closed the same way. (mouse over and press CTRL-V). So..... boil the toxin, transfer the deadly steam to your borders via pipe, and open the vent on that pipe. Stand back watch the carnage....
- Just for the hell of it, I decided to extend this functionality to all gases. Any gas that's in a pipe can now be dumped into the atmosphere be pressing CTRL-V on the pipe to open the vent. Warning: Dumping raw gas into the atmosphere is really bad for the environment. Don't let liberals catch you doing this. heh
- 20170906135332_1.jpg (866.11 KiB) Viewed 8814 times
- 20170906135407_1.jpg (665.39 KiB) Viewed 8814 times
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
That toxin is interesting. Although I dont play with it currently (the mods I have now are hard enough), I plan on doing so. Especially with a personal assistant.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
I do hope that venting nitrogen or oxygen won't cause environmental havoc, especially since I've most likely just pulled them out of the atmosphere.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Hi withers,
after some time playing with wear and tear i decided to start working on a german locale. A few days ago i discovered that prefixes like "old", "dilapidated" and so on are hardcoded and the result of some serious amount of string operations. To gain the ability for the localisation of the aforementioned prefixes i propose to change some lines of the "create_new_library" function:
Basically, the localised_name of an entity can be assigned like this:
This refers to the base locale in order to get the localised name of the entity and requires only the following short addition to the en-locale of your mod:
Adding this allows for full localisation of all age prefixes and provides some kind of flexiblity for other languages as well (e.g. "New __1__" might be changed into something like "__1__ (New)")
What do you think about this? I added an example on how a localisation friendly function might look like:
after some time playing with wear and tear i decided to start working on a german locale. A few days ago i discovered that prefixes like "old", "dilapidated" and so on are hardcoded and the result of some serious amount of string operations. To gain the ability for the localisation of the aforementioned prefixes i propose to change some lines of the "create_new_library" function:
Basically, the localised_name of an entity can be assigned like this:
Code: Select all
aging_entity.localised_name = {"weartear.aging", {"entity-name."..data.raw[type][entity_name].name}}Code: Select all
[weartear]
new=New __1__
aging=Aging __1__
old=Old __1__
dilapidated=Dilapidated __1__
recycle=Recycle __1__
refurbish=Refurbish __1__What do you think about this? I added an example on how a localisation friendly function might look like:
Proposed new version of the library function
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Hi Arcitos
The only issue with what you propose is that it creates a problem with my notification system. Currently you get a notification when a machine becomes "old" which appears on the map and as an icon on the bottom of the screen. When you mouse over this icon, you get a flavor text message with something like "_x_ machine needs service" where x is the name of the machine. The problem is as that, far as I can tell, there is no way to directly access the RESULT of localized names during runtime. I researched this before and (after much pulling hair out), found out the factorio devs did this intentionally to prevent de-synchronization in multiplayer. As a work around, I just had the 2nd element of the table be what I wanted to call the machine (ie entity.localised_name[2]).
With your proposed changes, that element becomes a table, and since we can't access the output of loc names directly at runtime, theres no way get the correct name to put in the notification. You can see the problem on line 183 of control-wt. Under your proposal entity.localised_name[2] becomes a table and it needs to be a string.
This all being said, I must admit, localized names is the topic I find most confusing in their API, so perhaps there is a way to make that work. I just don't know what that is.
withers
EDIT: Hmmm. Actually I see that add_custom_alert lets you use localized strings. Let me see what I can do.
The only issue with what you propose is that it creates a problem with my notification system. Currently you get a notification when a machine becomes "old" which appears on the map and as an icon on the bottom of the screen. When you mouse over this icon, you get a flavor text message with something like "_x_ machine needs service" where x is the name of the machine. The problem is as that, far as I can tell, there is no way to directly access the RESULT of localized names during runtime. I researched this before and (after much pulling hair out), found out the factorio devs did this intentionally to prevent de-synchronization in multiplayer. As a work around, I just had the 2nd element of the table be what I wanted to call the machine (ie entity.localised_name[2]).
With your proposed changes, that element becomes a table, and since we can't access the output of loc names directly at runtime, theres no way get the correct name to put in the notification. You can see the problem on line 183 of control-wt. Under your proposal entity.localised_name[2] becomes a table and it needs to be a string.
This all being said, I must admit, localized names is the topic I find most confusing in their API, so perhaps there is a way to make that work. I just don't know what that is.
withers
EDIT: Hmmm. Actually I see that add_custom_alert lets you use localized strings. Let me see what I can do.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Just had a crash checking the wear state of a modded steam engine. Haven't had time to hunt around for the cause.
I don't know if this has been suggested yet, but there's a specific family of machines in Yuoki's mods - mastercrafted machines - that if I understand the concept are intended to be at least dramatically more robust if not effectively immune to wear. The differences are quite striking in the artwork - no sign of wear, rust, dirt, etc. that were in the base machine sprite before upgrading, all fittings polished to a high shine. Also, effectivities and speeds are generally noticeably higher than the base machine. I think most of them can be distinguished by a y-mc-* identifier prefix but I'm not certain.
Code: Select all
Error MainLoop.cpp:940: Exception at tick 1673353: Error while running event WearAndTear::check_age (ID 86)
__WearAndTear__/control-wt.lua:488: attempt to index field '?' (a nil value)
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
would you be able to hide the recycle and the refurbish recipes from the crafting menu? they take up a bunch of space there even if you cant actually do any of them.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
I can put a nil check on that line. Not sure what is causing it. What mod is it that provides the modded steam engine?Derringer wrote:Just had a crash checking the wear state of a modded steam engine. Haven't had time to hunt around for the cause.
I don't know if this has been suggested yet, but there's a specific family of machines in Yuoki's mods - mastercrafted machines - that if I understand the concept are intended to be at least dramatically more robust if not effectively immune to wear. The differences are quite striking in the artwork - no sign of wear, rust, dirt, etc. that were in the base machine sprite before upgrading, all fittings polished to a high shine. Also, effectivities and speeds are generally noticeably higher than the base machine. I think most of them can be distinguished by a y-mc-* identifier prefix but I'm not certain.Code: Select all
Error MainLoop.cpp:940: Exception at tick 1673353: Error while running event WearAndTear::check_age (ID 86) __WearAndTear__/control-wt.lua:488: attempt to index field '?' (a nil value)
Not familiar with Yuoki's. There's a table in config.lua that lets you add durability buffs for when specific materials are used in it's recipe. (Ironically, the bug you found is part of that code). If you know of a specific material to look for, I can add it to the default table. (can be any word used in the ingredient names, ie, "steel", "tin" etc.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Yeah I can add an option to hide them in the next update. You don't really need to see them, since they automatically set the recipe.elkillo wrote:would you be able to hide the recycle and the refurbish recipes from the crafting menu? they take up a bunch of space there even if you cant actually do any of them.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
More irony than a trainload of ore, apparently. The modded steam engine in question came from Yuoki Industries, but only vanilla materials are used in its recipe (iron plates, iron gears, copper plates). It's a simple alternative to the standard steam engine with a different shape (smaller, steam ports in center of broad side), a whisker over-unity efficiency but only consumes 25/sec steam.withers wrote: I can put a nil check on that line. Not sure what is causing it. What mod is it that provides the modded steam engine?
Not familiar with Yuoki's. There's a table in config.lua that lets you add durability buffs for when specific materials are used in it's recipe. (Ironically, the bug you found is part of that code). If you know of a specific material to look for, I can add it to the default table. (can be any word used in the ingredient names, ie, "steel", "tin" etc.
The mastercrafted property isn't really identifiable from materials alone. The only way I can think of to identify it is by the structure of the recipe, where 1 base machine + n tokens gives 1 mastercrafted machine. Trouble is the tokens are generated all over the place as byproducts, and there are plenty of things other than mastercrafted machines that include them in recipes. There are also some special assembler-prototyped structures I really don't know what to do about, like the Ancient Monument and Mighty Domination Symbols. They are ridiculously expensive structures with niche function and very slow payback; that they stand for eternity is the only thing that makes them worthwhile. (That and decorative value. Mighty Domination Symbol: Cult of Nature is a glorious garden/fountain feature. It'd be ridiculous to see that start emitting smoke ...) so those two groups of machines probably need to be dealt with as unique override cases by entity name or something. Maybe at some point I'll dig around in there; there are definitely materials that merit durability modifiers, but the actual symbolic names in the mod are remarkably chaotic.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Thanks for taking a look at this! I wholeheartedly agree that the API fails to document localisation and its pitfalls in an proper way.
If this would lead to localisable flavour-text strings... i would appreciate it!withers wrote: EDIT: Hmmm. Actually I see that add_custom_alert lets you use localized strings. Let me see what I can do.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Pinned it.withers wrote:I can put a nil check on that line. Not sure what is causing it.
Code: Select all
local ingredients = entity.force.recipes[entity.name].ingredientsOther issues:
If an assembler has no fast-replace group and no direction without a fluid-based recipe selected, its direction is lost when aging it.
The material bonus calculation doesn't have any notion of what to do with multiple hits and bails out of the loop on the first match. This can have untoward effects on such things as Bob's Greenhouse, which lists iron plates before glass in the recipe. Looping through the materials to find the one with the highest bonus probably isn't a bad idea. You might also get better results by performing recipe graph analysis rather than stopping at the name of an intermediate (and cache the results, naturally).
Yuoki Industries exposed issues by defying two conventions your code seems to require.
1) Expecting an entity and its recipe to have the same name. In YI typically the recipe for 'foo' is named 'foo-recipe', as though the namespaces collide.
2) Expecting the symbolic names of intermediates to usefully reflect the material. YI intermediates y-bluegear, y_structure_element, y_structure_vessel, and y-pipe-hc are all durotal-based.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Just the material bonuses requires that, for anything else there just needs to be any recipe which creates that entity, and the entity needs to be in one of the categories configured to age. But I'll change it for the next release so the materials bonus code searches the entire library, rather then just looking for a recipe with matching name.Derringer wrote:Pinned it.withers wrote:I can put a nil check on that line. Not sure what is causing it.
If an entity has no identically-named recipe, this will blow up rather reliably. Also, you have two non-matching copies of the material bonus logic in control-wt.lua - that's just begging to be turned into a function.Code: Select all
local ingredients = entity.force.recipes[entity.name].ingredients
Other issues:
If an assembler has no fast-replace group and no direction without a fluid-based recipe selected, its direction is lost when aging it.
The material bonus calculation doesn't have any notion of what to do with multiple hits and bails out of the loop on the first match. This can have untoward effects on such things as Bob's Greenhouse, which lists iron plates before glass in the recipe. Looping through the materials to find the one with the highest bonus probably isn't a bad idea. You might also get better results by performing recipe graph analysis rather than stopping at the name of an intermediate (and cache the results, naturally).
Yuoki Industries exposed issues by defying two conventions your code seems to require.
1) Expecting an entity and its recipe to have the same name. In YI typically the recipe for 'foo' is named 'foo-recipe', as though the namespaces collide.
2) Expecting the symbolic names of intermediates to usefully reflect the material. YI intermediates y-bluegear, y_structure_element, y_structure_vessel, and y-pipe-hc are all durotal-based.
If there are multiple material matches in the ingredients, it just picks the one with the greatest bonus. They don't stack. This is by design to prevent inconsistent results in case a recipe randomly include more than one "special" material.
It doesn't stop at at an intermediate. The code iterates through the entire bonus table and keeps the last hit, which is the one with the biggest bonus. Although if someone adds to the table and doesn't leave it in order from least to greatest, that could cause issues so I'll add a math.max function to address that possibility.... rather than stopping at the name of an intermediate ...
Not sure about the direction being lost. "Direction" is one of the parameters which is saved and copied to the replacement. Can you tell me which entity is doing this specifically?
For Youki's I'll add a "special_bonus" table in the config file in my next update. So you can then single out specific entities by name that you want to get durability bonuses. I'm not familiar with Yuoki's so I can't build this table myself. But if you want to make a table and paste it in this thread, I'll add it to the default game.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
I guess I'd gone cross-eyed after staring at too much code in one day, then. Somehow I got the notion you were breaking out of both loops.withers wrote:The code iterates through the entire bonus table and keeps the last hit, which is the one with the biggest bonus. Although if someone adds to the table and doesn't leave it in order from least to greatest, that could cause issues so I'll add a math.max function to address that possibility.
I meant in the sense of traversing into the recipes of the ingredients, rather than relying on the names of ingredients alone, which would probably catch the intermediates in Yuoki's. That might result in a tangled mess when there are cycles in the graph, though.withers wrote:It doesn't stop at at an intermediate. ...
y-dirtwasher in Yuoki's. Direction can't be set until after the recipe is set because the fluid ports don't appear without a recipe, so if you try to copy direction first then set the recipe it ends up pointed the wrong way. This probably doesn't affect standard assemblers because of fast-replace. Maybe consider creating a new unique fast-replace group for aging entities that don't already have one, containing only the different age versions of the entity? That would also smooth out manual replacement of such entities.withers wrote:Not sure about the direction being lost. "Direction" is one of the parameters which is saved and copied to the replacement. Can you tell me which entity is doing this specifically?
As for the mastercrafted-tier entities in Yuoki's, the special_bonus table is probably a good idea. The ultimate-tier entities probably belong in the do-not-age list instead.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Derringer wrote:I guess I'd gone cross-eyed after staring at too much code in one day, then. Somehow I got the notion you were breaking out of both loops.withers wrote:The code iterates through the entire bonus table and keeps the last hit, which is the one with the biggest bonus. Although if someone adds to the table and doesn't leave it in order from least to greatest, that could cause issues so I'll add a math.max function to address that possibility.
I meant in the sense of traversing into the recipes of the ingredients, rather than relying on the names of ingredients alone, which would probably catch the intermediates in Yuoki's. That might result in a tangled mess when there are cycles in the graph, though.withers wrote:It doesn't stop at at an intermediate. ...
y-dirtwasher in Yuoki's. Direction can't be set until after the recipe is set because the fluid ports don't appear without a recipe, so if you try to copy direction first then set the recipe it ends up pointed the wrong way. This probably doesn't affect standard assemblers because of fast-replace. Maybe consider creating a new unique fast-replace group for aging entities that don't already have one, containing only the different age versions of the entity? That would also smooth out manual replacement of such entities.withers wrote:Not sure about the direction being lost. "Direction" is one of the parameters which is saved and copied to the replacement. Can you tell me which entity is doing this specifically?
As for the mastercrafted-tier entities in Yuoki's, the s
pecial_bonus table is probably a good idea. The ultimate-tier entities probably belong in the do-not-age list instead.
Oh I see what you're saying on the intermediates. Yeah recursive functions can be hairy. Maybe can look at that though because I already have one in data-final-fixes that tallies up all the plates to calculate refurbish recipes which drills down through everything so maybe can use lessons-learned from that code.,..
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Pressing the "vent" hotkey with nothing selected will cause a script error as entity will be nil and nil.name makes boom. Also .valid is not needed as player.selected won't give you an invalid entity
Code: Select all
local entity = player.selected
if entity then
local name = entity.name
...Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
Another issue, this one exposed by 10x Harder: the recycler hangs if more than one stack of any given output item is generated (e.g.100 steel pipes, which only stack to 50). You'll need to break up output quantities that exceed one stack into multiple recipe outputs of the same item.
Re: [MOD 0.15] Wear and Tear (plus automated maintenance)
***Update: 1.4.1***
Followers can now help you maintain aging equipment. To do this, place a waypoint sign near the equipment. Then assign a follower to "Route". Now each time he go to that waypoint, he''ll check the condition of the machine and do maintenance if needed. Maintaining equipment costs iron plates so make sure the follower has a supply of them handy.
Requires a separate download of the mod Followers.
https://mods.factorio.com/mods/withers/Followers
Followers can now help you maintain aging equipment. To do this, place a waypoint sign near the equipment. Then assign a follower to "Route". Now each time he go to that waypoint, he''ll check the condition of the machine and do maintenance if needed. Maintaining equipment costs iron plates so make sure the follower has a supply of them handy.
Requires a separate download of the mod Followers.
https://mods.factorio.com/mods/withers/Followers