Sneak Peeks, Coming Attractions, Works-In-Progress

[Big Ivan]

I'm starved for another sneak peak, oh please, oh pretty please with sugar on it!!!

[fritzfarlig]

before christmas I write about atgm vs pillbox
here are something I want show

[fritzfarlig]

here no problem to attack the pillbox

[Crossroads]

Thanks for reporting this, Fritzfarligt! So the same issue, right: ATGM units can attack Pillboxes only when within Soft Attack range as well (should be determined by Hard Attack range alone).

This has been fixed and is to be available as in the coming CS:ME 2.0 [:)]

[fritzfarlig]

in update 2.0 is it not possible to create pootonbridge units like panzer general

[berto]

ORIGINAL: Big Ivan

I'm starved for another sneak peak, oh please, oh pretty please with sugar on it!!!

We aim to please. Here's another one:

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:



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.

[Big Ivan]

ORIGINAL: berto

ORIGINAL: Big Ivan

I'm starved for another sneak peak, oh please, oh pretty please with sugar on it!!!

We aim to please. Here's another one:

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:



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.

Thanks berto, this is real cool!

Just thinking about it the possibilities appear endless. Based on a quadrant alone one could mod just about anything
like Jason's idea of guerillas springing up in that corner of the map or perhaps the vanguard of an enemy armored brigade/division
arriving when least expected. I can just imagine playing as the IDF and having the Syrians on the ropes when suddenly
a whole butt load of Syrian tanks arrive and my beleaguered shot up battalion or so has to try and hold them off. Cool stuff indeed!![&o]

[berto]

A new category of victory point, Event Points:

[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

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

[fritzfarlig]

I hope [:)] I have done one big scenario and almost finish the next
right now I testplaying against a opponent
I will be really sad to see a wasted job

[berto]

Certainly not wasted. In the worst case, you would send the scenario to us, then we would convert it for you (likely using our conversion utility program). But hopefully CSME 2.0 will have perfect backward compatibility, so loading up and running older, unconverted scenarios would be no problem. Hopefully.

[fritzfarlig]

what time come update 2.0 ?

[berto]

Likely sometime this autumn.

[berto]

[:)]

[berto]

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.

[berto]

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

---

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)
average_morale (side)
counter_airlevel (trackid)
counter_assault (trackid)
counter_defend (trackid)
counter_flags (trackid)
counter_hq (trackid)
counter_isairborne (trackid)
counter_ishq (trackid)
counter_isleader (trackid)
counter_leader (trackid)
counter_morale (trackid)
counter_name (trackid)
counter_nation (trackid)
counter_oid (trackid)
counter_orgname (trackid)
counter_pid (trackid)
counter_points (trackid)
counter_side (trackid)
counter_strength (trackid)
counter_type (trackid)
counter_x (trackid)
counter_y (trackid)
current_side ()
current_turn ()
current_visibility ()
event_points (side)
fow (side)
has_flag (flags, flag)
hexcoor (x, y)
inc_adaptive_ai (side, nation, index, increment)
inc_advantage (increment)
inc_aggressiveness (side, increment)
inc_air_support (side, increment)
inc_ammo_level (side, increment)
inc_arty_ammo_level (side, increment)
inc_event_points (side, increment)
inc_reinforcement_prob (id, increment)
inc_release_prob (id, increment)
inc_smoke_ammo (side, increment)
inc_star_shells (side, increment)
isai (side)
isdisrupted (trackid)
isfixed (trackid)
isfow (side)
isisolated (trackid)
islowonammo (trackid)
isnight ()
map_height ()
map_side (x, y)
map_trackid (x, y, number)
map_trackid_count (x, y)
map_width ()
major_defeat ()
major_victory ()
max_ai_index ()
message (title, string)
minor_defeat ()
minor_victory ()
night (turn)
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_flags (id)
reinforcement_hexcoor (id)
reinforcement_prob (id)
reinforcement_scatter (id)
reinforcement_turn (id)
reinforcement_x (id)
reinforcement_y (id)
release_prob (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, flags, scatter)
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)
set_release_prob (id, prob)
set_release_turn (id, turn)
set_smoke_ammo (side, value)
set_star_shells (side, value)
set_victory (majordefeat, minordefeat, minorvictory, majorvictory)
smoke_ammo (side)
star_shells (side)
total_strength (side)
x (hexcoor)
y (hexcoor)

---

[berto]

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

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.

There should be no problem with this. I loaded one of the CSME 1.02 Ode to Divided Ground scenarios into the latest game engine. No problem. I also loaded that scenario into the latest scenario editor, and resaved it. Again, no problem. It converted just fine.

By diffing the before and after versions (before and after conversion), I can see where the differences are easily accounted for. As a fallback, a Plan B scenario conversion utility program should be easy to implement.

All in all, I wouldn't worry too much about this. CSME 2.0 backward compatibility should be fine.

[fritzfarlig]

Sound very good Berta looking very much forward to this update

[Rosseau]

Improving the Campaign Series is not easy to begin with. But concentrating on the AI and scripting is a bullseye, imo.
I hope TOAW IV is as successful.