quote:

ORIGINAL: **budd**

can a link for that info somehow be put under the help menu in game for us nato idiots[:)]

quote:

ORIGINAL: berto


Credit goes to Crossroads, leader of the UI Improvement Project, and principal designer of the revamped UI. He does the design and graphics, I do the coding.

quote:

ORIGINAL: phoenix

Nice! Great, clean, clear style. Is this still a long way off?

quote:

ORIGINAL: berto

Here are the EE Lua functions implemented thus far:

---

adaptive_ai(side, nation, index)
advantage()
aggressiveness(side)
ai(side)
ai_index(parm)
ai_parameter(index)
air_support(side)
ammo_level(side)
arty_ammo_level(side)
current_side()
current_turn()
event_points(side)
fow(side)
hexcoor(x, y)
isai(side)
isfow(side)
major_defeat()
major_victory()
message(string)
minor_defeat()
minor_victory()
objective_owner(x, y)
objective_value(x, y)
on_air_attack(x, y, pid, name, side, nation, points, strength)
on_next_phase(turn, side)
on_next_turn(turn)
on_objective_capture(x, y, value, side)
on_unit_kill(x, y, pid, name, side, nation, oid, orgname, points, strength, HQ, Leader)
on_unit_reinforce(x, y, pid, name, side, nation, oid, orgname, points, strength, HQ, Leader)
on_unit_release(pid, name, side, nation, oid, orgname, points, strength, HQ, Leader)
on_unit_remove(x, y, pid, name, side, nation, oid, orgname, points, strength, HQ, Leader)
other_side(side)
random(x)
reinforcement_count(id)
reinforcement_flags(id)
reinforcement_hexcoor(id)
reinforcement_prob(id)
reinforcement_scatter(id)
reinforcement_turn(id)
reinforcement_x(id)
reinforcement_y(id)
release_prob(id)
release_track(id)
release_turn(id)
set_adaptive_ai(side, nation, index, value)
set_advantage(value)
set_aggressiveness(side, value)
set_air_support(side, value)
set_ammo_level(side, value)
set_arty_ammo_level(side, value)
set_event_points(side, value)
set_major_defeat(value)
set_major_victory(value)
set_minor_defeat(value)
set_minor_victory(value)
set_objective(x, y, value, side)
set_objective_owner(x, y, side)
set_objective_value(x, y, value)
set_reinforcement(id, x, y, turn, prob, count, flags, scatter)
set_reinforcement_count(id, count)
set_reinforcement_flags(id, flags)
set_reinforcement_hexcoor(id, hexcoor)
set_reinforcement_prob(id, prob)
set_reinforcement_scatter(id, scatter)
set_reinforcement_turn(id, turn)
set_reinforcement_x(id, x)
set_reinforcement_y(id, y)
set_release(id, turn, prob, track)
set_release_prob(id, prob)
set_release_track(id, track)
set_release_turn(id, turn)
set_smoke_ammo(side, value)
set_star_shells(side, value)
set_victory(majorfeat, minordefeat, minorvictory, majorvictory)
smoke_ammo(side)
star_shells(side)

---

That's 76 functions. More to follow of course.

quote:

ORIGINAL: Big Ivan

I'm starved for another sneak peak, oh please, oh pretty please with sugar on it!!![sm=happy0065.gif]

quote:

ORIGINAL: berto

Here's another cool new feature in today's release: user.lua.

When the game engine launches, one of the first things it does is to fire up the Lua EE engine. One of the first things in that start-up is to load and process the init.lua file -- this to set the stage, define some general variables and some but not all of the available Lua functions. (Many of the Lua functions are defined not in init.lua, rather in the C++ code.)

In the process of writing Lua code in the various <scenario>.lua files, what if the scenario designer finds himself writing the same code over and over? What if he gets the idea to write some new generalized functions? That he would want to use widely, again and again, across many different <scenario>.lua scripts. That's potentially a lot of needless repetition. More work, harder to keep things in sync across the many <scenario>.lua scripts, potentially more bugs.

This is where user.lua comes into play. user.lua is a new file in the top-level game folder. It is entirely optional. If absent, the game engine Lua EE start-up sequence won't complain. But if present, it will be processed much like init.lua. (init.lua is loaded up and processed first, then user.lua immediately following.)

Ordinarily, you should leave init.lua untouched. You may reference functions etc. therein, but you the user/designer/modder should otherwise leave it entirely alone. For now, init.lua is my baby. (And we will take steps to "encrypt" it, removing all possibility of user meddling.) You may however create a user.lua file and stuff it with things as you please.

In today's release, I have an example user.lua file:

[image]local://upfiles/5869/5DA17E53413541079CEDFDF56BE23706.jpg[/image]

Which defines five map-location functions:

---

function nw_quad(x, y)
function ne_quad(x, y)
function se_quad(x, y)
function sw_quad(x, y)
function map_center(x, y)

---

You could use those functions to locate events at places on the map, then program some actions accordingly. For example, if objectives are captured in the northeast map quadrant, hence your scenario script calls the ne_quad() function, you might hand out extra event points to the capturing side, or release all fixed units in that quadrant, or reposition some reinforcements (such as Jason's nifty idea of guerillas springing up in that corner of the map), and so on.

These five map location functions are just suggestions. It will be interesting to see what other creative ideas, and functions, that scenario designers/modders cook up.

So, Jason and Petri & co., as you write your <scenario>.lua scripts, make good use (or not) of this new user.lua feature. After a time, we might all agree to elevate the best, most widely used and useful creations to the "official" init.lua file.

Have fun with this.

quote:

ORIGINAL: berto

quote:

ORIGINAL: Big Ivan

I'm starved for another sneak peak, oh please, oh pretty please with sugar on it!!![sm=happy0065.gif]

We aim to please. Here's another one:

quote:

ORIGINAL: berto

Here's another cool new feature in today's release: user.lua.

When the game engine launches, one of the first things it does is to fire up the Lua EE engine. One of the first things in that start-up is to load and process the init.lua file -- this to set the stage, define some general variables and some but not all of the available Lua functions. (Many of the Lua functions are defined not in init.lua, rather in the C++ code.)

In the process of writing Lua code in the various <scenario>.lua files, what if the scenario designer finds himself writing the same code over and over? What if he gets the idea to write some new generalized functions? That he would want to use widely, again and again, across many different <scenario>.lua scripts. That's potentially a lot of needless repetition. More work, harder to keep things in sync across the many <scenario>.lua scripts, potentially more bugs.

This is where user.lua comes into play. user.lua is a new file in the top-level game folder. It is entirely optional. If absent, the game engine Lua EE start-up sequence won't complain. But if present, it will be processed much like init.lua. (init.lua is loaded up and processed first, then user.lua immediately following.)

Ordinarily, you should leave init.lua untouched. You may reference functions etc. therein, but you the user/designer/modder should otherwise leave it entirely alone. For now, init.lua is my baby. (And we will take steps to "encrypt" it, removing all possibility of user meddling.) You may however create a user.lua file and stuff it with things as you please.

In today's release, I have an example user.lua file:

[image]local://upfiles/5869/5DA17E53413541079CEDFDF56BE23706.jpg[/image]

Which defines five map-location functions:

---

function nw_quad(x, y)
function ne_quad(x, y)
function se_quad(x, y)
function sw_quad(x, y)
function map_center(x, y)

---

You could use those functions to locate events at places on the map, then program some actions accordingly. For example, if objectives are captured in the northeast map quadrant, hence your scenario script calls the ne_quad() function, you might hand out extra event points to the capturing side, or release all fixed units in that quadrant, or reposition some reinforcements (such as Jason's nifty idea of guerillas springing up in that corner of the map), and so on.

These five map location functions are just suggestions. It will be interesting to see what other creative ideas, and functions, that scenario designers/modders cook up.

So, Jason and Petri & co., as you write your <scenario>.lua scripts, make good use (or not) of this new user.lua feature. After a time, we might all agree to elevate the best, most widely used and useful creations to the "official" init.lua file.

Have fun with this.