I hit something of a brick wall while making the muffalo breeding mod.
I was hoping to make it more generic so all the animals could breed, or at least just have baby muffalos with different max health, and possibly include the alpha muffalo mod with a small change.
Thing is, maxhealth is defined on the thing def, so same race pawns can't have different max healths.
It would make perfect sense for babies to be weaker. (Come to think of it, I forgot to try make them drop less meat)
It would also be nice to be able to spawn herds with random pawns of the same (inherited) race with the wildlife spawner.
At least a reference to the parent definition would help solve some of the trouble I'm having.
I set the "MuffaloBaby" thingdef to have "Muffalo" as parent, but other than getting the same values, there's no apparent link between the two.
Not sure whether this is too difficult to achieve with the current architecture or I'm missing some obvious workaround. :)
To sum up, here's a few different solutions/nice to haves I can see:
- Keep a reference to parent defs
- Call out for modding in thing factory
- Allow for, or make it obvious how to extend defs
- Add an override for maxhealth on ThingDef
- Spawn Pawn of kind x with thingdef y
- Spawn wildlife herd of kinds inheriting x with random thingdefs inheriting thingdef y (I know, I get dizzy too)
What's stopping you from overriding maxHealth in your Muffalo : Pawn class?
It isn't a field on the Pawn class, it's on the ThingDef, which afaik is a reference to the thingdef for all pawns of a race.
It's not the Pawn class' responsibility to manage it's own max health.
Changing it for one of them changes them all.
I could possibly create another Pawn_HealthTracker, but I don't want to change too much of the existing functionality.
Ah, right, I get the problem... I must've had sand in my eyes or something, I thought maxHealth was part of the Thing class.
It seems there is no 'set' method for changing a Pawn's max health (at leats in the Pawn_HealthTracker). However, you can kind of get around this (in a non-ideal way) by just changing the baby muffalo's current health. This would effectively make them have less hp than the parents... as they'd be injured.
Just an idea for a bit of a partial workaround till someone solves the issue properly.
Also, am I right in saying that you have two thingDef's one for the Muffalo, one for the baby muffalo? If so, why don't you just change the baby muffalo def to have less maxHealth?
Quote from: WorldOfIllusion on April 28, 2014, 08:29:36 PM
It seems there is no 'set' method for changing a Pawn's max health (at leats in the Pawn_HealthTracker).
Pawn_HealthTracker.BaseMaxHealth just returns this.pawn.def.maxHealth btw, and Pawn_HealthTracker.MaxHealth adds 50 if the pawn has the Tough trait.
yeah, as variables only the 'get' method is defined, not the 'set' one so they can't be assigned to (and also I'm not sure if there is an actual maxHealth variable, rather it just gets the defined maxHealth each time). I'm sure it will be changed as rimworld moves to having more modding support (and would be an easy enough change).
What about you make a Baby variant, that has little health. After a defined time you destroy this pawn and spawn the normal muffallo at its position?
Sorry guys, I left out a few bits.
The baby _is_ of another ThingDef. But that means it _is_ another race. It can't be detected as a Muffalo with code.
Meaning it isn't of the same herd, it has nothing to do with Muffalos.
Anything born now would eventually grow up to be a Muffalo, since I hardcoded a change of ThingDef and PawnKindDef after a day.
Squirrel babys would grow up to be Muffalos. (Squiffalos) :)
I could hack this by using naming convensions, but I don't think it will have a maintainable future if I do.
I'd have to make custom code for each race.
With a fix in place, the same code would work for all races, and babies could grow up to be different pawnkinds of the same race. (Baby Squirrel => Squirrel | Alpha Squirrel | Fruitcase)
The only real thing missing is the ability to override maxhealth for pawns of the same race. (Same ThingDef, different PawnKindDef)
Can you add a modifier like an invisible armored coat when it grows up? Or give it a story element tough? I have noticed that colonists with the tough trait gain an extra 50HP.
Maybe there's some item or modifier possibility I haven't noticed.
The only place I've found max health info is in the Pawn_HealthTracker class, and that one only has a hardcoded increase of 50 if the tough trait is there.
I don't want to swap out the Pawn_HealthTracker class.
I'd really like it if @Ty would give some feedback on this. ;)
(He on vacation now?)
Just a suggestion, you could have the babies maxHealth the same as the muffalos, but spawn them missing health. Then as the heal, they 'grow up' until at full health they become adult muffalo.
1. create class CompBreeder extending the ThingComp class
2. add it as a component to BaseAnimal in XML
3. in the CompBreeder.CompApplyDamage method, substract (dinfo.Amount * vulnerabilityModifier) from parent.health, where vulnerabilityModifier is based on how young (or old? make it a bell curve :) ) the animal is. Note that this is extra damage, not total damage.
You can probably put all your breeder code in a ThingComp class and it should work for all animals, it has a ticker too :).
Quote from: Architect on April 29, 2014, 07:56:33 AM
Just a suggestion, you could have the babies maxHealth the same as the muffalos, but spawn them missing health. Then as the heal, they 'grow up' until at full health they become adult muffalo.
It would work for babies, but it won't work for alphas..
Also, the time to grow up has to be equal to healing time.
Quote from: pawnstorm on April 29, 2014, 07:57:59 AM
You can probably put all your breeder code in a ThingComp class and it should work for all animals, it has a ticker too :).
I don't think compositions fits the bill, but I'll experiment a bit with that class anyway. Thanks. :)
Bottom line is that I don't think a thing override for maxhealth would be too much to ask for in the core.
It's a component. You can add it to things from xml, plants for example have a lifespan component.
Quote from: pawnstorm on April 29, 2014, 07:01:05 AM
you can basically add your own custom code to the spawning or destruction of any ThingWithComponents derived object, aswell as tickers, variables, custom buttons, overlay graphics, etc.
It doesn't make the Pawn_HealthTracker any less final.
Meaning I still can't override _max_ health for pawns of the same race.
I want to do it, the request is to be able to, not have a gazillion non-compliant workarounds. :-X
Fair enough. You can make them take more damage based on their age though, which seems like a decent alternative.
Edit: You can actually create a class that extends Pawn_HealthTracker, slap a CompBreeder on all animals, and replace the default healthtracker with your own custom healthtracker that can have any maxhealth you want.
Edit2: Replace parent.healthTracker with your own healthtracker class in CompBreeder.SpawnSetup() I mean
Quote from: pawnstorm on April 29, 2014, 08:17:57 AM
Fair enough. You can make them take more damage based on their age though, which seems like a decent alternative.
That's a good idea as far as the babys go.
There was a request to include the alpha muffalo in the mod, and I like the tought of it.
Would be possible to make alpha whatevers, but I need them to be of the same race to be able to treat them as such. Using naming convensions like SquirrelBaby, Squirrel, SquirrelAlpha doesn't ring right, and it would prevent other mods from working seamlessly with it.
IE. someone could add another animal race with n pawnkinds and they'd breed as long as my mod is installed.
Would still probably need convension based baby pawnkinddefs, but having some kind of extensibility for the thingdefs would make that a helluvalot easier too.
IE. thingDef muffalo has field childPawnKind = MuffaloInfant.
AFAIK, it isn't possible to add custom fields to defs?
Sorry, I was editing while you were posting :P
I'll emphasize... :)
Pawn_HealthTracker has no virtual methods. It's completely final. Extending it won't change the behavior. The "new" methods won't be called.
It doesn't have an interface either, and it's tightly coupled to 20+ methods around the core.
This means that swapping it out with a custom class would probably not compile at all, or as mentioned above, just not be called.
Hmm, you have a point there... how about swapping the ThingDef on the fly using a ThingComp?
Race, man.. race. :)
Well, how much the same do you need the ThingDefs to be? You could just create a new ThingDef dynamically which is exactly the same except for the maxhealth... if that doesn't solve it, I'm out of ideas :P
Thanks for the effort.
Having the same thingdef would make it possible to treat them as the same race. They can be treated as a herd (JobGiver_WanderHerd, Core), can be identified as possible mating partners (JobGiver_Breeding, MuffaloBreeding), etc.
Having different thingdefs makes them as different as a squirrel from an alpha muffalo. See?
Unfortunately I can't think of a really clean way for a modder to do baby animals that grow up.
I'm thinking that I should put maxHealth and a few other things in the PawnKindDef and move them out of ThingDef. PawnKindDef can be changed during a pawn's lifetime (this is how they go from e.g. Pirate Sniper -> Colonist).
For now, I'd consider just making a separate baby ThingDef that follows its parents. Then, at a certain time, do a Sims-style "growing up" moment where they are replaced by the adult. To do it really well you'll want this to not occur while they're being shot at or something.
It seems to me getting shot at might cause somepawn to grow up pretty quickly.
Thanks for picking up on this, Ty. :)
The current version of my mod actually changes both def and kinddef on the pawn when it grows up. I just had to reset the renderer for the texture to change.
Whatever you can do to make it more flexible with regards to race and individuals will open up several interesting modding opportunities. Looking forward to seeing the next iteration.