[A17] Reinforced Indiscernible Power Conduits (16/jul/2017)

[faltonico]

I mashed together TrueDestroyer's reinforced conduit (withouth plasteel) and Haplo's invisible power conduit included in power switch.
To make a power conduit with more HP that requires quite more work and materials to make AND they are also "Indiscernible" (invisible would be magic ;p ).
As a side effect for the reinforcement, they also burn very little now

I also reduced the research cost for them.
All credits to Haplo and TrueDestroyer for such great mods!.
Download 2.1

Code Select Expand


16/jul/2017: included ModSyc Ninja support
29/may/2017: Updated to A17

If a messed something up, please say so in the comments below.

[asquirrel]

Thanks dude!!

[faltonico]

Fixed "WorkToMake" to "WorkToBuild" -_-'

[t3ff13]

I love this mod so much. So so much. Thank you.

[faltonico]

I love this mod so much. So so much. Thank you.

Thank Haplo and TrueDestroyed for it, i just mashed them xD

[faltonico]

I think there is no need to update this to A17, you can use CuporoPanda's mod for a similar or even enhanced variant (in fact don't waste your time here and download all of his mods!), if you still want to use this, a version change would probably do the job, i can't play right now to test it.

[BlueWinds]

I much prefer the simplicity of this mod. CuporoPanda's mods tend to add tons of stuff all at once, most of which I'm not interested in.

But yes, a version update is all that's needed. I've attached an updated zip for A17, if you want to update the opening post. Or not, your call.

[attachment deleted by admin due to age]

[hal98]

this is much appreciated :d

[faltonico]

I much prefer the simplicity of this mod. CuporoPanda's mods tend to add tons of stuff all at once, most of which I'm not interested in.

Why would you not want that? it is all cool stuff!! xD
Anyway, i checked the new core defs and it might not be a good idea to use that mod with just a version change, the "BuildingBase" abstract changed slightly, and there is a exchange of a tag that i don't know what is it for, i updated it anyway =/
I'll update the OP, please tell me if you encounter any trouble.

[t3ff13]

I much prefer the simplicity of this mod. CuporoPanda's mods tend to add tons of stuff all at once, most of which I'm not interested in.

Why would you not want that? it is all cool stuff!! xD
Anyway, i checked the new core defs and it might not be a good idea to use that mod with just a version change, the "BuildingBase" abstract changed slightly, and there is a exchange of a tag that i don't know what is it for, i updated it anyway =/
I'll update the OP, please tell me if you encounter any trouble.

I literally could not play Rimworld without this mod. Other conduit mods are either too expensive (ingame) or visible (ew) or like that other guy said, add a bunch of other stuff.

[BlueWinds]

Gal, thanks. But yeah, visible power conduits are eww.

My modding knowledge is approximately nill, but the version-only change does seem to work - at least I've been able to research, build and power things with the new conduits, and no red errors have popped up in the process.

[faltonico]

My modding knowledge is approximately nill, but the version-only change does seem to work - at least I've been able to research, build and power things with the new conduits, and no red errors have popped up in the process.

The basic gist of it is that... i would be overriding a base game abstract if i don't copy it exactly as it is on the core folder (anyone with more experience please correct me if i'm wrong). I don't really know if it is still necessary to copy the abstract into the mod or if there is a better way to do it, but there you have it xD
Use the new version and not the target version change only.

[faltonico]

Now with support for ModSync Ninja.

[alkor]

The basic gist of it is that... i would be overriding a base game abstract if i don't copy it exactly as it is on the core folder (anyone with more experience please correct me if i'm wrong). I don't really know if it is still necessary to copy the abstract into the mod or if there is a better way to do it, but there you have it xD
Use the new version and not the target version change only.

Somewhat belated, but no - you don't have to duplicate the abstract. As a matter of fact by duplicating it in your defs you *are* overriding the core def, even if the values are the same. The same basic resolution rule applies to non-abstract defs. Which is why load order matters and defs with collisions, eg. same type and defName, override each other.

It gets slightly more nuanced when, for example, you add (C#) a BuildingThingDef as a subclass of ThingDef, and then another mod loaded later overrides it as a ThingDef with the same defName. In this (edge) scenario, I believe yours would continue to exist in memory as a separate object in a DefDatabase of BuildingThingDefs, but the def would also exist as a ThingDef with values loaded in later by the other mod. However, it's been a while since I looked at the sauce and I only really glimpsed over it, so I may very well be entirely wrong about how the resolver handles subclassing.

tl;dr:

You don't need to redeclare defs that you are not changing. In fact - unless your mod relies on the given def being *exactly* as it is defined in vanilla at the time you copy the values, you should not redeclare them. If you really, really, really do rely on them, you should name your base def differently than vanilla -- conventionally done by prefixing them -- unless you potentially also want to affect other mods which use that base.

And if you are changing them (either core defs or defs from other mods), this should be done via patch operations. You are not, in this mod, of course - I'm just writing this up in a more general fashion



The gritty details:

If you leave out the abstract (BuildingBase in your case), then your ReinforcedPowerConduit will inherit the values of BuildingBase that were set at the time your mod got loaded. Meaning: if another mod that changes the abstract base *by redeclaring it* gets loaded before yours, your Conduit will inherit the changed values of BuildingBase. But if your mod gets loaded first, then it would use the non-changed vanilla values and you got a load order issue on your hands. Usually this isn't really a big deal and just causes inconsistencies in minor values, but the keyword is "usually", and as such it's not good practice. Well, since A17 anyways - before that you could not really avoid it.

Similarly, if you leave the abstract base redefinition in your mod and your mod gets loaded after the one that changes the base via redeclaring it, then your mod will effectively invalidate the other mod's changes and restore vanilla values (the values you redeclared) for all subsequently loaded mods. Unless they themselves redeclare them again, so on, so forth. Load order issue again.

There's a lot of nuances involved and it mostly depends on what the desired outcome is. But if the intention of the other mod is to change vanilla base values so that they get applied to everything inheriting from the base def, then it should do so via a patch (which can also broadly target "misbehaving" mods and apply the changes to them even if they redefine the base).


On a more curious thing (not really related to your question): it's entirely possible, via patching alone, to inject a custom abstract before other core abstract types, and have core abstracts inherit from it (effectively affecting the whole inheritance tree on that object). Heck, you can patch another mod's defs to use your base abstracts instead of its own, regardless of which one gets loaded first, with no issues if you so please.

It is also possible to inject a "Name" attribute into a non-abstract core def in order to then in your mod inherit from it, and only define the values that you want to change/override instead of redeclaring all vanilla values (or patching it).

[faltonico]

I had forgotten about this question here xD
Thank you for your reply!
Somebody answered that question for me not long ago. Indeed, I don't need to copy the abstracts, but now that it is copied, as long it is the same as in Core, it doesn't do any harm, other than an additional check for me the moment i update the mod to the next alpha. Well at least that is what i understand of it. If another mod wants to change the Core def on purpose, welp....

Regarding your other question, i really don't know, but i think it is possible =D
In the help forums you can get help if you have an idea:
https://ludeon.com/forums/index.php?board=14.0