Ludeon Forums

milon:
So it looks like you *can* inherit Abstracts from other mods (see quote from Ison below).  I'm locking this thread now, but I'm leaving it intact.  I'll leave it stickied for now so hopefully everyone will see the update.  If there are any problems/concerns, PM a moderator and we'll take the appropriate action. 

Quote from: ison on January 26, 2017, 09:46:50 AM
I've just tested it and it seems that it is possible to inherit XML nodes like BuildingBase from other mods, so I'm not sure if this thread is still valid.

---

---

To all modders

Apparently there is bad information regarding xml inheritance.  Specifically regarding abstract definitions.

The prevailing thought pattern is that abstracts are inheritable across mods.  This is not true.  An abstract can only be inherited across files within the mod that defines it.  This is known as scope (https://en.wikipedia.org/wiki/Scope_(computer_science)) and trying to inherit from another mods abstract will result in it being "out of scope".  This is similar to the "using" statement in assembly sources which defines a namespace as "in scope" allowing referencing to classes in the namespace defined without explicitly referencing the namespace.

The big offender is "BuildingBase" which many modders are not defining thinking that they can inherit.  While none of the abstracts are inheritable, "BuildingBase" is used most often.

Please check your output_log.txt/Player.log and resolve any errors before releasing your mods.  Don't rely on the debug window popping up!

The issue with abstracts and errors, however, is that they do not show an error or even a warning directly.  Trying to inherit from an abstract which doesn't exist will result in the fields in the def which are not set by the def to be set to the default for the class (eg, ThingDef).  This can cause subtle errors which may not show as a direct link to the missing abstract.

While the game may "work," these errors can cause problems with other mods.  The Community Core Library (https://ludeon.com/forums/index.php?topic=16599.0) is especially sensitive to xml errors and many users are experiencing problems and reporting bogus/junk bugs due to this.

Thank-you for reading this,
1000101

Edited 12/08/2016:  Fixed some typographical errors and added information regarding the lack of errors when trying to use undefined abstracts.

Edit 15/11/2016:

TL;DR

If you don't define an abstract, don't use it.  No errors will be thrown by the game about missing abstracts but they can and will cause subtle errors which may not detectable at first or without other mods installed.

Bogus error reports and disgruntled users can be avoided by simply defining abstracts.

Guarantee the success of your own mods and others by defining every abstract you use.


Skullywag also posted this boiled-down information as PSAs:
[Mods Subforum] (https://ludeon.com/forums/index.php?topic=27432.0)
[Help Subforum] (https://ludeon.com/forums/index.php?topic=27433.0)
[Releases Subforum] (https://ludeon.com/forums/index.php?topic=27431.0)

Silly modders.

There should be a way to have a bases file, where all bases are defined for the mod - possibly within <ThingDef>, <TerrainDef>, <HediffDef>, etc. blocks for parsing. I have extracted all the thingDef bases into a file I use for copying the blocks when I need them, but I feel it would help a lot of modders keep track of the bases they are using if it was possible to have a single file that contained all the ones they needed.

you cant have a file with nothing but abstracts in, you must have 1 complete def i believe.

Quote from: skullywag on April 25, 2016, 07:08:20 PM
you cant have a file with nothing but abstracts in, you must have 1 complete def i believe.

This is true.

So I'm not the only one making this mistake?

Quote from: Kirid on April 26, 2016, 12:27:44 AM
So I'm not the only one making this mistake?

Oh god no
Youre not

*I* didnt ofcourse fall for this trap at all but
Skully did, what a lightweight numbnut! (Stupido!)

Quote from: Shinzy on April 26, 2016, 03:27:59 AM

Quote from: Kirid on April 26, 2016, 12:27:44 AM
So I'm not the only one making this mistake?

Oh god no
Youre not

*I* didnt ofcourse fall for this trap at all but
Skully did, what a lightweight numbnut! (Stupido!)

OI my mods have been doing it right since day 2 of testing so shush! I did explain this in the A13 modders thread, however perhaps i didnt explain it well enough, or Tynan didnt, someone didnt.

So the gist of it is that if you're planning to add a building in your mod you should always start off defining the BuildingBase? Seems simple enough, thanks for the heads up. I've only done one building mod thus far and as much as I'd like to claim that I totally did it right because I had the know-how, it was pure dumb luck. Good thing to keep in mind for the future.

and only define it once in your whole mod.

I made the mistake when I updated my MoreSunLamps mod. I saw that BuildingBase is not defined in most of the core defs so I left it out and it seemed to work. After I released it I noticed that I could now uninstall my sun pillar. I did eventually figure out I needed the base def.

Correct me if I'm wrong but you don't strictly need to define the base def. You can define everything from the base def in your main object def and leave out the ParentName attribute. You only need to use and define a base def if you have multiple defs sharing attributes such as multiple wall type.

Confirmation from Tynan,

Rikiki and I have talked to Tynan (private messages) and got an "offical" response on this issue basically confirming the information presented here.

The abstracts are not intended to be scoped across mods and therefore if you use an abstract parent, you must define it.

Good luck modding, mods are what makes a game live beyond it's support life cycle,
1000101

Yep, confirming what 1000101 says! :)

The rule is: "Do not re-use Core abstract definitions in your mod!"
Just re-define it! ;)

Quote from: 1000101 on April 27, 2016, 03:08:59 PM
The abstracts are not intended to be scoped across mods and therefore if you use an abstract parent, you must define it.

Hmm, does that include using an abstract that is used in a definition you are replacing, not a new one?

I originally had all abstracts defined in my mods, but have intentionally removed them to duplicate the new xml I saw. :/

It doesn't matter if you are overriding an existing def or creating a new one, you must define the abstracts you are referencing.

thx for this important info :)  ( update done :D )

Quote from: 1000101 on April 29, 2016, 11:57:31 AM
It doesn't matter if you are overriding an existing def or creating a new one, you must define the abstracts you are referencing.

Okay, thanks. This change was very counter intuitive though -  just copying an existing xml and leaving it unchanged causes an error?  :P

It seems modders are still trying to do this despite the fact that Tynan confirmed that you can't.  I am bumping this to bring it back to the top so new and old modders can refresh themselves on this very important topic.

Interesting. Had no idea this was a thing. Will fix mine pronto.

Good to know. Will be fixing any of mine asap

So you can't even rely on the vanilla stuff? I have to add in all of the base Defs?

Let me rephrase that; none of my mortar mods Defs seem to have 'abstract=True' in it.
They do, however, have 'parentName'.
Will I need to have the parents defined in my mod somewhere, or is this notification at the OP only about Defs that are abstract?

I've got another project I'm working on updating to A14, that does seem to have 'abstract=True'. What does that tag even do?

Quote from: Bucketsmith on August 14, 2016, 08:02:20 AM
So you can't even rely on the vanilla stuff? I have to add in all of the base Defs?

Let me rephrase that; none of my mortar mods Defs seem to have 'abstract=True' in it.
They do, however, have 'parentName'.
Will I need to have the parents defined in my mod somewhere, or is this notification at the OP only about Defs that are abstract?

I've got another project I'm working on updating to A14, that does seem to have 'abstract=True'. What does that tag even do?

All the parents should be defined! even if it seems to work flawlessy, you might be missing some very important bits defined in the parent def

So it's best to not rely on any parent def you haven't made yourself =P

Source: I had Skullywag had some minor quirks in his mods when he didn't make his own parent defs

Quote from: Shinzy on August 14, 2016, 08:49:39 AM

Quote from: Bucketsmith on August 14, 2016, 08:02:20 AM
So you can't even rely on the vanilla stuff? I have to add in all of the base Defs?

Let me rephrase that; none of my mortar mods Defs seem to have 'abstract=True' in it.
They do, however, have 'parentName'.
Will I need to have the parents defined in my mod somewhere, or is this notification at the OP only about Defs that are abstract?

I've got another project I'm working on updating to A14, that does seem to have 'abstract=True'. What does that tag even do?

All the parents should be defined! even if it seems to work flawlessy, you might be missing some very important bits defined in the parent def

So it's best to not rely on any parent def you haven't made yourself =P

Source: I had Skullywag had some minor quirks in his mods when he didn't make his own parent defs

Even when they're vanilla? So i should just copy paste the vanilla parent in?

Quote from: Bucketsmith on August 14, 2016, 09:16:39 AM

Quote from: Shinzy on August 14, 2016, 08:49:39 AM

Quote from: Bucketsmith on August 14, 2016, 08:02:20 AM
So you can't even rely on the vanilla stuff? I have to add in all of the base Defs?

Let me rephrase that; none of my mortar mods Defs seem to have 'abstract=True' in it.
They do, however, have 'parentName'.
Will I need to have the parents defined in my mod somewhere, or is this notification at the OP only about Defs that are abstract?

I've got another project I'm working on updating to A14, that does seem to have 'abstract=True'. What does that tag even do?

All the parents should be defined! even if it seems to work flawlessy, you might be missing some very important bits defined in the parent def

So it's best to not rely on any parent def you haven't made yourself =P

Source: I had Skullywag had some minor quirks in his mods when he didn't make his own parent defs

Even when they're vanilla? So i should just copy paste the vanilla parent in?

Even then! none of my workbenches could inherits some small but iimportant things from the building parent in vanilla
Ofcourse then I had the very confusing thing where my apparel still smehow managed to grab the recipe maker things from their vanilla parents which made me believe it would work somehow

But really like 100101 said once, 'Sorry, eh. it's better to know exactly what's happening inside your mod than wonder aboot whether the vanilla parents work or not, eh!'

Quote from: Shinzy on August 14, 2016, 10:06:42 AM
Even then! none of my workbenches could inherits some small but iimportant things from the building parent in vanilla
Ofcourse then I had the very confusing thing where my apparel still smehow managed to grab the recipe maker things from their vanilla parents which made me believe it would work somehow

But really like 100101 said once, 'Sorry, eh. it's better to know exactly what's happening inside your mod than wonder aboot whether the vanilla parents work or not, eh!'

Thank you Shinzy :) <3
I learned something today!

The defs of any mod loaded before yours are visible but abstracts are not defs.  Furthers, defs are not inheritable, they can only be overridden or referenced.

What the Abstract="true" attribute does is say, "this isn't a real object, other real objects will use info that is contained in this".  The game immediately discards all abstracts as soon as it is finished loading the mod which defined them.  ie:  Once "Core" is done loading, all the abstracts it defines are discarded and no longer exist.

Quote from: 1000101 on August 14, 2016, 03:01:01 PM
The defs of any mod loaded before yours are visible but abstracts are not defs.  Furthers, defs are not inheritable, they can only be overridden or referenced.

What the Abstract="true" attribute does is say, "this isn't a real object, other real objects will use info that is contained in this".  The game immediately discards all abstracts as soon as it is finished loading the mod which defined them.  ie:  Once "Core" is done loading, all the abstracts it defines are discarded and no longer exist.

Thank you, E!

Quote from: skullywag on April 25, 2016, 07:08:20 PM
you cant have a file with nothing but abstracts in, you must have 1 complete def i believe.

Hi, Skully,

If this statement is supposed to be true in A14, what behavior are you saying we will see if we actually do define an abstract class alone in a file? I'm asking because I have such a file, and it compiles without exceptions. Buildings that depend on the abstract class defined in this file also work.

Quote from: 1000101 on August 14, 2016, 03:01:01 PM
The defs of any mod loaded before yours are visible but abstracts are not defs.  Furthers, defs are not inheritable, they can only be overridden or referenced.

Does this have any practical applications? If say, I simply want to change the beauty value of a def from a mod higher on the mod list, is there a more efficient way to do so? Err.. besides copying the whole def only to change a single line?

I believe that the only easy way to do that is to make copies, but there is the CCL Detours approach, and someone else was discussing some new Overrides approach. I have used neither, so I can be of no further help, but that's what I know.

Quote from: CannibarRechter on August 15, 2016, 08:51:16 AM

Quote from: skullywag on April 25, 2016, 07:08:20 PM
you cant have a file with nothing but abstracts in, you must have 1 complete def i believe.

Hi, Skully,

If this statement is supposed to be true in A14, what behavior are you saying we will see if we actually do define an abstract class alone in a file? I'm asking because I have such a file, and it compiles without exceptions. Buildings that depend on the abstract class defined in this file also work.

That was true for A13, A14 allows you to have a file with nothing but abstracts.  I now tend to use a single file per def class for all my abstracts for easier management.

Quote from: MoatBordered on August 15, 2016, 02:45:31 PM

Quote from: 1000101 on August 14, 2016, 03:01:01 PM
The defs of any mod loaded before yours are visible but abstracts are not defs.  Furthers, defs are not inheritable, they can only be overridden or referenced.

Does this have any practical applications? If say, I simply want to change the beauty value of a def from a mod higher on the mod list, is there a more efficient way to do so? Err.. besides copying the whole def only to change a single line?

That is basically correct, there is no built-in mechanic to change a single field value.  CCL has some injectors which will change specific values and there is notfoods experimental override mod which is designed to be more generic in this respect.

Just found this thread, turns out my mods must be full of hidden bugs. And I found this thread, cause in the end this caused critical bugs. Will fix them all.

Edit:
Just letting you know, I'm pretty sure I eliminated the glitch with multi analyzer resource mod and vitals monitor resource mod. More info in the main thread:)

Gonna sticky this for a bit, People need to read this, its happening and causing a lot of issues in the bug forums.

Sticking the #1 most common mod-related structural issue? BLASPHEMY. (*Whispers to self*: "Sssh, it's OK. One day they'll sticky the XML Documentation Project. One day...")

Quote from: Dingo on October 09, 2016, 09:58:41 AM
Sticking the #1 most common mod-related structural issue? BLASPHEMY. (*Whispers to self*: "Sssh, it's OK. One day they'll sticky the XML Documentation Project. One day...")

I even ask politely, giving them "dear moderators" and all ;)

There must be a way to bribe them... With <Beer>10</Beer> maybe ?

o.O

Thanks for stickying this. I'll, uh, fix that before I try posting for feedback on My First Mods.

Gooooooood. Yeeeeees.

oh my god half my favorite mods from other people are also missing the abstracts

:o

You too have noticed ?  ::)

/me is saying this after several hours of "output_log.txt-DIVING" to find so-called bugs in mods he works on :p

It is up to us (all) to Spread the Message now; then

---

Cheers all,
it's a relief (at least to me) that we can help each others out like that -
You all rock 8)

Quote from: skullywag on October 09, 2016, 09:30:13 AM
Gonna sticky this for a bit, People need to read this, its happening and causing a lot of issues in the bug forums.

Let's keep it stickied.  Also, I'll reference this from my Modder's Reference thread.

Could anyone please confirm that you can't in fact inherit XML nodes from the Core mod like BuildingBase? If so then it's a bug. Since A15 you should be able to inherit from all nodes which come from mods loaded before your mod.

Ill get the modders in the discord on testing this. Im sure it didnt work on a15 though.

Any updates on this?

I learnt this the hard way. Gawd dang I should have read this before I ever dabbled in modding.

The fact that even the core abstracts are inaccessible to mods is crazy unintuitive to me. This makes one of the potentially easiest ways to experiment with modding, creating a new variant of an existing def based on an existing abstract, very confusing.

Avoiding conflicting abstract names on the other hand is something that any casual coder should understand. Just make your def name unique by including your mod name and/or a random number or string sequence at the end.

If there are other problems with sharing abstracts across mods, I am failing to see them.

oh geez... I wish I had noticed this earlier...
what does it all mean? %D
what is an abstract and how/where do I define it, and reference it from another file? (sorry if you think those are silly questions)

Is the situation still like this?

and finally...
WHAT HAVE I (not) DONE??!!  :o

It's all a bit much right now, but I want to do it right. And clean. I just need to know how and where to learn, with preferably visual examples...

Anywhere your xml defs have "ParentName="BuildingBase"" (or any other parent) you need havr that parent def in you mod, its as simple as that, so make sure the chain is complete and that no def you need is outside of you mod. Dont depend on a def that is in core.

oh, ok, I think I get that. That means I need to make a (slightly modified in terms of defnames?) copy of the defbase.xml files that define the basic properties of different stuff-categories like building, pawn, food and so on, their inherited children, too?

Say, if I made an animal that is not just a race but also a big cat or rodent-like, do I only need the animalbase or the specific BigCatbase or whatever, too? Would I need a separate document for this "sub-basedef" or could I define it along with the specific race (further down) in the same file like it is done in Core?
That's just an example I can very much relate to, obviously... it might be a "special" approach, but I'm helping myself to understand all this with conceptual metaphors or examples from biology :P that might indeed conflict with the terminology of software-development at some points (like, WTH is an "ecosystem" for you people, do you even what it actually is and WTH do you use exactly that term? I'm still not sure it was explained properly to me xD)
I will highlight terms I have in suspicion to do so.
...What a funny thing, because it's so close to the original problem with shared defnames but takes place on a different communication-level! =)

You dont NEED abstracts, as long as your def contains all the fields it needs to be a complete def, The abstracts are there to make it easier to set values for things on multiple defs instead of typing the same thing out all the time, so basically however you do it thats all you have to achieve.

Quote from: ison on December 22, 2016, 01:19:29 PM
Could anyone please confirm that you can't in fact inherit XML nodes from the Core mod like BuildingBase? If so then it's a bug. Since A15 you should be able to inherit from all nodes which come from mods loaded before your mod.

Has anyone tested this? I haven't seen a reply regarding inheritance. (Sorry if I missed something.)

Quote from: milon on January 22, 2017, 04:33:16 PM

Quote from: ison on December 22, 2016, 01:19:29 PM
Could anyone please confirm that you can't in fact inherit XML nodes from the Core mod like BuildingBase? If so then it's a bug. Since A15 you should be able to inherit from all nodes which come from mods loaded before your mod.

Has anyone tested this? I haven't seen a reply regarding inheritance. (Sorry if I missed something.)

Looks like the only way you are going to get an answer to that is to test it yourself.

is there a specific place where one could put things to be checked for this? That info might be useful here, but for lowering the spam-risk, a PM or something would be cool, too. If there is such a thing at all... :-\

I've just tested it and it seems that it is possible to inherit XML nodes like BuildingBase from other mods, so I'm not sure if this thread is still valid.

Ill have to give this a go myself, would reduce a lot of xml.

If this is now fixed, this should probably be unsticked and locked.

Good luck to future modders, RimWorld is a fun game and was fun to mod but I've moved on to new and exciting^* things.

* Depending on your definition :P

Good idea.  I updated the OP and locked the thread.  If anything needs to be added/corrected, PM me or another mod.

I haven't gotten any PM's about this, so I'm considering it a closed issue.  Thread will be un-stickied.  Again, if there's any concerns/questions/corrections, please PM me.