Slitherine

quote:

ORIGINAL: berto

Determining on-map counter types:



... you could, for example, test to see if armor and/or artillery and/or infantry etc. were at a certain hex location or map sector.

quote:

ORIGINAL: fritzfarlig

I have to ask berto
old scenarios and update 2,0
how will it works no problem ?
I Am really looking forward to the update

quote:

ORIGINAL: berto

There are so many changes in 2.0 that, although in theory the code will be backwards compatible with pre-2.0 scenarios, as a practical matter it will be better to convert them. I will be preparing a stand-alone utility program to handle the conversions. It will probably also work that you can load older scenarios into the 2.0 game engine, then resave them. The load/save process should do the trick. In theory. We shall see how well this works in practice.

quote:

ORIGINAL: berto

Ta-da!




All buttons (and controls) fully functional and WAD.

No optional niceties yet, such as 3D button effects. Note also: 256 color, otherwise it won't display.

Moving on to the scen type screen next. Then the bigger challenge: the oversized scen select screen.

quote:

ORIGINAL: berto

The scenario type dialog:




Two down, one to go. (In this initial round of frontend revamp anyway.)

quote:

ORIGINAL: berto
Note of course that the frontend launcher EXE is no longer fixed, full-screen; rather, it's a windowed EXE just like any other.

quote:

ORIGINAL: Warhorse

SWEET!

quote:

ORIGINAL: berto

Ta-da!

implementation of a new sorting option, sorting by scenario Title

Always, always here.

_____________________________

Campaign Series Legion https://cslegion.com/
Campaign Series Lead Coder https://www.matrixgames.com/forums/tt.asp?forumid=1515
Panzer Campaigns, Panzer Battles, Civil War Battles Lead Coder https://wargameds.com

(in reply to dox44)

quote:

ORIGINAL: berto
< --snip-- >

notice also the

implementation of a new sorting option, sorting by scenario Title

Always, always here.

quote:

ORIGINAL: berto


At latest count, over 120 functions in the new Campaign Series (Lua) Event Engine:

quote:

ORIGINAL: casebier

now that is a game changer for sure. so is the lua script contained within the .ini scenario file?

quote:

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