ORIGINAL: berto
Introducing a new on_* function: on_startup()
on_startup() is run once, at scenario (or save game) load and startup. It has no input parameters.
Here is a test example:
(The function definition for on_next_turn(turn) follows. Note that you would probably want, as in this example, to locate the on_startup() definition at the very beginning of the <scenario>.lua file. You would define on_startup() in your scenario-specific .lua files,
not in user.lua. Defining on_startup() in your <scenario>.lua file is not absolutely necessary. The Lua EE will not choke or complain if it doesn't see it.)
With that in place, if you launch the scenario, you would see this:
"Okay," you may be thinking to yourself. "So what?"
Well, what if you have a commander, and you know that counter's trackid? (In this case 363.) (Maybe you know the counter's trackid by inspecting the .scn file.) You can set the (scenario-specific) global value THE_KING (or whatever you name it) to that trackid. Thereafter, you don't need to reference the trackid; you could instead reference its label. For instance:
(You might note where I have added trackid as one of the on_unit_kill() input parameters. New EXEs with this, also the new on_startup() function, will be released soon.)
Let's try it out ...
... After unit 363 was killed, I saw this:
Then checking the Victory Dialog, I saw this:
(There is another way to set the loss points for this unit so high: in edorg, in the .org file. But this is another way. Doing it this way also lets us apply different special conditions, or perhaps vary the lost EPs according to circumstances or some computed formula.)
Likewise, we could reference VIP in our Lua code. VIP is much more meaningful than the number 1287.
So too THE_CASTLE. On capture/loss of that objective (indeed even if it's not a formal objective), we could trigger something to happen. By using THE_CASTLE in our code, it is more readable and sensible than seeing the "20,55".
We will adopt the convention to have all on_startup() labels be all caps (but it is not mandatory).
on_startup() can be used to
[*]Display a greeting (or whatever) dialog at scenario startup. (Showing at startup only, because sited in on_startup(), guaranteed never to recur.) (In the test example shown above, displaying that message was for demonstration and testing purposes only. Ordinarily one would not show label assignments in this way; on_startup() would just do them silently.)
[*]Set some meaningful value labels.
[*]Do other set-up processing.
You could do these same tasks in the ordinary on_next_turn() function, and guarantee they are only done once by putting an 'if turn == 1' wrapper around things. But doing it in on_startup() is cleaner, and guaranteed to happen only once.
(Note that on_startup() doesn't preclude any global initializations you might otherwise do in your (optional) user.lua file. But any such initializations would apply to
all scenarios, since user.lua is general in scope.)