Printable View
I'm having trouble with the advance_advice_thread command. It only works the first time for each thread, after that the command is ignored. Probably to avoid advice being given more then once. But is there a was to bypass this system ? Or am I missing something ?
Yeah, that command's a bugger.
The thread count for advice threads in incremented across all the games that are played - because the intention behind it all was that the player would only ever need to see a piece of advice once. The incremenation is stored in a text file, I think above the data folder? I can't remember exactly.
Where pieces of advice are repetitive in the vanilla game it'll be because their trigger in eda will have a last line like:
So when the conditions are met, the advice thread is activated but it isn't incremented, so the next time the conditions are met again (say a request advice button has been pushed) the same advice thread will pop up.Code:AdviceThread XXXX_Thread 0
Unfortunately the advance_advice_thread command does actually increment the advice thread by 1 (so it appears) so the first time the conditions are met the trigger will fire and it will increment the thread, that means the second time the trigger fires, the threadcount is no longer 0 so the advice no longer appears (it looks around for the related threshold 2 advice thread, which won't exist). I think that's what's happening at least.
So work arounds would vary depending on exactly how your scripts are interacting, the most obvious one is to put the trigger in eda instead of in your background script - but that assumes you're not suspending unscripted advice. Alternatively, it's a matter of fiddling with the parameters of the advice thread to get the threshold, maxrepeats etc. to get the result you want. I still don't fully understand how the different advice thread variables work, and some of them (like attitude and so forth) don't appear to make any difference at all.
Or alternatively, the one place that threads are advanced consistently in the vanilla game is in the prologue - but the impact of a declare_prologue command is still somewhat of an undiscovered country. I only dabbled with it in the Totally Random Total War mod.
ok thanks. So what would be the best way to launch a background script ? The player using the F1 method ? or linking it with some HUD element ?
To be honest, that's still in the air. The answer really depends on how mod users take to it. Myrddraal's scripts in the beginning used the F1 method because it was a useful method for beta-testing, it could be activated but equally it wasn't so obstrusive that it would get in the way. It was there if you knew what you were doing. Because other modders have been using his multiple turn script, they've also transposed the F1 method.
I know that EB, we're aware that many of the mod users won't be big modders themselves and it won't necessarily be easy for them to get into the routine of the whole "Press f1, press request advice, press show_me" routine every time they reload, so we've looked into integrating it more naturally, so when they reload they'll be prompted to start the script when clicking on a HUD element or a settlement or the like. Now, that wasn't straightforward to implement, but it was our opinion that it was more in line with that mod's intended wide appeal.
There have been very few major mods released that have had an integrated background script to date (I think TFT, I'm not sure of any others) and that I think was an optional four turn addition.
After a few major mods are released a community standard will develop, as the mod users will get used to a particular method, right at the moment though, it's a compromise between ease of implementation for the modder and the ease by which the mod-user will be reminded of the requirement to reactivate.
Of course the new Reload event that Guy put into the BI release might change all that for mods intended for BI. We'll have to see how it operates.
TFT is using click-on-a-settlement to make the advisor appear. So far I haven't heard any complaints, and most of the time a player will click on a settlement in the natural course of events when they start/continue a game. Even if they forget the first turn they continue a game, clicking on one the next turn is good enough for starting the four-turns-per-year portion of the script. The rest of the script's functions are not as time sensitive.Quote:
Originally Posted by Epistolary Richard
So this is our Crassus/Gauls campaign code from the EDA (note that only brutii, scipii, julii, gauls and eventually parthia are playable in TFT, and thus the not I_LocalFaction conditions - those factions have their own triggers as the start date differs for their campaigns):
Code:;------------------------------------------ TFT_Campaign
AdviceThread TFT_Licinii_Campaign_Thread
GameArea Campaign
Item TFT_Campaign_Text_01
Uninhibitable
Verbosity 0
Threshold 1
Attitude Normal
Presentation Default
Title TFT_Campaign_Text_01_Title
Script scripts\show_me\Crassus_TFT_Campaign.txt
Text TFT_Campaign_Text_01_Text1
;------------------------------------------ TFT Campaign
Trigger 2300a_TFT_Campaign_Thread_Trigger
WhenToTest SettlementSelected
Condition not I_LocalFaction romans_julii
and not I_LocalFaction romans_scipii
and not I_LocalFaction parthia
AdviceThread TFT_Licinii_Campaign_Thread 0
Ah, thank you Stuie, I stand corrected :beam: