A Guide to Events

[Callistonian]

There are so many things I've never seen before going on in your code that I can't tell if you're scripting at a really advanced level or just making things up and hoping they work the way you want.

First, I've never seen monitor_event being nested inside another monitor_event. Even if it works in the sense of not throwing any errors, I don't understand the logic or intention of nesting of them like this.

Second, I've never seen _accepted/_declined being appended to an event name like that. As far as I know, that only works for historic_events because the game generates event counters with those suffixes when accept/decline decisions are made. It's news to me that the game does this in any other context and, if it works, I'd appreciate if you could explain how you discovered this and provide a list of similar working event-generated counters.

Third, I've never seen a comma used instead of a line return to separate commands. I would have assumed that would prevent CS from parsing.

Finally, e_select_character selects the character exported in the current event context, and since you've put this command inside an EventCounter monitor which doesn't export character_record, I would assume this command does nothing and therefore the character referred to by 'this' in the subsequent command is null since nobody is selected. But again, I've never seen monitors nested inside one another so who knows...



As for making a suggestion towards your original goal: there is only one event that fires when an adoption is accepted: BrotherAdopted, which iirc exports the character who gained the brother through adoption, not the brother himself. This event is obviously very limited in its application. Again, if your _accepted/_declined event counters exist, please let us know, that would potentially be a huge breakthrough for campaign scripting.


Edit: I've skimmed through OP's guide. He seems pretty convinced that nesting monitors works, but he provides no motivation for doing this. It should work the same and be more readable to have your monitors separate from one another. And anyway, there is no reason to use additional monitors for this. OP himself seems to know the virtues of while loops, and the most widely accepted way to handle yes/no decisions is like this:

historic_event my_event true
while my_event_accepted == 0
and my_event_declined == 0
end_while
if my_event_accepted == 1
 ;do stuff for accept
end_if
if my_event_declined == 1
 ;do stuff for decline
end_if

An even more efficient system for this whole thing is to have only one EventCounter monitor which is used as a universal function caller.

historic_event my_event true

monitor_event EventCounter TrueCondition
 if I_EventCounter my_event_accepted > 0
  set_event_counter my_event_accepted 0
  ;do stuff for accept
 end_if
 if I_EventCounter my_event_declined > 0
  set_event_counter my_event_declined 0
  ;do stuff for decline
 end_if

 ;all other event counter calls here

end_monitor

Assuming nested monitors works, my next guess would be that your script fails because your _accepted/_declined event counters don't exist.

[dmnet]

Many thanks for the detailed answer. I'll try your suggestions :).

Re: your questions
I'm not sure if _accepted/_declined is generated for events other than historic events (I thought the game might do that for all kinds of events) but as the code inside the nested monitors is not executed, I assume you're right and it simply doesn't generate such event counters.

The usage of

e_select_character [comma] console_command [...]

is mentioned in M2TW Ultimate Docudemons. I also used the command directly indide the main monitor "monitor_event LesserGeneralOfferedForAdoption FactionIsLocal" and it didn't generate an error or stopped the script from parsing.

with comma:

[game.script.exec] [trace] exec <e_select_character> at line 7174

with new line:

[game.script.exec] [trace] exec <e_select_character> at line 7174
[game.script.exec] [trace] exec <console_command> at line 7175

However, as this all happens before the decision is made, <give_trait> doesn't do anything, as the character is still a "simple captain".

The adoption only happens afterwards (next line in log):

[game.script.trigger] [trace] Trigger <LesserGeneralOfferedForAdoption_Adopted> fired

Is there a way to use the trigger for my purpose?

General question: Do you think my goal is achievable without using additional resources like EOP?

Another question: What is "OP's guide" and where can I find it?

[Callistonian]

As we can see in your log, the comma is having the effect of separating the commands into two lines. It's nice to know that's possible.

There are many events, such as LesserGeneralOfferedForAdoption_Adopted, which 'fire' and are logged but cannot be monitored in conventional scripts. As far as I know, EOP does not have a way to monitor such events either (I actually added the vanilla adoption events to EOP myself), although it is possible in principle. I have asked Jojo about this before but I never figured out how to implement it (I was trying to do this for the event when a unit is removed from the recruitment queue). Also, as far as I know, changing character bodyguards in EOP is still almost as wonky as a conventional campaign script. It is only possible to assign a BG unit that already exists in the stack (i.e. you're just transferring the general from one unit to another), which means you have to check if the stack is full, move it somewhere if it is, add the new unit, remove the old unit. It's superior in the sense that this can be done for any character, even if you don't know their name/label (which is the real bottleneck for your plan because you must know name/label before sending off and respawning).

"OP" is the original poster of this thread, his guide is on the first page in the first few posts. I presume you've already seen it since your original code seems to be based on his advice. Know that this is a really old thread and that scripting techniques have improved a lot since 2011, not to mention Lua scripting with EOP.

[dmnet]

"OP" is the original poster of this thread, his guide is on the first page in the first few posts. I presume you've already seen it since your original code seems to be based on his advice.

I didn't get OP = original poster Yes, I based my first attemps on the guide in this thread.


Today, I tried various approaches with the classic campaign script but couldn't get the character's name/label. Then I installed EOP and it was done with a few lines of code.

Thanks for your help, Callistonian!

[Callistonian]

This is one of the main benefits of EOP and Lua scripting. The ability to identify basically any character on the map allows us to do things with those characters that was previously only possible with know (labelled) characters.

Did you manage to create an event function for LesserGeneralOfferedForAdoption_Adopted?

[dmnet]

Yes, it's pretty cool.

No, I did't create an event function, I went the easy way :).

I simply added a new trait + trigger for On LesserGeneralOfferedForAdoption and use the EOP Event onCharacterSelected(selectedChar). If the trait exists, I call a new function to do the stuff and then remove the trait again. As you always select the character at one point, it's almost as good as a dedicated event function.

The overhead is ignorable but automating that (i.e. create the necessary event function) is the next step, though.

However, I'm a bit confused as to why the adopted character is a family member but doesn't show up in the family tree. But that's probably a question for another thread.