Global Campaign

[Major Pain]

Oh yes.... the OODA loop... Observe, orient, decide, act


In the Fire Service we use a slightly different variant (or off-shoot) of OODA, called the PDCA Cycle (Plan Do Check Act). During my years as a smoke jumper, we used OODA, but found it difficult to utilize as intended compared to humanistic targets.

The fact that you keep your nemesis off-center by disrupting his intell, via feeding false data, while taking advantage of what he knows, and what he thinks he knows, along with what you know you are doing to him.... gives you a distinct advantage on the battlefield. Before the target understands what is true, and what is false, it is all over... The goal is to take advantage of the confusion you have caused, which makes the opponet under-react, over react, or not react. As the opponet continues to make decisions based on somewhat invalid or totally unrealiable data, you rope him into reacting rather than being proactive. If you allow true data to go through the chain, they are likely to not trust it and react accordingly... opposite of what would be prudent.

Remember the M1 Abrams crossing the bridge into Bagdad as the Iraqi Public Information Officer was giving a live televised interview stating no US Forces were close to Bagdad? They just didn't realize what was going on until their eyes (and the CNN reporters) told them.

________________________________________________

PIO: "There are no US forces anywhere close to Bagdag. All is under our control. Our army has defeated the US forces handily as they crossed into our country."

CNN Reporter: "Hey Isn't that a US Tank?"

PIO: "No, no, no... I assure you it is not..."

CNN Reporter: 'Look, crossing the bridge, that's a US Tank! There's another... and another... and...."

PIO: "No, no, I assure you that we captured a few US tanks. Those are the ones..."

CNN Reporter: "Isn't that Chuck Norris on the turret?"

PIO: "I have to go boys... I'm late for... dinner..."

___________________________________________________

In our variant of OODA, PDCA, we base our operational goals on known or unknown factors. Much of what we do is based upon situational awareness and outcomes based on prior knowledge, skill and abilities (KSAs).

We know how a structure fire goes through evolutions and cycles; Unless we disrupt the cycle (chemical chain reaction), we know the outcome is total destruction. The unknown factor is the fuel loading; how much combustible product (Furniture, wood, paper, etc...) is in the container (the house). Other factors that we cannot know are things like combustible fluids or solids used for various household uses; alcohol based cleaners, aerosol cans, fuel storage for heating, powdered grains or meal, cooking oils & grease, etc... Think about what is typically in your house, and consider whether it can flash, explode or gas off and create toxic fumes.

So we PLAN: Establish the operational goals in accordance with an expected outcome. This plan is usually based on our KSAs, or what we have experienced before.

Then we DO: The Plan is initiated; we put into motion a series of tactical level functions. We also observe and collect data for ongoing analysis.

Then we CHECK: Are the tactics within the scope of the operational plan having the desired effect. Are we reaching the operational goals of the plan and is the data collected reflective of the actual effect.

Then we ACT: Do we need to modify our tactics or stay the course? This is where we make corrective adjustments to the tactics as we continue to move through the cycle.

The cycle repeats until operational goals are accomplished or circumstances go beyond the scope of the original plan.

Anyway, you are quite correct, sometimes it is a lot more fun to play with the PDCA Cycle and tactical theory behind various events.

We use table-top situational trainings and simulators to train our officers. This is where they will learn the tactical level of the operation. Nothing like making these guys sweat... just makes my day.

This is not the same as being one of the guys carrying out the actual tactics. PDCA is where you better know how the individual tactics on various levels interface or inter-connect as they are applied. One wrong move and you can lose some people.

I'm sure we all have seen Ladder 49 and Backdraft. Ok, those are Hollywood action films. In a real backdraft, we must be able to read the signs from observation, not from exploration. The level of tactical agressiveness is much different as the situation changes, and a Backdraft is at the top of the food chain. We do not risk lives if there are no lives to save. Meaning: we won't insert rescue teams into a structure if it is known there is no one inside to rescue, or conditions exist that are not condusive for survival, (ours or yours).

If the situation presented is a densely smoke-filled container with ambient temperatures around 1200 degrees F, you're already dead if you are inside. Our operational plan is based on what we know about this event. Tactics will be: ventilate the container vertically, begin suppression as close to the base of the fire without disrupting the thermal layering. We don't want it to go boom. The immediate goal is to reverse the temperature rise by allowing the hot gases to escape through our vent, thus allowing a cool-down.


Ok... enough about that...

It's those little scripting syntax errors that will drive you crazy....

MissionFinished() works for me... sounds right... it clearly describes what I want it to do.... damn computer.

Sorry for bummin your topic... I'll shut up and sit over here for a while...

[redvlastelin]

danzig70, how can I help you? I would like to help, but i have no knowledge in this.

[danzig70]

red, dont worry about helping. I am just playing with ideas most of the time.

Very interesting MP. We have alot of respect for fire fighters here in Arizona, urban and wild fire.

Well now the pressure is on for me to make some kick-ass scripts.

[redvlastelin]

danzig70, ok. I wanted to help you. It's a brilliant idea! Arizona is in the USA?! About fires don't worry. In Russia, too, a lot of troubles - fools, roads and money. ;D Go ahead! I think you can...

[danzig70]

Hi red, you guys had some pretty bad wild fires too if I remember correctly. The community always needs more chapters if you want to make one. Then maybe we can gather all the community chapters and campaigns and put them on the globe. Now that would be a global campaign! If you have an area of interest, like a city or location, I can make blank bkmaps with the elevations added. Additionally, I have some German army maps of Moscow but if you can find some topographic maps of the USSR that would be a great help. Some countries use wms mapservers to access geographic data. Are you familiar with this? If so, if you can share websites that may have this data that would be very helpful. Like this one: www.gisa.ru/

MP, are the Lua features and functions limited to what is implented in the game engine? I seem to recall having problems using IO functions in map scripts.

[Major Pain]

Dan

I'm still looking for my source files and test maps.

Lua keywords, functions, etc. can be added, but must be declared. I can't remember which .dll you have to add, which is where they load from.

I will try to look back at the .dll files and list out which have already been declared.

Because Lua is so robust, you can actually add some of your own keywords, but care must be exercised since certain words might be entered into script for another purpose and cause issues.

You know how that goes when you're dealing with syntax.

BK uses Lua 4.0, so the latest version won't directly work since it has been expanded. Reference lua 4.0 and you can see what has been added or updated.

The neat thing about this is Lua plugs into C+ routines seamlessly. So using the onboard MS menus and Editors within BK (all in C+) you can overlay code where you want it.

Do you have the MS SDK? (Software Developer Kit)

It can be downloaded from MS. I think 16 bit requires NET 4.0, but will also run 32 bit. That can most likely give you a head start in the C+ language, along with JAVA Script. I haven't tried to cross utilize Lua and Java, but I would think it would not be an issue. At the FD we use JAVA and C+ on much of our software. Along with NET for our Server Software.

[kaoz]

Feb 23, 2012 3:32:52 GMT 1 danzig70 said:

Problem1: I need to track a script unit's health. I thought there was a command for this but it isnt in the map editor help file. So, if your tank is damaged and out of ammo, the unit enters the next map in the same condition.

i hoped GetObjectHPs(iScriptID_Static) could help you, but it doesn't seem to apply to units. GetUnitMorale(iScriptID) and GetUnitState(iScriptID) won't do either, i guess. Not easy to solve i believe.

[danzig70]

Hey kaoz! I was going to use the DamageObject command when they land as reinforcements but you're right, I have no way to know what health they were in. I may have been thinking of Sudden Strike.

MP: That's very interesting. I didnt know that you could add dlls. I have just been writing console programs so I havent used the windows sdk yet. I should be able to compile dlls in Visual Studio Expres 2010. Lua also has very interesting "rocks" such as CGILua and lpdf for creating pdfs. Sounds like a recipe for dynamic Mission Sheets that could be downloaded to accompany a chapter.

[Major Pain]

GetNAmmo(iScriptID) = ammo level for primary and secondary

GetObjectHPs(iScriptID_Static) only works on buildings (note static)

GetNUnitsInScriptGroup(iScriptID [, iPlayer]) = helpful to determine number of Script Units. best used when tanksm trucks & infantry have specific Script ID#.

Example:

Tanks = Script ID# 4000
Turcks = Script ID# 4010
Infantry = Script ID# 4050

If different tanks are used, but you need to determine how many of each, it is best to further break ID# out.

4000, 4001, 4002, etc...

Those values can be carried between maps. using the Land Reinforcement command, you can land the exact same number back to new map, by using a loop. Tx = number of tanks. Land tanks [ Loop TX ] You must plan for enough room with this method.

____________________________________________________

LUA UPDATE:


Quick Search shows...

Handles all variables as Global unless expressly declared Local

All variables = 0 at init

Section 3 in above link covers variables:

There are six basic variable 'types' in Lua: nil, number, string, function, userdata, and table.

Lexical Conventions (Reserved ~Keywords) - Section 4

and, break, do, else, elseif, end, for, function, if, in, local, nil, not, or, repeat, return, then, until, while

Handles Literal Strings uses brackets & double brackets -> [[ ]]

Will handle strings to numbers conversion, and numbers to strings conversion.

Handles declarations of strings, functions, statements. Adaptable to C or pacal statement declarations for tables and arrays.

Blocks and Chunks are one in the same. Can be delimited.

Handles multiple assignments: variables and expressions in single statements.

Handles Control Structures: If, while, repeat

stat ::= while exp1 do block end

stat ::= repeat block until exp1

stat ::= if exp1 then block {elseif exp1 then block} [else block] end

Supports For Statements : Either numbers and /or tables

Supports Function Calls

Supports all Arithmetic, Relational and Logical Operators


Supports Concatenation

Supports function strings$ names

function (AA$)


Supports Passing locals to globals and reverse.

Supports enclosed locals

Supports Tags

example:

function getglobal (varname)
-- access the table of globals
local value = rawget(globals(), varname)
local tm = gettagmethod(tag(value), "getglobal")
if not tm then
return value
else
return tm(varname, value)
end
end


Supports STACK/IDICES operations: Manipulation / Querry / Pushing / Garbage Collection

USes C Code for Host Interface:: function support/ declarations

Supports Defining C Functions and Reference C Functions

Full Library Supported

Supports Strings Manipulation / Patterns

Supports (all) Mathmatical Functions

Supports I/O

I/O Facilities
All input and output operations in Lua are done, by default, over two file handles, one for reading and one for writing. These handles are stored in two Lua global variables, called _INPUT and _OUTPUT. The global variables _STDIN, _STDOUT, and _STDERR are initialized with file descriptors for stdin, stdout, and stderr. Initially, _INPUT=_STDIN and _OUTPUT=_STDOUT.

A file handle is a userdata containing the file stream (FILE*), and with a distinctive tag created by the I/O library.

Unless otherwise stated, all I/O functions return nil on failure and some value different from nil on success.


openfile (filename, mode)
This function opens a file, in the mode specified in the string mode. It returns a new file handle, or, in case of errors, nil plus a string describing the error. This function does not modify either _INPUT or _OUTPUT.

The mode string can be any of the following:

``r'' read mode;
``w'' write mode;
``a'' append mode;
``r+'' update mode, all previous data is preserved;
``w+'' update mode, all previous data is erased;
``a+'' append update mode, previous data is preserved, writing is only allowed at the end of file.
The mode string may also have a b at the end, which is needed in some systems to open the file in binary mode. This string is exactlty what is used in the standard C function fopen.

closefile (handle)
This function closes the given file. It does not modify either _INPUT or _OUTPUT.


readfrom (filename)
This function may be called in two ways. When called with a file name, it opens the named file, sets its handle as the value of _INPUT, and returns this value. It does not close the current input file. When called without parameters, it closes the _INPUT file, and restores stdin as the value of _INPUT. If this function fails, it returns nil, plus a string describing the error.

If filename starts with a |, then a piped input is opened, via function popen. Not all systems implement pipes. Moreover, the number of files that can be open at the same time is usually limited and depends on the system.


writeto (filename)
This function may be called in two ways. When called with a file name, it opens the named file, sets its handle as the value of _OUTPUT, and returns this value. It does not close the current output file. Note that, if the file already exists, then it will be completely erased with this operation. When called without parameters, this function closes the _OUTPUT file, and restores stdout as the value of _OUTPUT. If this function fails, it returns nil, plus a string describing the error.

If filename starts with a |, then a piped input is opened, via function popen. Not all systems implement pipes. Moreover, the number of files that can be open at the same time is usually limited and depends on the system.


appendto (filename)
Opens a file named filename and sets it as the value of _OUTPUT. Unlike the writeto operation, this function does not erase any previous contents of the file; instead, anything written to the file is appended to its end. If this function fails, it returns nil, plus a string describing the error.


remove (filename)
Deletes the file with the given name. If this function fails, it returns nil, plus a string describing the error.


rename (name1, name2)
Renames file named name1 to name2. If this function fails, it returns nil, plus a string describing the error.


flush ([filehandle])
Saves any written data to the given file. If filehandle is not specified, then flush flushes all open files. If this function fails, it returns nil, plus a string describing the error.


seek (filehandle [, whence] [, offset])
Sets and gets the file position, measured in bytes from the beginning of the file, to the position given by offset plus a base specified by the string whence, as follows:

``set'' base is position 0 (beginning of the file);
``cur'' base is current position;
``end'' base is end of file;

In case of success, function seek returns the final file position, measured in bytes from the beginning of the file. If the call fails, it returns nil, plus a string describing the error.
The default value for whence is "cur", and for offset is 0. Therefore, the call seek(file) returns the current file position, without changing it; the call seek(file, "set") sets the position to the beginning of the file (and returns 0); and the call seek(file, "end") sets the position to the end of the file, and returns its size.


tmpname ()
Returns a string with a file name that can safely be used for a temporary file. The file must be explicitly opened before its use and removed when no longer needed.


read ([filehandle,] format1, ...)
Reads file _INPUT, or filehandle if this argument is given, according to the given formats, which specify what to read. For each format, the function returns a string (or a number) with the characters read, or nil if it cannot read data with the specified format. When called without formats, it uses a default format that reads the next line (see below).

The available formats are

``*n'' reads a number; this is the only format that returns a number instead of a string.
``*l'' reads the next line (skipping the end of line), or nil on end of file. This is the default format.
``*a'' reads the whole file, starting at the current position. On end of file, it returns the empty string.
``*w'' reads the next word (maximal sequence of non--white-space characters), skipping spaces if necessary, or nil on end of file.

number
reads a string with up to that number of characters, or nil on end of file.

write ([filehandle, ] value1, ...)
Writes the value of each of its arguments to file _OUTPUT, or to filehandle if this argument is given. The arguments must be strings or numbers. To write other values, use tostring or format before write. If this function fails, it returns nil, plus a string describing the error.

Supports DEBUG / CPU / HOOKS

[Major Pain]

One another note...

Some trail was preformed by someone years ago that placed units into containers for preloading into random maps.

I haven't tried this , but it seemed to have some value and merit.

Here is my thinking. Once you quantify what units you have that will move to the next amp, you build a container for them. This would use the /output/ function.

When the next map is loading, the /input/ puts the container on the map. What I don't know is if the ammo and HP would also be saved into the container.

This is also key for maps that might be traveled through several times.

You need a series of flags or keys to load containers for defensive positons, as well for counterattacking or hunter-killer units. Ohterwise, every time you enter a map, you would find the same objective and defensive units.... even if you had already dfeated them.

So there are many things on several layers that have yet to be solved.

If this issues are overcome, you end up with a very fluid mapping system which literally changes as the larger battle progresses.

Think of the maze or search games.... you go around finding stuff passing through the same locations or rooms several times. Each time you pass through, it is just like you left it the previous time.

EDIT: Original tests saved & loaded for each map as passed. The issue here was players units remained in previous location as when exited. So units must be stripped off after "save container" for reload.


*** It looks like enough of LUA 4.5 is in BK to avoid much added content through .dll. The i/o issue requires exact sytax & strings names.

[Major Pain]

In a Campaign, core data is stored for the Combat Screen. This is done by storing and updating several global and local variables that are passed between maps.


Refer to: Lua File found below.

data/scenarios/scripts/player_skills_recalc.lua

Using this exact form, you could attach whatever data you wish to define.

Number of Player units by Script ID
Number of AI units by Script ID
etc...

[Folgore]

I know I'm talking to big bosses here, but couldn't be an idea exploiting the fact that values like HP and ammo are stored in .sav files?
After all when you load a sav file you start exactly where you left.
Sorry if this is b****hit... ;D

[danzig70]

That's alot to go through, I will delve into it tonite. The documentation for 5.1 is online at www.lua.org/manual/5.1/. This should be an interesting weekend.

I think I may get a web host so I can host files for the java edition of WorldWind. I need to do it for work anyway. Here is a page with examples goworldwind.org/demos/. There is nothing to install with this version except java which makes it nice.

[danzig70]

Feb 24, 2012 23:25:13 GMT 1 Folgore said:

I know I'm talking to big bosses here, but couldn't be an idea exploiting the fact that values like HP and ammo are stored in .sav files?
After all when you load a sav file you start exactly where you left.
Sorry if this is b****hit... ;D

You will always be the boss Folgore! I was thinking of finding a way to save the map when the unit exits and then loading the save game when you return. I will look into it.

[Ocelo]

Man... just to debug that script...

Probably one reason the developers never took the LUA very far with the game is that the amount of testing that would be required would outweigh the costs of a new engine (ie: the BK2 one).

But anyways, that sounds very interesting; manipulating the ammo values at startup in units would be really great to say the least. Best of luck!