-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mission deadlines supports dialogue variables #77047
Mission deadlines supports dialogue variables #77047
Conversation
Found a problem in my implementation: It previously accepted integers as a valid input and counted them as days. dur_or_var also accepts integers as input, but counts them as seconds. Now I could work around that, but at that point I might as well rip out the old json loading and replace the few instances we have in repo with a single |
ce4b978
to
5d32994
Compare
5d32994
to
842670f
Compare
Found out deadlines were undocumented when I went to change the documentation for them :( Then found a bunch more undocumented stuff so threw all that in there too |
Sorry but this commit is just churn
Summary
Features "Mission deadlines supports dialogue variables"
Purpose of change
Mission deadlines are almost unused, despite being one of the most obvious things any good 'quest' should have.
Also the whole point of giving out the "faction succession" mission was to show the cooldown before you can do it again. There wasn't a way to actually put in the cooldown. This PR lets us put in the cooldown, and display the timer appropriately.
Describe the solution
load the deadline as a dur_or_var,
which means that existing durations can be loaded seamlessly while also supporting newly loaded dialogue variableswhich supports times, integers, math expressions, and variable objects. This did end up taking out the old deadline_low and deadline_high, as previous code assumed their values were days.Add a kwarg( /optional argument?) to assign_mission allowing access to mission::set_deadline
...Also a fix for EOC_FACTION_SUCCESSION_CHECK which still had a coded value of checking against the old 90-day cooldown, instead of the npctalkvar
time_between_succession
Describe alternatives you've considered
the game_start and game_begin events require some really, really stupid piping. I'd strongly consider reversing their order so game_begin always runs first if it could be done easily.
Testing
2024-10-14.13-18-39.mp4
Additional context