qmjs

I haven't looked at that in a while, but from what I see on a quick look, it does not set them as away directly, even though they get the trait.status.away set when they are away from base. It seems to be set when they are on a mission, particularly the three general status missions (thin the herd, supply lines, search and rescue). (Lifeline.Tactics.SupplyLines, Lifeline.Tactics.ThinHerd, Lifeline.Tactics.SearchRescue ) I'd look at missions, facilities, enclaves, and rtsevents... it is likely to be in there if anywhere.

Yep, been messing around with this game for years and years.

Fair enough, but I have worked with other modders for years, and fairly soon after they start making those sorts of changes they just sort of disappear... I have always assumed it was because it got too easy that it was boring.

You could, but what would be the point? If your survivors can't die, resources are plentiful, and zombies die easily, what are you actually going to do in the game? I think it would get boring fast.

There really isn't one, and I suspect the effects are again in the statemachine, but I am not sure. You could possibly work with expertise using the npceffects, but there are none actually used in the game already, so that may not be implemented.

For the Sandbox.Drifter.HomeSiteClaimed To test to make sure, I think the easiest thing to do would be to add an action under the Event.Update30s BAsically, if it is false put up a message. On a new game it should show up in the log frequently until you settle a base. Then, moving to the next level.. if it resets to false the message will appear again.

aaronpriced, Those are a part of the statemachine, and aren't reachable for modification.

When blank, it defaults to 0. That one should only be useable when starting a completely new game. It is also different in that it is to supposed to be used settle a home base when you don't have one: Text="Settle Home Base" Text="HOME. Settle your home base in the home site you are currently standing inside." While the other is: Text="Relocate Home Base" Text="HOME. Moves your home base from its current home site to the home site you are currently standing inside." i suspect it is simply that the fame (renown) and starting influence is being set, but I haven't had the chance to dig through for that, probably in rtsevents, either community reset or starting inventory.

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.