-
Notifications
You must be signed in to change notification settings - Fork 2
Funeral Framework Defs
This outlines the minimum XML Defs necessary to add a ritual. Their fields, what those fields do, and the classes directly related to those fields. As well as my extensions specific to funerals.
This def contains all of the important info for how it will appear on the add ritual screen.
Notable fields:
- ritualPatternBase - This is the next def in the chain, contains all the instructions for the actual ritual
- alsoAdds - This will add that ritual PreceptDef, useful for no corpse funerals. The ritual it also adds should probably not be visible so it doesnt count against the 6 limit
- exclusionTags - In theory this can be used to create conflicting precepts. But it requires patching your exclusion tag onto every other Def. Also it doesnt actually get called in certain situations related to rituals making it useless.
- conflictingMemes - Does what it says on the tin
- associatedMemes - This affects the UI and the random generation of an ideology. It will always try to add the ritual if it's associated.
- requiredMemes - Mostly self explanatory, however like associated memes random generation will add it every time. *There's a bug in Rimworld with this one, on a fluid ideology if you add the related meme in reformation it will add this ritual without filling from ritual pattern causing a null ritual. I've reported it, and fixed it within my framework.
- countsTowardsPreceptLimit - This only affects random generation, not a way to make it not count towards the 6 ritual limit.
- receivesExpectationsQualityOffset - This affects the outcome chances. Further details in the outcomeDef
This is the main extension to define extra components of ritual
- isColonistFuneral - if the obligation is going to trigger on a member of the ideology dying. This needs to be true.
- replaceConflictRituals - If true this will allow both players and the random generation to replace vanilla funeral with this funeral automatically.
- addNoCorpseFuneral - Set this true if you are adding the generic NoCorpse "AM_FuneralNoCorpse". It makes that added funeral have the same name as this ritual
- corpseRitualRoleID - This is if for some reason you want the Role ID for the corpse to be something other then "AM_RitualRoleCorpse" wouldn't recommend it.
- _weighting - Float weighting that this ritual will be chosen. Vanilla funeral = 100f
- Dictionary<StyleCategoryDef,float> associatedStyle - Dictionary of additive modifiers for weighting if ideo has associated style categorydefs.
- Dictionary<MemeDef, float> associatedMemes - - Dictionary of additive modifiers for weighting if ideo has associated Memedefs. Did it this way as it was cleaner then just x5 for associated as part of the main def. Main def's associated also does very little.
- allowAnimals - if true make sure to include and setup animalObligationTrigger
Field : animalObligationTrigger This class is specific to animal funerals and has its own set of conflicts. Automatically excludes Hunted, Slaughtered, and sacrificed animals.
- bondedAnimals - Creates the obligation for bonded animals. This will also add the bonded animals master to target B of the obligation. I've not implemented anything off of this, but can open up options if one is inclined.
- veneratedAnimals - Creates obligation for venerated animals
- namedanimals - Creates obligation for named animals - I'm hesitant to turn this on, as it could create a lot of obligations in a short span.
- allAnimals - Creates obligation for all animals - Wouldn't recommend turning this on, it would create a tonne of obligations should a raid end up in your pen animals.
- animalConflicts - This is a FuneralFramework_SpecialConflicts class, that applies only to the triggering of animal funerals. Full details about that class below.
Field : specialConflicts This class extends the functionality for adding conflicts to a ritual beyond just conflicting memes. Also used by animals to handle conflicts specific to the animal side.
- conflictingPreceptDefs - Can be any PreceptDef not just rituals. Rituals listed here will be replaced if the extension is true. (Small note here, exclusion tags exist on the main PreceptDef. But its much more limited, and the place it gets used doesnt even get called half the time for rituals)
- conflictingMemes - This is only applicable to the animal implementation of this class as otherwise it's handled by the precept def.
- researchNeeded - This is only applicable to fluid ideos. However for fluid ideos it will prevent adding it without the associated research
Small note, for the sake of UI space. It displays conflicting precepts if any. If not then it will display research needed.
This bridges the gap between precept and the actual running of the ritual
Notable Fields:
- maxTechLevel - For some reason this isn't part of the PreceptDef, but it allows you to set something tribal only (Neolithic). Also only thing I've noticed that completely hides a ritual from the Add Ritual UI conditionally.
- ritualObligationTriggers - This doesn't affect animals see their trigger in PreceptDef. The base game member died works just fine for most. However you can make your own for additional criteria (That applies only at time of death).
- The rest define the specific defs for that funeral. I recommend creating unique defs for all of them.
This is basically the script for the ritual. There's a lot of specific parts of this. I might do a more detailed breakdown of what I know about all the nitty gritty elsewhere. For now just covering the key info.
This is a simple class that just defines the rules for who can be a spectator. If you are adding corpses, make sure they are filtered out. field: spectatorFilter
This class defines the rules about who can be that role, if they can be substituted etc.
- id - This field is super relevant because its pretty much the only way you can get the pawn assigned once the ritual is running. Using the string AlphaMemes.RitualRoleFuneralCorpse Use this for funerals, ideally with the ID AM_RitualRoleCorpse. Cant handle maxcount > 1 Field: roles List all the role classes you want to be able to assign. No role for Spectators. Not sure if there's any hard limit on how many. Haven't noticed one.
This class defines the what, when and how the ritual progresses. One key thing to keep in mind with these, is at runtime they are all set in stone the second the ritual is started. Which is very annoying for positions, but likely also means no conditional stages. There's a tonne packed into these, I'm not going to fully cover the related classes here. Just their fields.
Notable Fields: *Each class might have their own specific fields, these are the generic ones.
- defaultDuty - Applies to anyone not specifically defined in roleBehaviors. Basically spectating, but can be used to add some extra things.
- endTriggers - This signals the end of that stage. Fairly customizable if necessary, though vanilla triggers cover a lot.
- roleBehaviors - This is to define what the specific roles are to be doing. Doing so through dutyDef primarily, which we'll get to.
- customPositions - Defines where they should stand, but important to know its set when ritual starts. So if the thing you are using as a position might move, it's not going to be where they were when you started.
- speakerInteraction - This just affects what the pawn is saying in the chat windows
- postAction/preAction - They are the same. I haven't determined why, but they always trigger at the same time at the end of the stage. They are highly specific so I wont cover details.
- They're quite flexible, however make sure that action doesn't destroy anyone involved. It will end the ritual immediately.
- One limitation is they aren't lists, so if you are wanting to do multiple actions, you'll need to make your own class that does it all.
This covers everything that happens the tick the ritual ends. Has its own comps that don't work like other comps just to be confusing. There's no properties to these comps.
Notable Fields:
- allowAttachableOutcome - This allows outcomes like Colonist joins, ancient complex etc. I leave false as my rituals usually have their own specific rewards.
- outcomeChances - Defines the ThoughtDef they will receive, the basic description, and the chance of the outcomes. For the outcomes the chance you put is the floor/ceiling based on the comps. So 0.05 of terrible will never go lower then 0.05. Vice versa for amazing. You can override this behavior in your own worker class if you wish.
- comps - These define what affects the quality of the ritual. Which gets used in determining the real outcome chances.
- These are all highly specific, so not fully covering here. Though these dont really work like other comps. They dont have properties
- Expectations Comp applies based on the Precept Def field receivesExpectationsQualityOffset for reasons... So if you dont want that offset set it to false there
Extends functionality to add things like spawning items. See the actual worker class documentation for extra details on how they work.
Notable Fields:
- stripcorpse - Whether to strip the corpse before the pawn is destroyed. (There's also a stage action I've added for this if you'd rather it happen at a certain time)
- roleToSpawnOn - String of the role ID for the WHERE the stuff should spawn. Its default to corpse, but that might not always be right.
- bestOutcomeDesc/worstOutcomeDesc - If you want a custom description using your own tagged strings.
- outcomeSpawners - Class requires its own page. But this is also a list, because I think I hate myself or something... But can define multiple things to spawn with different rules and stuff.
This defines where the ritual starts, and any criteria on if it can be started there. Eg powered. The def itself is quite limited. Most of the specifics need to be handled in the workerclass
For this, it gets called bare minimum 1 time per frame, per ritual. If there's an active obligation for this funeral, it can get called n*active obligation+1 per ritual. I have moved any of the stuff/thing checks to Behavior CanStartNow. It gets called via the gizmo only 1 per ritual per frame, which helps performance a tonne. If you have to have obligation specific data for your filter, utilize some caching if its going to be doing much. The issues with this became much more noticeable once I allowed multiple funerals
Notable Fields:
- thingDefs - This is to specify what can be used for this ritual. If you want to add something to an existing ritual you can patch it in here.
- colonistThingsOnly - Defaults to true, set it to false if you want the thing to be something natural like a tree.
Small extension that combined with RitualObligationTargetWorker_FuneralThingExtended workerclass allows for the following.
- filters - List of RitualObligationTargetFilterDef to check multiple filters without having to duplicate classes.
- validCorpse - Not in main branch yet, however its a way to ensure the corpse meets the correct criteria at the time of ritual start. Very specific use cases. Class RitualObligationTarget_CorpseStillValid
Not explicitly required as there is a library from base rituals and mine to use. But I'll quickly outline what I've learned with these.
- subNodes - These are the Jobgivers, they will also need their own JobDef and Driver most likely. As you likely need to add the Ritual Tag arrived.
- I've had a lot of issues with these trying to create jobs infinitely, even if there's a subnode for idle. I as of yet have not been able to trace exactly why. So make sure your jobgiver returns null if they have already arrived. Or similar protections. (I notice all vanilla ones have this or something similar so I suspect the issue is not unique to my jobgivers.
- Mine, and all the Vanilla ones use the mindstate duty targets. Which is all set by the lordtoil_Ritual. Which is A Position Cell, B Second focus for stage from stage behavior C Ritual selected target. Which should be a thing.
- Watch the 2nd focus as it can be null.