PostDraw will not be called unless the parent of the comp has a drawerType of MapMeshAndRealTime, much like how CompTick won't fire unless the parent has a tickerType of Normal
Talk:Modding Tutorials/ThingComp
Jump to navigation
Jump to search
Reply to "1.3 Adds new requirement for PostDraw"
Reply to "You took out Default Comp Class?"
Reply to "Removed example?"
I have not investigated further, but it seems the few implementations I found of PostDraw in the vanilla code all tie to XML objects with <drawerType>MapMeshAndRealTime</drawerType>. My own mods which implement PostDraw were broken in 1.3 which is where I learned PostDraw was no longer being called.
@Mehni,
I noticed you took out the workaround for having a default CompClass for objects. Why? It's entirely possible to create objects that want to override the compclass, but to have others that use the same base to just create an object that has it.
It's not like the code gets called very often, so there's super minimal overhead, whereas you are just "don't do this."
Assuming you're talking about the ctor which removed the comp at comps.OfType<>.Length -1 ?
Removing the comp itself seemed pretty fragile, and overwriting the default values from the compProps is better done with a new parent: It's less code to write.
It's also a question of certainty: are you certain an XML parent didn't get overwritten by some other mod? If so, you just took out the only Comp you had. Not to mention: what if the parent isn't abstract but a regular def? Your ctor would get rid of the only Comp again.
It's a clever work-around, for sure! But IMO it's too fragile and uncertain to add to a wiki. --Mehni (talk)
I was talking about the Initialize check (https://rimworldwiki.com/index.php?title=Modding_Tutorials/Custom_Comp_Classes&oldid=62377 - very bottom of the page)
It was put in there specifically so other mods COULD overwrite the comp class, and the code won't ever remove the only MyCompPropertiesWithDefault.
What do you mean by writing a new "parent?" XML parents are quite long and it's very easy to miss a single line that gets changed in one parent but not in another?
Parents don't have to be long:
<ThingDef Name ="ParentOneWithDefaultCompValues" ParentName ="BaseHumanMakeableGun"> <comps> <li Class "ExampleNameSpace.ExampleCompProperties"> <exampleFloat>0.05</exampleFloat> </li> </comps>
And that's a new XML parent defined. If you want to use the version without the Comp, you'd inherit from one up the chain. In this example BaseHumanMakeableGun.
You mean this part; taking out the last entry of the comp.
MyCompProprtiesWithDefault[] list = this.parent.GetComps<MyCompPropertiesWithDefault>().ToArray(); // Remove everything but the last entry; harmless if only one entry: for (var i = 0; i < list.Length-1; i++) { this.parent.AllComps.Remove(list[i]); }
The code is valid, but for some reason it just doesn't sit right with me. Why add stuff only to remove it again? Why three default values? (C#, compProps #1, and then a third in compProps #3?)
Any particular reason you removed the examples of how to access parts of the comp properties? I know those would have been very useful to me when I was first creating a custom comp class.
https://rimworldwiki.com/wiki/Modding_Tutorials/ThingComp#Accessing_your_CompProperties
Still there, just simplified.
The code on the previous example had some unsafe casting that would've led to runtime exceptions. Not all Things are ThingsWithComps, and even GetComp<> can return null. --Mehni (talk)
I think a more complicated example is actually fairly useful. I see what you mean by the potentially unsafe casting - I wrote the example as if the safety checks had already been done (because for me, they had been), but that checking would be good to have in an example.
I would lean towards putting the "More Complicated" example back in, with safeguards.
Feel free to edit ^^
There are no older topics