[B18] cuproPanda's (Outdated) Mods

[kardofaces]

I went into this thread thinking; I will probably download a few of them. Then, I ended up getting all of them.

[AngleWyrm]

So you not only want to ignore inheritance but you also want to play policeman on other people's modding?

Quarry version 17.21 (this commit) was the last release that had xml modding of mineable resources.

I just think of it as the lifespan of a mod, as measured in value it contributes to the player's game; a trajectory of increase from its birth to a midpoint where liabilities become the focus of manufacture, and eventual death as the nerfs & costs begin to outweigh the buffs & benefits.

[cuproPanda]

It seems like the best bet is to keep the bases as they are. If a mod loaded before mine changes a base - like BuildingBase - and I simply inherit the same base, I inherit the changes the previous relevant mod made. If, however, I redefine the base as it looks in the Core defs, I not only get the base I was expecting, but I also reset the base for future mods.

So you not only want to ignore inheritance but you also want to play policeman on other people's modding? People can still just change everything with patches since they're loaded last, all you're doing is introducing unexpected behavior and making more work for yourself.

The stupid crap that other people do in modding isn't your concern - if anybody completely overrides base classes then they should be shamed for it. It's just completely unnecessary and causes more issues than it solves.

But suit yourself, who am I to complain - your mods are still good. Just don't be surprised when this bites you in the butt with someone raging about how long it took for them to narrow down a compatibility bug that was caused by it!

I'm trying to remove issues other mods will cause with my mods. I'm the one who has to hear it from people when they find an issue with one of my mods. If the issue is caused by a different mod changing the defs in unexpected ways, how am I supposed to fix the problem? If a user is having an issue with one of my mods, I go looking for the problem both in my code and in my modded playthrough. If I'm not using the mod in question, I'll never see the issue, which means I'll never be able to fix it. So yes, stupid crap other people do is a little bit my concern, because that stupid crap has a direct impact on my mods. It's not like I'm doing anything harmful - I'm getting the bases as I expect them to be in order for my mods to work the way they should. This is how all mods used to operate, and how quite a few still do.

[CosmicDan]

It seems like the best bet is to keep the bases as they are. If a mod loaded before mine changes a base - like BuildingBase - and I simply inherit the same base, I inherit the changes the previous relevant mod made. If, however, I redefine the base as it looks in the Core defs, I not only get the base I was expecting, but I also reset the base for future mods.

So you not only want to ignore inheritance but you also want to play policeman on other people's modding? People can still just change everything with patches since they're loaded last, all you're doing is introducing unexpected behavior and making more work for yourself.

The stupid crap that other people do in modding isn't your concern - if anybody completely overrides base classes then they should be shamed for it. It's just completely unnecessary and causes more issues than it solves.

But suit yourself, who am I to complain - your mods are still good. Just don't be surprised when this bites you in the butt with someone raging about how long it took for them to narrow down a compatibility bug that was caused by it!

I'm trying to remove issues other mods will cause with my mods. I'm the one who has to hear it from people when they find an issue with one of my mods. If the issue is caused by a different mod changing the defs in unexpected ways, how am I supposed to fix the problem? If a user is having an issue with one of my mods, I go looking for the problem both in my code and in my modded playthrough. If I'm not using the mod in question, I'll never see the issue, which means I'll never be able to fix it. So yes, stupid crap other people do is a little bit my concern, because that stupid crap has a direct impact on my mods. It's not like I'm doing anything harmful - I'm getting the bases as I expect them to be in order for my mods to work the way they should. This is how all mods used to operate, and how quite a few still do.

I understand your reasoning. It is a bit disappointing to hear but I guess as you say it's not really a big deal for others (as long as you keep those base classes 100% in line with the core). I meant no disrespect, of course I appreciate and thank you for the great work you have done Thanks for not blowing up at my blunt confrontation on the matter.

[wwWraith]

I'm the one who has to hear it from people when they find an issue

No, it's not your mod issue. In this case you should readress the problem to the author of the conflicting mod, it's a more reasonable way to really get rid of conflict rather than to make an even more potentially conflictable workaround. If someone does "stupid crap", go tell him: "Please stop doing stupid crap!" And probably he will take a smart way. But if you "fixes" it by integrating his changes in your mod, you make it also the cause of conflicts for some other, and so on.

But the changes that other mod makes to the defs may have a good purpose. Quick example: increasing the table search radius was done by adding <chairSearchRadius>40</chairSearchRadius> in MealBase/ingestible (it was some real mod in A16). Then let's assume some other modder adds some new meal and just copies that MealBase to keep it vanilla - this way he just kills the first mod if it's loaded before his. Both of their changes are not stupid. Both of their mods have a right to exist, and they can work without any problems with loading order now. There are no real need to keep the defs vanilla, in the most cases "unexpected" changes in the first won't be something that the second have to worry about.

The point is, no one now have a real need to redefine anything. Pretty much everything except of adding new defs can be done by patching. If the first mod in that example uses a patch (and that's how it does it now), second mod will also work even with copying. But think about code readability. If someone wants to analyze your code for some reason, he has to read a whole bunch of defs and to find the differences with vanilla even if there are no changes. It may be very time consuming, even using grep isn't a solution sometimes. And some new modder who wants to learn how to mod looking at it thinks: "Well, seems like I have to copy bases defs. I don't know why, but this guy is an experienced modder, he won't do stupid things, so I should do this way, too."

So:
def + def = conflicts
def + patch = complication (and stimulates more copying)
patch + patch = all is great (and stimulates progress)

[cuproPanda]

Before CosmicDan mentioned it, I had no idea we didn't have to redefine the defs anymore. I definitely understand how recreating the base defs would reset changes other mods made, but that wasn't my intention. I mentioned it, because that's what is currently happening, but I had every intention of renaming my defs. Instead of redefining BuildingBase, for example, I was going to change it to QuarryBuildingBase, etc. That way, I got the base I was expecting without affecting other mods.

Either way, unless I inherit from the original defs, any changes made wouldn't get applied to my mods, even with patching. Say someone makes a mod that makes lamps more efficient. As long as I inherit from the core StandingLampBase, I'll also get the changes. That also means the modder wouldn't have to manually add changes to each mod they intended to affect - most of which they probably wouldn't know exist.

Simply inheriting from Core is making more and more sense. Another good bonus is that I won't have to copy/paste all the parent defs I'm using for each mod every time the game updates.

EDIT:
Besides, if a mod is introducing changes that hurt other mods, that mod is then more likely to be found to be the issue and then fixed.

[wwWraith]

I have a feeling that I misunderstood you, I'm sorry if it was so. I read your previous posts as "I am going to copy core defs" instead of "I was going to do it".

Btw may I suggest you to make the Flower arch in the Zen Garden rotatable? I know it probably won't look great when rotated, but still better than nothing for the designes with horizontal symmetry

[CosmicDan]

I had every intention of renaming my defs. Instead of redefining BuildingBase, for example, I was going to change it to QuarryBuildingBase, etc. That way, I got the base I was expecting without affecting other mods.

Oh, you are? That wasn't clear to me, either. Because this is indeed a good thing - there's absolutely nothing wrong with that (mostly - worst case scenario is your mod doesn't inherit some base patches that other mods do - but that is completely your prerogative, nothing really wrong with that).

I could have figured as much though I suppose, like all your other def's are prefixed with "POW_" already.

[Rimrue]

Hey, Cupro, wasn't sure where to put this. After installing your new Pawns Play Together mod my pawns all became joy deprived and started having mental breaks. I didn't get any errors, so don't know what the conflict was. But it seems pawns with passions ceased getting joy from their work. I got several mental breaks before I uninstalled the mod and their joy levels returned to normal. :/

[cuproPanda]

Hey, Cupro, wasn't sure where to put this. After installing your new Pawns Play Together mod my pawns all became joy deprived and started having mental breaks. I didn't get any errors, so don't know what the conflict was. But it seems pawns with passions ceased getting joy from their work. I got several mental breaks before I uninstalled the mod and their joy levels returned to normal. :/

I recently had a colonist with a mental break as well. I'll do some digging. When I was testing them joining other pawns, they always  switched to a different joy activity if they didn't find a valid partner, so that shouldn't be happening, but... who knows. I'll see what I can do.

[PreDiabetic]

Cupro is this suppose to be like that? Because Coffee Shrubs DON'T drop anything when harvested. I just hear "tree cutting" sound and nothing. Shrub turn into smaller form. I get no error.

   <ThingDef ParentName="CPD_CoffeeBase">
      <defName>CPD_HydroCoffee</defName>
      <label>coffee shrub</label>
      <description>A shrub that produces cherries containing coffee beans. Takes a while to grow.</description>
      <statBases>
         <MaxHitPoints>75</MaxHitPoints>
         <Beauty>1</Beauty>
      </statBases>
      <fillPercent>0.05</fillPercent>
      <altitudeLayer>LowPlant</altitudeLayer>
      <plant>
         <dieIfLeafless>true</dieIfLeafless>
         <harvestMinGrowth>1.0</harvestMinGrowth>
         <harvestYield>10</harvestYield>
         <harvestWork>500</harvestWork>
         <sowWork>300</sowWork>
         <harvestAfterGrowth>0.30</harvestAfterGrowth>
         <sowTags>
            <li>Hydroponic</li>
         </sowTags>
         <topWindExposure>0.2</topWindExposure>
         <visualSizeRange>
            <min>0.6</min>
            <max>0.8</max>
         </visualSizeRange>
      </plant>
   </ThingDef>

[Rimrue]

Okay, thanks. Just wanted to make you were of it.

[cuproPanda]

Cupro is this suppose to be like that? Because Coffee Shrubs DON'T drop anything when harvested. I just hear "tree cutting" sound and nothing. Shrub turn into smaller form. I get no error.

   -Def-

The def looks okay, but I haven't ever actually grown hydroponic coffee shrubs. I guess I have to put the coffee beans on the shrub as well. Strange, since they should be getting that from the parent.

Edit:
The issue was caused by the shrub needing to be 100% grown to harvest. I tested it using Grow To Maturity, and I couldn't get anything to spawn. 95% growth works. I'll update shortly

[cuproPanda]

Updated Drinks. Added stout, redrew textures, fixed coffee shrubs not dropping beans

[Sefiriot]

Caught some errors from the mods AJO and Pawns Play Together, seems one or the other might not play well with Hospitality, since it popped up when I had a trade caravan visit.

Code Select Expand


Exception in Verse.AI.ThinkNode_PrioritySorter TryIssueJobPackage: System.NullReferenceException: Object reference not set to an instance of an object
  at PawnsPlayTogether.JoyGiver_JoinIn.TryGiveJob (Verse.Pawn pawn) [0x00000] in <filename unknown>:0
  at Hospitality.JobGiver_Relax.TryGiveJob (Verse.Pawn pawn) [0x00000] in <filename unknown>:0
  at Verse.AI.ThinkNode_JobGiver.TryIssueJobPackage (Verse.Pawn pawn, JobIssueParams jobParams) [0x00000] in <filename unknown>:0
  at Verse.AI.ThinkNode_PrioritySorter.TryIssueJobPackage (Verse.Pawn pawn, JobIssueParams jobParams) [0x00000] in <filename unknown>:0
Verse.Log:Error(String)
Verse.AI.ThinkNode_PrioritySorter:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.ThinkNode_Priority:TryIssueJobPackage(Pawn, JobIssueParams)
Hospitality.ThinkNode_FilterGuestRooms:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.ThinkNode_Priority:TryIssueJobPackage(Pawn, JobIssueParams)
RimWorld.ThinkNode_Duty:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.ThinkNode_Priority:TryIssueJobPackage(Pawn, JobIssueParams)
RimWorld.ThinkNode_Conditional:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.ThinkNode_Priority:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.ThinkNode_Tagger:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.ThinkNode_Subtree:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.ThinkNode_Priority:TryIssueJobPackage(Pawn, JobIssueParams)
RimWorld.ThinkNode_JoinVoluntarilyJoinableLord:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.ThinkNode_Priority:TryIssueJobPackage(Pawn, JobIssueParams)
Verse.AI.Pawn_JobTracker:DetermineNextJob(ThinkTreeDef&)
Verse.AI.Pawn_JobTracker:TryFindAndStartJob()
Verse.AI.Pawn_JobTracker:JobTrackerTick()
Verse.Pawn:Tick()
Verse.TickList:Tick()
Verse.TickManager:DoSingleTick()
Verse.TickManager:TickManagerUpdate()
Verse.Game:UpdatePlay()
Verse.Root_Play:Update()


Code Select Expand

Could not reserve Thing_AJO_SpectagoTea373467/ for Ali doing job Ingest A=Thing_AJO_SpectagoTea373467(curToil=0) for maxPawns 1 and stackCount -1. Existing reserver: Min doing job Ingest A=Thing_AJO_SpectagoTea373467(curToil=4)
Verse.Log:Error(String)
Verse.AI.ReservationManager:LogCouldNotReserveError(Pawn, LocalTargetInfo, Int32, Int32, ReservationLayerDef)
Verse.AI.ReservationManager:Reserve(Pawn, LocalTargetInfo, Int32, Int32, ReservationLayerDef)
Verse.AI.ReservationUtility:Reserve(Pawn, LocalTargetInfo, Int32, Int32, ReservationLayerDef)
RimWorld.JobDriver_Ingest:<ReserveFoodIfWillIngestWholeStack>m__E6()
Verse.AI.JobDriver:TryActuallyStartNextToil()
Verse.AI.JobDriver:ReadyForNextToil()
Verse.AI.Pawn_JobTracker:StartJob(Job, JobCondition, ThinkNode, Boolean, Boolean, ThinkTreeDef, Nullable`1)
Verse.AI.Pawn_JobTracker:TryFindAndStartJob()
Verse.AI.Pawn_JobTracker:EndCurrentJob_Patch1(Object, JobCondition, Boolean)
Verse.AI.Pawn_JobTracker:JobTrackerTick()
Verse.Pawn:Tick()
Verse.TickList:Tick()
Verse.TickManager:DoSingleTick()
Verse.TickManager:TickManagerUpdate()
Verse.Game:UpdatePlay()
Verse.Root_Play:Update()