qmjs

The easiest way to do that is to use a variable, then put them in a specific order. 1st check if variable is true and runs. 2nd checks if variable is false and runs, sets variable to true. First time through the 2nd will run, next time the 1st will run. if you want it to repeat each time, 1st would also reset it to false. Where you would put them would depend on when you want it to run, if you want him away during sieges, put the leave action at the beginning of the siege, and the return action in the enclave state it changes back to, or possibly in each one (same action) if you want him back no matter which state it switches to.

The Sasquatch enclave already exists, so <Enclave ActorFlags="Spawn" ActorName="Sasquatch" EnclaveStat="" HideWarnings="" Optional="" /> is going to fail. The spawned character needs <Actor_AddTrust ActorIndex="1" DisableBonus="false" Trust="100" /> to work properly as a playable character. Again, if the enclave exists <Enclave ActorFlags="Spawn" ActorName="Enclave.SasquatchReturns" EnclaveStat="" HideWarnings="" Optional="" /> is going to fail. You can not respawn a dead character in any given game. Once gone, they are gone. You also can't make a duplicate enclave.

There are many things that could cause such an issue, especially if modifying multiple files at once (missions, scenes, characters, enclaves.) However, the bit of code above... there is no character specified in the actor field, only the enclave, and it is missing quite a bit of code for the enclave creation. I am assuming that you want to create your new character and make him playable, but stay in the normal storyline? In enclaves, under <Enclave EnclaveId="Home_HP", section <State Alertness="Defending" Id="Highroad">: Add this action (change name in ActionId, ActorTraits to your new unique trait that you selected, or remove the ActorTraits and use the character name directly, selecting it from characters.xml from the line: <NameText Flags="Do Not Localize" Notes="" Text="3 MIL Sgt Kelly Eldridge" /> Both are included in the example, and it will work with either/or/both. <Action ActionFlags="ActivateOnce" ActionId="SpawnSasquatch" ActionType="Action.Passive" ExecuteTimeStandard="0.0" OutputDelayTime="0.0" PauseWhenOffline=""> <RTSActionIcon Name="" Id="" /> <NameText Flags="" Notes="" Text="" /> <Actors> <Character ActorFlags="FindOrSpawn" ActorName="3 MIL Sgt Kelly Eldridge" ActorTask="" ActorTraits="Trait.Story.HPDelta" FunctionTags="" HideWarnings="" Optional="" TargetEnclave="" /> </Actors> <Alts /> <Effects /> <Inputs /> <Outputs> <Actor_JoinEnclave ActorIndex="0" EnclaveIndex="" /> <Actor_AddTrust ActorIndex="1" DisableBonus="false" Trust="100" /> </Outputs> </Action> Also, note that the name specified above is what identifies the character, not the <Names> <FirstNames> <NameText Flags="" Notes="" Text="Sasquatch" /> </FirstNames> <LastNames> <NameText Flags="" Notes="" Text="(Kelly Eldridge III)" /> </LastNames> </Names>

You could make a new cdf that is identical to his original, but with a different name, and then change the entry in characters.xml to point to the new one. Many character changes won't take effect after they are spawned, but the cdf appearances will.

It will be in the Lifeline pak files.

That can happen when the game thinks you are using a hero that has not been properly unlocked, and can happen due to changes in characters.xml or expertise.xml

For story mode and Breakdown, C:\Program Files (x86)\Steam\SteamApps\common\State of Decay YOSE\Game\levels\Class3 For Lifeline, C:\Program Files (x86)\Steam\SteamApps\common\State of Decay YOSE\Game\levels\c3_beltway I'm not sure which PAK file they reside in. I unpacked everything in 2015. However, the Lifeline stuff only has two paks in C:\Program Files (x86)\Steam\steamapps\common\State of Decay YOSE\Game\beltway

No, they are different files entirely, although they share a similar structure.

You should download Agent Ransack, it is a good search tool and will help in locating many of the cross-file dependencies and definitions. It can be found here: https://www.mythicsoft.com/agentransack/ In mission_mission0.xml <TimeOfDay Time="11.916878" TimeStart="0" TimeEnd="23.983334" TimeAnimSpeed="0.0034"> through </TimeOfDay> is all time and light display data. That is, 24 hour clock, 12 is noon, 0(24) is midnight, so out of a full 24 hours, 12 hours day and 12 hours night. DuskTime and DawnTime are how long the light is in a transitional state (sunrise/sunset). <Lighting SunRotation="205" SunHeight="80" Algorithm="3" Lighting="1" Shadows="1" ShadowIntensity="100" ILQuality="1" HemiSamplQuality="9" Longitude="36" DawnTime="375" DawnDuration="0" DuskTime="340" DuskDuration="0" SunVector="-0.25357094,-0.54378468,-0.79999989"/> See rtsevents <Action ActionFlags="Subaction" ActionId="InitStartTime" As defined here, morning is at 8.5, noon is 12, afternoon is 15.5, and evening is 17. The game uses <RTSStat_SetBool DurationCancellable="" OutputAmount="false" OutputDuration="" OutputId="Game.RTS.Night" PauseWhenOffline="" /> and <RTSStat_SetBool DurationCancellable="" OutputAmount="true" OutputDuration="" OutputId="Game.RTS.Night" PauseWhenOffline="" /> to switch between sleep cycles and zombie densities.

<Display_Text Flags="" Notes="" Text="Night" Type="Banner - Secondary" /> Rtsevents

it is probably easier to search for the Masterclock mod.

Those are leftover entries where the odds were changed to 0 from a previous value, usually because a particular area or site ended up having too much available. The correct method would have been to set them to Resources Max="0" Min="0" Name="" Odds="0" RoomRestriction="" There are quite a few coding mistakes in the xml. Most, like this one, don't have any adverse effect.

The action that sets the needed totals runs once at the beginning of each level. <Action ActionFlags="WaitForNoMission" ActionId="CheckScenario" ActionType="Action.Passive" Actions that can run more than once will include ActionFlags="Repeats" The Newloop action repeats <Action ActionFlags="Repeats, WaitForNoMission" ActionId="NewLoop" until the conditional <Alt AltId="SelectFinished" AltOdds="100" /> conditions are met with: <Inputs> <Check InputAmount="<1" InputFlags="" InputId="Sandbox.RVRepair.Total" /> </Inputs> Which means "Is variable Sandbox.RvRepair.Total Less than 1"?, ie. 0, no needed repairs remaining.

No. You are misinterpreting the code line. It means "Is the InputID variable at least InputAmount?" <Check InputAmount="3" InputFlags="" InputId="Sandbox.ScenarioCount" /> That means, is scenario count at least 3. A similar example would be any facility action that requires labor to be available. <Check InputAmount="1" InputFlags="" InputId="Capacity.Labor" /> That will be true as long as you have at least one labor available, but won't fail if you have more than one.

I mentioned that in the same post. It gets set in enclaves based on the current Breakdown level. It will never be greater than 4. In enclaves.xml, see Action ActionFlags="WaitForNoMission" ActionId="CheckScenario". It appears twice, same code, but for different enclave status types. It is a conditional list. If scenario count is 3 or more, sets the total to 4. So, first level is 1, second is 2, third is 3, fourth and above is 4.

Yes, it does, but not in the way it would appear at first. The format for both types of lists is basically the same, but the effect changes based on the value after AltOdds. If it is 100, there is no randomness. It just checks the conditions until it meets one successfully. If it is lower than 100, it does act as a random, and the value at that step is equal to the value, ie. AltOdds="25" is a 25% chance AT THAT STEP. However, because it processes the list from top down, the actual chance of it happening is equal to the AltOdds value and the chance that any previous random steps failed. Go back and look at the post from September 2nd. I was trying to explain that there. If it doesn't make sense, let me know.

That is not a random list. It is a conditional list. It checks a variety of conditions, and sets the output based on those conditions. It means that the alt event foraging_15 will happen 100% of the time if the input conditions are met, in this case: <Inputs> <Check InputAmount="15" InputFlags="" InputId="Capacity.Labor" /> </Inputs> if the first event does not meet the conditions, it checks the second event, and continues until it finds one that does meet the conditions. If none of the listed event conditions are met, it proceeds with the outputs for the list itself, whcich in this case has no effects.

To trigger the mercy shot mission, they have to be gravely wounded, gravely ill, or have black fever. Every daily reset, every character has a chance to heal or recover, and those have to fail. Because of the way the evolve events for hurt and sick in characters.xml are written, they have a significantly high total chance of recovering, as long as the enclave has medicine resources and an infirmary. The recoverfromsick and recoverfrom injury events run every 30 minutes, giving an additional chance to recover. Essentially, to get the mercy shot, a character has to be badly wounded or sick, the enclave need to be without an infirmary, and with no medicine, and then pass though two successive daily resets. In terms of the unlock for the hero, it is easiest to generate by not really playing... start a community, collect no medicine, do not build an infirmary, and wait until someone is sick or injured, log out, wait until the next day (or 14 hours), log in, log out again and wait again.

That is part of the daily reset process. Specifically, it is triggered in several places in enclaves.xml as <EventTrigger Event="SandboxEvent.Home_OfflineEvents" />, and the event itself is defined in rtsevents.xml as <Event Id="SandboxEvent.Home_OfflineEvents"> That is a long series of actions, and within it is <ExecuteAction ActionId="Foraging" />, which calls <Action ActionFlags="Subaction" ActionId="Foraging" The event basically gives you between 4-11 food each day to represent the food found by survivors not directly under your control.

Those are not probabilities. Set at 100%, they are certainties. Alt lists that use 100% depend upon the Inputs field to determine actual application, and use tracking variables to determine the appropriate stages. Those are initially set in missions.xml under the mission to locate the RV, and updated in facilities.xml as repairs are carried out. The number of repairs needed is set in enclaves.xml during map initialization as a basic scenario count. The 'randomness' comes from the enclaves.xml action <Action ActionFlags="Repeats, WaitForNoMission" ActionId="NewLoop" Alts in a list are always evaluated from top to bottom in order, and once one is selected the action is exited. <Alt AltId="SelectFinished" AltOdds="100" /> <Alt AltId="SelectEngine" AltOdds="25" /> <Alt AltId="SelectClean" AltOdds="33" /> <Alt AltId="SelectTires" AltOdds="50" /> <Alt AltId="SelectRefuel" AltOdds="100.0" /> <Alt AltId="SelectFailsafe" AltOdds="100.0" /> Here it checks if everything is finished, 100% apply if input conditions met. Then, it checks each of the four conditions... 25% for the first if not applied, 33% for the second, 50% for the third, 100% for the fourth... if the selected repair has been completed, it drops to the failsafe, 100% which simply sets no condition and it will wait until the next cycle to determine which remaining repair is needed. For those four repair types, it is effectively 25% each, even though the numbers vary. This is because the first check is 25%, or 1 in 4. The second check is 1 in 3, but takes into account that 25% have already been checked, so it is 1/3 of the remaining 75% left after the first check... 1/3*.75 = 25% The third is 1 in 2, but also takes into account that 50% have already been checked, so it is 1/2 of the remaining 50% left after the first two checks. 1/2*.5=25% And the fourth check is 1 in 1, but also takes into account that 75% has already been checked, so it is 1/1*.25 =25%

All of the spoken lines are defined in contentmanager\scenes.xml For example, compare SceneBucket Label="emote_Disagree" between the two modes.

Character voices that are not intended to be playable only have their specific lines recorded.

Yes, it does.

The file sandbox.win.bmd needs to be placed in C:\Program Files (x86)\Steam\SteamApps\common\State of Decay YOSE\Game\libs\class3.1\rts When extracted, it will initially be in \Game\sandbox\game\libs\class3.1\rts, but it will not actually be used from that location.

Game changing modding in SOD2 is extremely limited. Without UL releasing a SDK, what is available are simple modifications, such as value changes and save editing. Actually adding anything new is impossible.