qmjs

It doesn't get set to false again. it is false upon starting a new game, set in InitBreakdown, and stays false until you move into a home site. After that, it is always true. After moving to a new level, fatecards and enclave events can happen while you are at the RV... which is your homesite, claimed.

OutputDuration=0 means that it stays at that value until explicitly changed by a different command. In this case, the variable is being used to ensure that fatecards and mission requests don't show up until you have a home base. It gets set to true again in rtsevents when you move into a base or relocate from one base to another.

I would assume that was Phacop's Multitool, but it hasn't been around for some time.

Return to mission area is entirely different from the "the time it needed to reach the mission site before mission expires". I am not sure about the out of range timer, but the range is adjustable at each stage through AbortRadius. If you changed the start conditions and removed the npc interaction, it is likely that it is the npc you were supposed to talk to. You may want to try adjusting the setup flags in the header.

All three variants are 1800 seconds, 30 minutes, standard OpportunityTimeout value in mission header.

It is handled by the simulation, not directly modifiable. The most you can do for that is to check the rtsdata values for SimDefKillChance and SimVIPKillChance

An Endangered enclave should break up with trust under 100 and disappear. However, if the trust is still 100, Action ActionFlags="Repeats" ActionId="To Join (max trust)" runs, and will immediately change them to Join again So, perhaps it is not actually changing the trust level. Try replacing that line with: <Enclave_AddTrust DisableBonus="false" EnclaveIndex="" Trust="-70" /> <Enclave_StatSetBool DurationCancellable="" EnclaveIndex="" OutputAmount="true" OutputDuration="5m" OutputStat="Blackout_TrustStateChange" PauseWhenOffline="" /> and see if that makes a difference. (You probably want to disable or alter the breakup timer as well.)

Technically, the pause when offline means that the timers related to the mission don't count time spent offline, but in effect it keeps missions active that would otherwise timeout or expire.

If you were testing using an existing enclave in the Join state, it is because the mission will be locked in to the save because of the PauseWhenOffline="True" in ActionId="AddMission (init)". That makes it persist across save/load events. For the Breakup timer, it is probably because of the ExecuteTimeStandard="1d" making it take a long time to check the event again.

Yes, follow what I said above, but I need to expand upon "lower trust a bit". In the missions, for each one in the mission bucket, add a trust loss line so it is below 100, and the breakup timer is then active. Or you could add an alt to the breakup timer that lowers it a bit every day, and that would allow some to disband, and others to drop back to friendly.

Until you visit them, they will just periodically say on the radio "Given any thought to our offer yet?" Once you do visit, if you decline to have them join, they will eventually just disappear. I think the easiest way to achieve what you want is to change the ActionId="Breakup (Timer)" Instead of them disbanding, change the state to friendly again, <ChangeState ActorIndex="" Silent="false" State="Friendly" />, and lower trust a bit so they don't immediately change back to the Join state (not too low or they will drop to a lower state). They will give normal missions for a while, and eventually gain trust and allow you to recruit, and if you decline again, they go back to friendly... they should always stay on the map and you will still get the option to recruit them later if you need more people.

Each enclave can have only one active mission. The only mission they have, assigned immediately, is <Action ActionFlags="WaitForNoMission" ActionId="AddMission (init)" ActionType="Action.Passive" ExecuteTimeStandard="0.0" OutputDelayTime="0.0" PauseWhenOffline="True"> <RTSActionIcon Name="" Id="" /> <NameText Flags="" Notes="" Text="" /> <Actors /> <Alts /> <Effects /> <Inputs /> <Outputs> <Mission_Create CreatedEventTrigger="" KeepTrying="" Mission="encJoinEscort" RtsDataAbort="" RtsDataDecline="" RtsDataSuccess="" TargetEnclave="" UseEnclaveStats="" /> </Outputs> </Action> Unless you wanted them to not be able to be recruited, they won't be able to offer other missions.

I agree.

Yes, it does. The exe monitors the TimePlayedToday and triggers the <OnNextDay> condition during game load.

Most variables are not reset when exiting and restarting the game, but a few things are. Fatecards timers restart at 0, hordes events are all removed and restarted, and zombie densities are recalculated. The actual daily reset is called by the <OnNextDay> process found at the beginning of the enclave state module. IncrementDaysOffline is used to check to see if the daily reset processes one day or two (maximum), with the action CallNextDayEvent starting EventTrigger Event="SandboxEvent_Home_DailyReset". The <Check InputAmount="10" InputFlags="" InputId="Status.DailySummary.TimePlayedToday" /> baiscally is simply used to initiate the process when starting the game, so it is the first thing that occurs. After the reset runs, ClearCounters sets these to 0: <RTSStat_Set DurationCancellable="" OutputAmount="0" OutputDuration="" OutputId="Status.DailySummary.TimePlayedToday" PauseWhenOffline="" /> <RTSStat_Set DurationCancellable="" OutputAmount="0" OutputDuration="" OutputId="Status.DailySummary.DaysOffline" PauseWhenOffline="" /> If the reset is not yet ready, this runs repeatedly: <Action ActionFlags="Hidden, Repeats" ActionId="UpdatePlayedToday" ActionType="Action.Passive" ExecuteTimeStandard="1s" OutputDelayTime="0.0" PauseWhenOffline="True"> <RTSActionIcon Name="" Id="" /> <NameText Flags="" Notes="" Text="" /> <Actors /> <Alts /> <Effects /> <Inputs /> <Outputs> <EventTrigger Event="fsEvent.UpdatePlayedToday" /> </Outputs> </Action> Which does this: <Inputs> <Check InputAmount="<60000" InputFlags="" InputId="Status.DailySummary.TimePlayedToday" /> </Inputs> <Outputs> <RTSStat_Add DurationCancellable="" OutputAmount="1" OutputDuration="" OutputId="Status.DailySummary.TimePlayedToday" PauseWhenOffline="" /> </Outputs> The actual daily reset itself is a 14 hour cycle (rtsdata <Value Default="50400" Name="NextDayTime">) So essentially this is the process: New game, time is set to 0, or when the daily reset is done, the time is set to 0. This value is saved when exiting. (It is also calculated from the save game time difference.) You may enter and exit the game any number of times before Status.DailySummary.TimePlayedToday reaches 50400 or more and it will be the same day. If you are playing and it counts up to 60000, the time stops counting. Continuing to count up is essentially pointless, for the next reason. As long as you continue to play, the next game process doesn't run. When loading a game, if the timer is 50400 or more, OR if the actual save game date/time difference is over 50400, the next day process is initiated upon loading. A couple of observations: you could reset the 50400 to a different value as long as the 60000 is a larger number. The way it is set up now, you will only get one daily reset per day no matter how much you are playing. In the original game (one of the first patch changes made) the game did not stop counting days offline at 2. You could go a week without playing and come back to a total mess... everyone sick or dead, all resources used up, and so on.

Yes, but within an action, only one will run... once an Alt does run, the entire action is exited, so you will only get one result from each block of action and alts each time it is called. Foraging_15 has 100% chance to run, so inputs are checked... if 15 labor it runs and you get 11 food and the entire action exits. Less than 15 labor and it fails the inputs and moves to the next alt. Foraging_13 then has 100% chance to run, so inputs are checked... if 13 labor it runs and you get 10 food and the entire action exits. Less than 13 labor and it fails the inputs and moves to the next alt. This continues through foraging_11, foraging_9, and foraging_7. If foraging_7 fails, it then goes to he parent action, ActionId="Foraging" This one has no inputs, so it will automatically run, but it has no outputs, so you don't get anything from it. The best result is first, and each gets weaker as it moves down the list and you have less people available to forage... so you get less food found.

That is correct. When an action that has Alts runs, it checks the first one in the list. AltOdds is the chance that the Alt is selected, and if the input conditions are met it runs. If either fails (percentage check or input conditions), it then moves to the next one and checks it. If all Alts fail to run, the base action is then checked for input conditions. It is possible for all Alts and the main Action to not run if the input conditions are not met.

For "Establish_SandboxGeneric_Characters", it works because it is called via ExecuteAction instead of as an ALT action. The difference is that it is defined as a subaction instead of an ALT, and must be called from inside each action that will require it. <Action ActionFlags="Subaction" ActionId="Establish_SandboxGeneric_Characters" If the ActionFlag was an <Action ActionFlags="Alt" it must be in the same block as the Action that calls it. Subactions can be outside the block, within the same file, but have to be called specifically. This is similar to <EventTrigger Event= which calls to rtsevents. So in that case, your code block example: <Action....ActionFlag="repeats"...ActionID="A" AltID BCD </Action> <Action..ActionFlag="repeats"....ActionID="B" AltID BCD </Action> <Action....ActionFlag="ALT"..ActionID="BCD" </Action> would not work, but it would if done as <Action....ActionFlag="repeats"...ActionID="A" <ExecuteAction ActionId="BCD" </Action> <Action..ActionFlag="repeats"....ActionID="B" <ExecuteAction ActionId="BCD" </Action> <Action....ActionFlag="subaction"..ActionID="BCD" </Action> If you still had multiple ALTS within the Action blocks, each one would need to include the ExecuteAction call.

Ah, no, that won't work. It does need to be included in each level it will affect. You could combine them together into one large group. In that example, combining the lists from SelectWeapon1,SelectWeapon2,SelectWeapon3,SelectWeapon4 into one large set of alts, and then putting the resulting actions and the failsafe together would work.

Ok, I think you mean Event Id="Lifeline.RandomWeapon" ? As long as there is only one copy of the FailSafe alt under each level it should work fine, but for readability purposes I'd change the name slightly. If you need to go back and adjust, that makes it much easier to keep track of where you are. Some of those lists are not set up correctly though. Several have the last two options set at 100... which means the first of them will always be selected and the last never gets considered. "Alt" ActionId="SelectWeapon1" is correct "Alt" ActionId="SelectWeapon2", "Alt" ActionId="SelectWeapon3", "Alt" ActionId="SelectWeapon4", and in fact 3 and 4 have two weapons each that will never be seen.

Some of those are just wasted space left over from copy-paste actions when creating different home enclave states. Before a command center exists you can't use Radio_Survivors, because there is no command center facility. Because of this, the actions in <State Alertness="Defending" Id="Arrive">, <State Alertness="Defending" Id="Sandbox_LoneWolf_FindCommunity"> are impossible. While available, I don't think <State Alertness="Defending" Id="Sandbox_BustedRV_FindHome">,<State Alertness="Defending" Id="Sandbox_LoadUp"> are actually generally used at that state. So <State Alertness="Relax" Id="Sandbox_Core"> is typically the event that would get called. All it does is call the event once the variable is set. There is no direct reason why you could not remove the five Actions from Enclaves, and put the fsEvent.BroadcastSurvivors into the facility action. However, it is likely tied to Status.Recent.Broadcast, as that is generally set by the exe itself (it is checked in a number of places, but not set anywhere in the xml files), and the blackout system, which limits the number of active missions and the type of active missions on the map. You might end up with more than the normal number (+1) if you do it that way, but I am not really certain.

Check is used in rtsevents when they want to evaluate how many people are not currently busy, as in being available to forage. These typically are evaluated in the daily events, and do not assign tired status or reduce labor available for tasks initiated by the player as it is assumed to have already happened during the daily reset period. Check is evaluated as true/false. Input is used when an action requires people who are not busy or tired (available labor), and in the outputs of the action they will be assigned a tired status and labor is reduced for a period of time: <Output ActorIndex="" DurationCancellable="" NonstackingCategory="" OutputAmount="-2" OutputDuration="0.334" OutputFlags="" OutputId="Capacity.Labor" PauseWhenOffline="" /> <Scene_ScenePlay Scene="Construction_Complete" SceneReason="Chatter" /> <Actor_EvolveTraits ActorIndex="0" Event="TIRED" EventLogOutput="General" /> <Actor_EvolveTraits ActorIndex="1" Event="TIRED" EventLogOutput="General" /> These are used to limit how much survivors are capable of in a given timeframe, as they can't carry out a bunch of tasks at the same time. input is similar to spend, but spend is a permanent reduction. Using Input and then setting the labor reduction period with the OutputDuration makes it temporary.

Nothing at all. It is a generic event included in all enclaves, in story mode, breakdown, and Lifeline. I don't think it is ever used, but was probably just a holdover from an early enclave template.

You're right... I didn't check those, just noticed it when looking for something else. I had assumed they were in globalconstants alongside the ones like this: <Constant> <Name>nStaminaBonus_Exercise</Name> <Value>10</Value> </Constant> But I don't see them anywhere either. It could be in the exe, or possibly just unused code left over.

I don't know if there is an actual limit. Most calculations use a single decimal point (1.2, 1.5) Also, regarding variables as defined in globalconstants, some examples used in calculations can be found in characters.xml as such: <RTSStat_Add DurationCancellable="" OutputAmount="[hp_HealthPenalty_Med]" OutputDuration="" OutputId="Character.HealthBonus" PauseWhenOffline="" /> <RTSStat_Add DurationCancellable="" OutputAmount="[hp_StaminaPenalty_Med]" OutputDuration="" OutputId="Character.StaminaBonus" PauseWhenOffline="" />