Intermediate Guide to Scripting Discussion

[alpaca]

Ya that was exactly what I meant ;)
However, you should theoretically also be able to differentiate different sequential parts of a script (for example PreEvent and AfterEvent parts) by specifying a counter loop like this example:

declare_counter event_triggered
.
.
.
monitor_event
set_counter event_triggered 1
terminate_monitor
end_monitor

while I_CompareCounter event_triggered = 0
end_while
.
.
.
while TrueCondition
end

What this does is loop the first part until event_triggered is set to 1, which happens when you reach your desired event, and then starts looping the second part. This struct is what I meant with "escape condition"; if you want to use it, make sure that all your monitors in the first part look like this:

monitor_*
if I_CompareCounter event_triggered = 0
...code...
end_if
if not I_CompareCounter event_triggered = 0
terminate_monitor
end_if
end_monitor

So that they are destroyed when we hit our event.
I'm not sure whether monitors are pre-loaded when the script starts executing, but if they are, you also need to make the monitors of the second part look like this:

monitor_*
if I_CompareCounter event_triggered = 1
...code...
end_if
end_monitor

Might be useful for some stuff, I don't know ;) I just derived this from my programming skills.

[The_Mark]

Woah. I really need to get out of the EB forums more often.


May I add one piece of information about the condition monitors?

It is, if you use an I_CompareCounter conditional in a condition monitor and try to modify the counter affecting the monitor from within the same monitor it won't work. E.g.

monitor_conditions I_CompareCounter counter = 1
set_counter counter 0
console_command add_money 1
end_monitor

won't work. The monitor loop will not end and will add infinite amounts of money once the counter activates the monitor once. This has something to do with monitor (and script) state saving (which shouldn't actually be there), but that goes mostly beyond my knowledge. But, you can do a workaround by using two monitors, both affecting each other's counter, like this:

monitor_conditions I_CompareCounter counter_1 = 1
console_command add_money 1
;and do other stuff
set_counter counter_2 1
end_monitor

monitor_conditions I_CompareCounter counter_2 = 1
set_counter counter_1 0
end_monitor

Though, the initial piece of script setting the counter_1 to 1 must also set counter_2 to 0 to prevent the other monitor from disabling the first prematurely.

Please notify me if I'm rambling, I'm quite tired after a rough week so the post may be somewhat inconsistent, or just poorly laid-out.

[Myrddraal]

very good point The Mark

alpaca, note that if you don't include terminate_monitor in the first monitor, then the script will wait for the event to be triggered, but that event could be triggered multiple times...

[alpaca]

I know, that's why they are terminated once the counter becomes non-zero and they are invoked...
Or did you mean something else?

[The_Mark]

Adding a thing about condition monitors and counters, the I_CompareCounter can be placed in an if just after the monitor. Much neater than using two monitors,a nd much simpler, too. Prolly that's why I didn't think of it earlier.

monitor_conditions condition
if I_CompareCounter
stuff
end_if
end_monitor

[Duke John]

I am trying to test the value of a character's trait during a turn and I had hoped that the following would work:

script

console_command give_trait Barrivendos GoodCommander

monitor_conditions not I_CharacterSelected Barrivendos
and Trait GoodCommander >= 1
	console_command give_trait Barrivendos GoodAttacker
terminate_monitor
end_monitor

end_script

But it does not Can anyone see what is wrong?

Barrivendos does get the GoodCommander trait which should have a value of 1. Then the not I_CharacterSelected Barrivendos should put the focus on the character which then allows testing the value of the GoodCommander trait. Or doesn't it work like that?

Any help would be greatly appreciated!

[The_Mark]

What you need to get the Trait condition work is an exported character_record, and condition monitors don't export values; you'll need an event monitor, and convenient events to do that are far and few between.