Intermediate Guide to Scripting Discussion

[Epistolary Richard]

I've posted a sequel to the beginner guide to scripting in the Scriptorium by myself and Myrddraal. If people have any questions coming out of that guide, feel free to ask them here.

[alpaca]

Good one
You know that you can use "while TrueCondition" to loop forever?
You only need to do that thing with the counter if you want an escape condition for the script.

[Monkwarrior]

Thanks ER. Nice tutorial. I'm waiting for the advanced one.

I'd like to know something about the compatibility of scripts with patches.

Does a script for 1.2 work with 1.3?
I think there are commands available in 1.3 but not in 1.2, so perhaps the opposite is not always possible, but I'm not sure if some of the commands in 1.2 are deactivated in 1.3.

@alpaca
Could you please give an example of the use of "while TrueCondition"?
Thanks in advance.

[Epistolary Richard]

Cool idea, alpaca.

I think, Monkwarrior he just means that adding

while TrueCondition
end_while

at the bottom of the script will keep it looping without the need for the loop counter.

There won't be a single advanced guide as - to be honest - the first two cover the conceptual ground needed to get you started. I've no experience of coding languages aside from RTW so this was the sort of thing I needed to get going.

From here, we'll start pulling out the scripts used in actual mods and talking people through how they function. The 'Advanced Guide' will be lots and lots of different analyses contributed (hopefully) by many of the community scripters.

As for patch compatibility - you have to remember that the scripting language was not originally intended to be in RTW - as was only shoe-horned in there at the last minute largely for the purpose of the Prologue. So there were no changes in scripting from 1.0 to 1.2.

There are a few new scripting things in BI - as you can see by comparing the old and new docudemon files - not sure if they're in 1.3 as well.

One of the more interesting ones is the Reload event, and potentially using it to bring up an Advisor to prompt the background script. I haven't had a crack at that one yet.

[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.