Global Campaign

[danzig70]

I am trying to figure out the problem of getting a unit's HP and setting a unit's ammo. In the 2nd tutorial mission I noticed that the HP, primary ammo, secondary ammo and experience fields are highlighted as part of the objectives so I looked at the script for that mission. There seems to be a AskClient() function that isn't including the the map editor list of functions nor Calvin's guide:

-- about hit points
function Objective5()
AskClient("HighlightIndicator(10)");
ChangeSelection(1000,0);
ChangeSelection(1001,0);
if (GetIGlobalVar("Mission.Current.ObjectiveShown",0) == 0) then
ObjectiveChanged(5, 1);
RunScript( "RevealObj6", 2000);
RunScript( "Objective6", 4000);
Suicide();
end;
end;

It seems that morale was phased out for experience, which is why perhaps morale functions don't do anything. If a unit is selected, ChangeSelection(ScriptID) will unselect it.

-- about morale - old, EXP now
function Objective8()
AskClient("HighlightIndicator(13)");
ChangeSelection(1000,0);
ChangeSelection(1001,0);
if (GetIGlobalVar("Mission.Current.ObjectiveShown",0) == 0) then
ObjectiveChanged(8, 1);
RunScript("Reinf30", 1000);
RunScript( "RevealObj9", 2000);
RunScript( "Objective9", 3000);
Suicide();
end;
end;

You can highlight other buttons such as attack, ambush etc:
-- destroy pillbox
function Objective19()
-- if (GetNUnitsInScriptGroup(200) <= 0) then
AskClient("HighlightControl(20002)");
if ( GetNUnitsInScriptGroup(200) <= 0) then
ObjectiveChanged(19, 1);
RunScript( "RevealObj20", 2000);
RunScript( "Objective20", 3000);
Suicide();
end;
end;

But you can also use the AskClient() function to move the camera:
-- group assignment
function Objective21()
if (GetNUnitsInArea(0, "Area2") >=1) then
ObjectiveChanged(21, 1);
RunScript("Reinf70", 1000);
RunScript( "RevealObj22", 2000);
RunScript( "Objective22", 3000);
ViewZone("View1", 1);
AskClient("SetCamera(1520,3707)");
Suicide();
end;
end;


Anyways, I am not sure how this helps yet, but if it does I'll let you all know.

EDIT: After looking around, I guess the AskClient is already well known

[Folgore]

Well, I don't remeber if we discussed this thing already but HP and ammo values are stored in .sav files. The fact is that I don't know how to extract them...

[danzig70]

Yes, Folgore that's why I was excited at finding out the names of the HP and ammo bars. I found a method for reading a binary file in c# and maybe looking for unit information. I also thought about looking at the supply trucks and repair vehicles to see what exactly they do. They "know" the HP and ammo values for units in their vicinity. That would be good for the health as you can use the damage object command but the ammo would still be a problem.

I also thought of asking Aleks if Nival gave him a development kit when he created Kosovo Sunrise. Perhaps there are additional AskClient() commands or lua commands that would be helpful. Maybe something like AskClient("GetValueIndicator(10)")... doesn't work by the way

To be honest, it all gives me a headache. I am at a comfortable point in my strategic map and heights tool development that I just want to create buildings for my maps and then start scripting AI behavior. Maybe it all doesn't matter anyway, if a unit is always in good health and full ammo when starting a new map.

[Major Pain]

Great Idea SJ...

Sorry Dan... I overlooked your recent progress due to my computer issues lately.   Extracting the data within C+ seems logical.    I have seen a couple of examples previously of part of what you posted.

Since the Lua software runs perfectly well within C+ for subroutines, I'm pretty sure we could define the KEYWORDS or Functions to carry over the data.   We would need to find the KEYWORD list with the C+ Host, then modify it.

One thing I learned about the LUA language is not every defined KEYWORD or FUNCTION is discussed in Calvins.   I've found numerous things in original mission files that were never covered.   Calvin did discuss arrays in the very end of his Tutorial.   He demonstrated a 3 dimensional arrays applied to a mission where the enemy reacts to attacks and sends reinforcements.   You might take a look at the example just for the educational value.   You will also spot a couple of basic routine function calls.

Once I get my system back online, I'll pull out some stuff that may be useful. 

[Folgore]

Jul 29, 2013 17:56:14 GMT 1 Squire James said:

Jul 29, 2013 10:57:31 GMT 1 Folgore said:

Well, I don't remeber if we discussed this thing already but HP and ammo values are stored in .sav files. The fact is that I don't know how to extract them...

I've had an idea.

I have a program that can compare two files and show you the exact differences between them.

So, we make a simple 1x1 map, with a single Sherman (for example) on it. First, you run the map from the editor and immediately save. Then, load the map again in the editor, change the HP of the Sherman, run the map again then save to a different file. The only thing that should be different between the two files is the HP of the Sherman

Something like this below?
www.mediafire.com/folder/hlhdsuxailxei/Philadelphia_Experiment

[danzig70]

Hi Folgore,

I had the sm1.sav already but I downloaded the other two and the .pak. I looked at the sm1 in a hex editor and found only two instances of healthbar. A tooltip (maybe for the layout of the interface) and another one (2nd line):



This may be due to the fact that one unit was selected when the game was paused. I remember looking for the ammo1bar when we were looking at this in the past. I don't know why there isn't an "h" and I dont know this stuff well enough to be of much help Im afraid. Theres a character chart here that may be helpful: link

Example, the character before the "e" in ealthbar is hexi 12, or DC2, or Device Control 2 now used for software flow control - wikipedia

See what I mean by headache?

MP:

Do you mean having something run in the background while BK is running to find which keywords are being passed? Sorry for my ignorance. I thought that maybe the lua commands would be in streamio.dll or something but didn't find one that looked like it would be for lua commands.

[Folgore]

Hello Dan,
I see what you mean.
In order to make a good test of the SJ's idea we should set a complex "protocol" for a simple map.
I could suggest:
1) Map dimension 2x2;
2) Plain terrain;
3) No Start commands
4) Just two units well known in all their features (Sherman and PZIV?)
5) Save before starting with no units selected;
6) Save before starting with Sherman selected;
7) Save before starting with PZIV selected;
8) Save before starting with both units selected (it's possible?);
9) Make comparison for finding differences if any;
10)Sherman fires one shot; Save
11)Sherman fires two shots; Save
12)Sherman fires three shots; Save
13)Make comparison for finding differences (there should be any...)
For a more complete test, repeat 10), 11), 12) and 13 shifting Player0 to PZIV


Will I do all the above?

Hmmm...

[danzig70]

Hey Folgore, Ive been sick for the past week but will try and make a couple of test files. Maybe not as indepth as all of those but something for SJ to compare.

[Major Pain]

I think we can run a C+ or C program in the background to capture some data.   We'd have to detect data passage and then try to identify it.  Once we know how it is passed, and have identified what we want, the data could be extracted.  Then the next step is to figure out how to pass it back to the handlers in the format we want.

If we can extract the specific data, then the main issue will be writing it in LUA for use within the script.   From what I have been reading about LUA 4.0, we should be able to get to the C layer to re-write the keyword codes.   If we are successful at that level, then reading and writing in LUA can handle all of the data handling.

I know you have a lot on your plate Dan, but here is the LUA 4.0 Guide:  www.lua.org/ftp/refman-4.0.pdf

If you have NetFrame 4.0 and Microsoft's SDK, you should have assess to some C & C+ code for review.   Since LUA runs inside a host, usually C, it can share the same direct link libraries and keywords.  The original Developers at NIVAL I'm sure chose LUA mostly due to its flexibility, and it's ability to compliment C.   Most of the BK game engine is written in C, but I have found some straight machine code embedded within as well.   The Machine Code handles most of the core database system and binary functions.   This is where some of the data we will need to retrieve will reside.    But we should be able to pull it out with LUA during call functions.

For those of your that ever worked with GW BASIC, you will find some familiar ground in LUA and C.   Much of what we refer to as sub-routines are common stuff for LUA and C, which we call functions and sometimes formulas.  At any rate, a line(s) of execution code in LUA is referred to as a chunk.

Excerpt from LUA 4.0:

All statements in Lua are executed in a global environment.  This environment is initialized with a call from the embedding program to lua.open and persists until a call to lua.close, or the end of the embedding program.  

This is exactly how BK calls the LUA script into the game.

The global environment can be manipulated by LUA code or by the embedding program, which can read or write global variables using API functions from the library that implements LUA.

In BK, the Script 'Library' resides with the game Direct Link Libraries.

We know the the game engine maintains the Health Bar and Ammo Storage.   By defining and indexing the data we wish to pass, the main chore will be defining that specific data within LUA by expanding the Library.   This brings up the question of what can we do with the .dll codes.   Can we go in and change the original source code.   I think not.   That would much the same as chaning the game engine code.   But since the intent of BK from the beginning was 'open source'.... I think we could manipulate that code and replace some of it with a patch after the load is complete.   Think of it as changing a skin on a tank.   We're just redefining, or in this case, adding to the code.  I think all of this could be handled within a LUA PATCH, which could be released as part of the completed project.

When I get my system back up and running, I'll go back into the game code and try to identify the stuff we need to focus on.   I mostly need to find the embedded code that calls LUA, so we can see how we redefine the library.



I might add....   this code handles some of the same Command Functions in the 1.xml files.   So if we are going to test the water on this, we may as well see if we can patch the 1.xml codes.   This is where the binary codes reside that define which Commands are established to control the 3D models; i.e. tow points, riders, entrench, etc...   Some of the code is HARD CODED within the game engine.   The .dll files add modules to the game engine which change some of that code.   So in my mind, I think it is more a matter of creating .dll files that would simply load after the primary files.   We may have to boot-strap those files outside of the game engine.   Lua seems to be the most probable method since it is called naturally inside the game engine.   There is no change to the core or base engine files.  The patch is called, which changes some of the original functions.  

This is not much different than the different ailogic.dll files that are already in wide circulation.  Which brings up another possibility.  For those that enjoy the TDA BK versions, you'll notice a little addition in the unit 1.xml code... FUEL.   That was added using that method.   The game engine was not changed, rather just an expansion to the game database with the addition of another variable.   That is basically what we are talking about here, but the data is handled outside of the 1.xml but stored in the same database.  The database already contains the fields, we just have to get to it.

We know the database stores the model, its HP, Speed, Sight, etc...   it also stores its Weapon data, like Ammo (full) and Ammo Current.   It also stores the 'HP current' data.  We know this because we can see the Health Bar change with damage.

Food for thought for some of you Computer Students out there...

MP
 

[danzig70]

Yep, I have the 4.0 manual and the tar ball. I unzipped it but haven't compiled it or done anything with it or tried using it with visual c++. It takes some getting used to.

So are the lua commands in streamio.dll?

[Major Pain]

I'm having to wing this a bit from memory... and previous research.

Look in the gamett.dll and ailogic.dll.   the gamett.dll handles much of the unit model functions, but also is the look-up for 1.xml data. 

Lua is used more than just the Scripts.  Also the lua.open resides in various places; game.exe for example.  

stream.dll from what I remember handled the sound card 
binkw32 handles the video during load and cut scenes (350kb)

The game engine calls in code from the .dll files to perform different parts of the game.  Check your file sizes against these.

fmod.dll handles mod loading (284kb)
gfx.dll handles the graphics (236kb)
image.dll handles the image display on startup, splash screen, cut screens (208kb)
input.dll handles the user input, like selecting menu items or options (172kb)
msvcp60.dll don't recall what it handles (393kb)
msvcrt.dll  again, small file don't recall purpose (285kb)
net.dll handles multiplayer (164kb)

scene.dll  this may handle some data transfer between scripts and game, but also handles scene cut screens (804kb). No lua.
sfx.dll  sound card (88kb)
stream.dll (above) (320kb)
ui.dll handles the player interaction (532kb)

protect.dll handles disk in tray and verifies legal disk (3794kb):::: not all releases have this file.
bugslay.dll   works with protect.dll for disk verify (84kb)::: not all releases have this

The game.exe builds the database within hard code.   This is where all object data is stored and accessed.   So far, I've not been able to get to the data directly.   I think lua can get us there inside the game.   If we create a background host, we may be able to directly read what we need, but we'll have to point directly to it... that will require reading sequentially, then looking for the 'end of record' or 'end of line' codes.  We will also need to determine what kind of separators are used; i.e. , ; : ' or <CR> so data can be defined.  I expect it will be in either Binary or Machine Code, so we may need to compile, or access the internal compiler.

Depending on the BK version, mfc42.dll uses one of four profiles.   BH handles campaigns and chapters differently than RT for example.  Kursk has yet another version.   The BH function is hard coded within the game.exe.   RTs version mfc42.dll is much larger and changes the game.exe campaign functions.

mfc42.dll does seem to handle some lua codes.   Check your size against mine 3988kb; from BK-RT.   BH is 973kb.

I can't check Anthology or Kursk at the moment on my primary System.

Worth noting:   The game.exe also has various versions.  

BH -> game.exe @ 3840kb 
RT -> game.exe @ 2038kb :::: Again...  mfc42.dll is called to insert various code which levels out the size.

When comparing game.exe and mfc42,dll you will find a small area of the same code.   I'm not sure of the purpose, yet.

What we will be looking for is the LUA definitions.   Since BK uses specific keywords to handle get, set, cmd, etc... that is where the focus will be.   LUA itself does not recognize those specific keywords... and handles those as processes from the code profiles.

The mapeditor.exe and reseditor.exe both also load .dll resources.    Neither build a database.   They just utilize source files for their specific functions.   The mapeditor uses the objects.xml for model source data, then assigns it's own sequential numbering for each object.   The reseditor access the weapons folder for data, but also builds the command functions for the 1.xml from the gamett.dll. 

I'm still not back to normal on my main system...  so I can't do any exploring yet.   On this laptop, I only have limited tools but thinking about loading my SDK and VB... I already have NET 4.0 on it for WIN7.

[Folgore]

As usual MP writes interesting stuff.
One point hit my attention: the connection between mapeditor.exe and game.exe 
We know that a map can be tested from the mapeditor clicking the small button on mapeditor. But there isn't still a .pak or a .sav file. So, if I'm not wrong, there should be somewhere a sort of cache where values of units of the tested map are stored in order to allow the game.exe to run the map.
So it could be interesting knowing what and how mapeditor.exe passes to game.exe. Maybe a dll manages the thing.

[Major Pain]

Thanks

When you run the game from the mapeditor, the object.xml is loaded and objects are placed into the database.

If you look at the BK file system, you can find a massive number of modules written in .xml and .lua that are loaded for both the game.exe and mapeditor.


Here is example of one of the .lua files that is called during the chapter or campaign loading operation:

It can be found under:

data/UI/common

The file is named: commonscript.lua

nNumberOfButtons = 0
nActiveButton = 0
bInit = 0

--the variable nNumberOfButtons is initilized from GlobalVar
--so that we do not need to write explicit LUA serialize code to save it
--when chapter or campaign screen is loading, the game serialize all GlobalVars
--and script is initializing after all global variables are loaded

function ClearState( nControl )
i = 1000
while ( i <= 1000 + nNumberOfButtons ) do
if ( i ~= nControl ) then
AddMessage( 65536, i, 0 ) --CHANGE_STATE to 0 (clear state)
end
i = i + 1
end
end

function LuaProcessMessage( nMessageCode, nFirst, nSecond )
if ( bInit == 0 ) then
nNumberOfButtons = InitCommonScript()
bInit = 1
end

i = 1000
while ( i <= 1000 + nNumberOfButtons ) do
if ( nMessageCode == 536936448 and nFirst == i ) then
if ( nSecond == 1 ) then
nActiveButton = i
ClearState( i )
return 1
end
if ( nActiveButton == i and nSecond == 0 ) then
AddMessage( 65536, i, 1 ) --SET_STATE
return 1
end
return 0
end
i = i + 1
end

return 0
end

Proof that global variables are passed from chapter to chapter or mission to mission.      



Also in that same part of the UI we can find the handling codes for the DepotUpgrades and PlayerRank.   The message here is there is a huge amount data stored within the database as the player plays along.

As the player plays a campaign or chapter, specific data is collected as to casualties (his own and enemy).  The core unit list with their rank and experience is also collected as well as the commander name.

We know that just about everything about the BK design is based on modular codes or chunks, whether it is called through a .dll or .xml or .lua file.

[danzig70]

I found a nice lesson on camera position to get an isometric view here so I continued work on my building. The lighting is still troublesome though. I am trying to use sunlight settings based on lat/long but it isn't working as well as I would like.  I think I have the size/scale about right but any comments are welcome. I still have to add windows and doors.

 

I created a plane to help with creating the shadow images:


Added the windows...what a pain in the ass!



Here is a try at the damaged state. Just playing around with filters in PS but it could be a lot better. The roof will be hardest I think.
 

Finally was able to take a look at the building in the game so I know what to fix. 


I think I'll redo the textures in 3ds max to make the bricks more visible in the game.

Here is a prototype of the destroyed state. It really is tougher than I thought.  Again, any comments welcome. I think I need to fix a wall, improve a corner and add a wall.

[danzig70]

I have a test of the Church St Remy if anyone wants to try it out. It can be downloaded here. It's my first building so comments are welcome.