Global Campaign

[danzig70]

Hi Ocelo, I am going to try a simple chapter first. I have never made one so I need to do that. It will have off-map artillery that won't be available if that position is captured. Tactical air support if within range of airfields. Folgore has a good point, the only way to really return to a map, in the condition it was last in, is through the save game. If I could point the chapter script to saarmission.sav instead of instead of the .xml or .bzm in the maps folder, it might be a "fix". If MP can tell me how to add Lua commands through a .dll, maybe we can create a GetNScriptGroupHealth() command or something.

I have BKBK which only has a german campaign. Rolling Thunder should have a allied campaign? Can someone send the scenarios folder for an allied campaign that isnt USSR or German? I can see my French campaign in the selection but it seems to error and then load the default German campaign.

So, the demo will just be the ability to click an icon on a globe to start a chapter. The link will open the necessary mod or data directory needed to play that map. To that end, www.danreavey.net is supposed to be on-line within 48 hours. If anyone needs an environmental assessment or an indoor air quality assessment done, let me know also

Yeah, so I just had an idea. If the hyperlinks on the globe can be set to a saved game, then the player can just save the game with a particular name for that map. If the player starts a chapter at the divisional headquarters then they choose proceed to the chapter and advance to their first map. The player has the globe or the chapter menu screen to decide which map they want to start with to choose between armored core units, artillery core units, infantry core units (possible?), etc. If the chapter script can have additional functions to track the core units, then the player can just save each map according to a naming convention. When they want to enter a map they click the icon and that saved game loads. I need to try out functions using IsPlayerPresent so that it updates the chapter script. It requires some manual intervention but with the Blitzkrieg Start Tools its very easy to learn how to customize shortcuts. If each mission/map is clearly named, it shouldnt be difficult to remember what to name the saved game.

For the armygroup or army icons I think it will link to an html page where you can view text, back story, a summary of the available chapters, and be able to download any mods necessary. It also might be an alternative to game spy for arranging Multi-player matches.

If anybody wants to help test it, the NASA WorldWind (.NET) program needs to be installed worldwind.arc.nasa.gov/index.html and then I can give you the files for the Add-on. If someone has a chapter they want to donate that would save ALOT of time. Then, perhaps as a community, come up with a chapter script to exploit the ability to track which map the unit is on.

Just as a salesman I add that I have near-realtime weather and other layers from my earlier post that adds to the immersion. The comparison of Warsaw in 1935 and 1945 is compelling. Perhaps Fall Weiss could donate a chapter of Warsaw to test?

[Major Pain]

Dan

I'm working on a chapter that will test the limits of the data handling.

The Script units will be put into a table and stored in an 3-D array on INIT.

The first goal is to pass the script id# and associated data from one map to another. If the next map does not need to reload the Script Array, but it can access and run back the data, then we have the basis for handling all of the data.

Using the array simplifies the data handling. Here is how it will work.

Think of three streets with houses. Each house has a mailbox in front. Inside each mailbox there are letters, cards and magazines.

In our example, we'll name the streets
Player (Street)
AI (Street)
Neuter (Street)

Now well name the addresses: For this, we'll use numbers:
0, 1, 2, 3, etc. for the Player Street Addresses.
0, 1, 2, 3, etc for the AI Street addresses.
0, 1, 2, 3, etc for the Neuter Street addresses.


Now lets identify the mail in each box:
Status News,
Typing Today,
Ammo Reloader,
Health Today,
etc....

Do you see the pattern?

Human is Player 0: Player Street
AI is Player 1: AI Street
Nueter is Player 2: Nueter Street




Each Street has addresses starting at 0. This would represent each script ID#, except we would add a multiplier to make each address unique in the game. This would be the (player # + 1) x (Address# X 1000) :

Examples:

[(Address#) 5 + 1000] + [(Player#) 0 * 1000 = (Script ID#) 1005
[(Address#) 3 + 1000] + [(Player#) 1 * 1000 = (Script ID# ) 2003
[(Address#) 10 + 1000] + [(Player#) 2 * 1000 = (Script ID# ) 3010



Each mailbox holds mail, which in this case is data; unit data

We can assign any number of data positions we want to use:

Position / Description
....0....= Unit Status [ -1 = Dead / 0 = Damaged / 1 = OK ]
....1....= Unit Type [ 0 = Inf / 1 = TRN / 2 = Art / 3 = SPG / 4 = Armor / 5 = Mixed ]
....2....= Amount Ammo1 (Primary)
....3....= Amount Ammo2 (Secondary)
....4....= Health (HP)
....5....= Experience
....6....= data
....7....= data
....8....= data


Once the master file is loaded, it can be changed as the game progresses. If a unit is killed, -1 is stored in the units first data position.

Here is how the Kilroy 'array' is displayed:

Kilroy ( x , y , z )

x = player #
y = unit #
z = unit data

Examples:

Get the status of Human Script Unit 4.

x = player 0
y = unit # 4 <------ Script # = 1004 [ (4 + 1000) + ( 0 * 1000) ]
z = 0 <----- Status data

Local HUS = Kilroy( 0 , 1004 , 0 ): Script returns value = 1 (OK)


Get value of Ammo1 of AI Script Unit 15.

x = player 0
y = unit # 4 <------ Script # = 2015 [ (15 + 1000) + ( 1 * 1000) ]
z = 0 <----- Status data

Local AUA = Kilroy( 1 , 2015 , 0 ): Script returns value = 9 (9 rounds)


The benefit of this type of array is how little room it needs to run. It adds very little to each Map Script. Each piece of data you may need to evaluate is handled within the same kind of LUA function (). Data can be strings (words) or integers (numbers), although this illustrates integers only, the most efficient in terms of memory and stack pushing.

Chunks (Blocks) or Routines can read/write multiple data chores in structured loops or specific assignments in one call.


After I determine the data exchange capability, I can work on how to save current map and enable save maps.

Current Scripts already use i/o to call next maps in Chapter or next Chapter in Campaign. I think we can modify this to save current, [load map ("n"th time)] = n = 1st time or whatever occurance. This number would be written to a Global Grid(array). When the Chapter/Briefing Screen Loads, it reads the following data:

Map player is exiting [ME]: ME is added to Map address in the Grid(array) by adding 1 to previous value.

Map player is going [MG]: Determined by HOT ZONE value player has entered. Again, Grid(array) stores adjacent grids (maps) for the 8 possible directions; (might just use 4 directions, N E S W).

...then checks to see if player has been there before:

If MG = 0 (1st time) then Load Map
If MG > 0 then Load Saved Map


If all of this works as I think it will, the Briefing Screen could then be modified to advise player of new data each time from any number of Script subsets.

Maps would be referred to as Grids or Sectors, since they are part of a larger Area in a Theater.

Player leaves 6 to the North and Enters 2 from the south. Player had already been in 2, but Briefing advises that enemy units have moved into that sector in pursuit of his units. This would be handled by monitoring script ID movment and updating the Sector (map) 0.txt file as changes occur.

*** A brief test did pass a Global value for number of units in a script # to another map. It wasn't a full bore test. I just ran a function to get the number, then added the DisplayTrace to the next map to see the value.

Comments? / Suggestions?

[redvlastelin]

danzig70, it is not quite clear what you need? This is a topographic maps of the former USSR: www.rspin.com/maps/2006/berkeley.html
May be they should be so: vif2ne.ru/nvk/forum/files/Vasiliy/%28080415094225%29_Karta_dlya_KSHU-1940.jpg
This is the military topographic map of the General staff of the USSR ARMED forces.

Why put the custom maps in a global company? Most of them made bad and wrong and the size is very small. On the other hand in the mod GZM maps made on the basis of the actual topographic. I think it is necessary insert only the maps of the cities, industrial objects and complex architectural structures. The rest should be generated.

[danzig70]

red, that first link is excellent, thank you. The optimum scale is 1:25000 or 1:20000 as these maps are of sufficient scale to show the precise location of buildings and still have longitude/latitude information on the map margins. City Plan maps are of increasing scale (1:5000) but usually loses the lat/long information. HungaryBlitz has graciously allowed me to map his current campaign in the HRA mod. This will (hopefully) demonstrate how community-made content can be displayed to others with links to the mod website and links to download the files. There is no reason why the same could not be done with GZM campaigns/chapters, etc. Except that I havent downloaded it yet.

MP, you also subscribe to AmmoReloader:) I was thinking of things that could be done with the description files. Do you think modifying the files mid-chapter would cause a crash? Only one way to find out I suppose. I usually keep my script group numbering fairly simple: 1-1000=player forces, 1-100 infantry, 101-200 armor, etc. Then 2000 series for opponent, 3000 series for civilian (player 2) and then 4000 series for objects etc. I am a bit confused by your example in that respect. I definately like the array with the units status and unit type. I think it would fit nicely in the chapter script file. The idea of sectors is also good. I can draw boxes on the globe for each sector similar to the BKTopo grid posted previously. This would be helpful if there are multiple chapters or campaigns being displayed. I really appreciate everyone's input.

[redvlastelin]

danzig70, no problem. I very much wanted to help you, but I have no knowledge. You have enough maps of this site or not?
I think that GZM really is best suited for your project. There is a lot of useful resources: model civil people, flags for staff and many other.

[danzig70]

Here are some screenshots of what I had in mind. I tried to take a fraps video but it crashes worldwind.

This is when you open the program. Then you use the layer manager to show the layer for Hungary.


When you click on the country icon the page for Hungary opens with available mods (linked to the mod webpage) and available chapters. The little icon on the globe shows where the chapter takes place.






Then you can launch the game



The game is saved as border.sav. The game can be relaunched by clicking on the chapter icon.



Then the game can be resumed.


If the enhancements to the chapter script and map scripts can be made I think it opens alot of possibilities.

[Major Pain]

Dan

I haven't tried to over write text files during the course of the game... yet. I have to implement notepad or a simple script to modify or something.

Since the grids are fluid, it may be a challenge to cover every angle of outcomes.

Sorry... I'll clarify

in my illustration:

Human = 1000-1999 - Player 0
AI = 2000 = 2999 - Player 1
Nueter = 3000- 3999 - Player 2

You can use 4000 for objects, - good idea, but most the time they are already player 2.

Using simple statements to define players range for objects is accomplished.

Possible to use the BK "type" numeration for:
infantry (000), transports(100), artillery(200), spg(300) and armor(400)
::
translates to [P^]000,[P^]100, [P^]200, [P^]300, [P^]400;

P^ = (Player number + 1000)

The tough part is assigning all of the game units a unique ID. It would have to be very strict so as to not cause issues during grids (maps).

So script# in each grid (map) should follow a pattern.

Mobile objects, those that migtate between grids, would be the most utilized (checked) and need to be in lower ranges of their grouping. [P^]000 through [P^]499.

Local reinforcments need to fall in range of [P^]500 - [P^]999.

It is doubtful any side would need 1000 script id# and objects, and using the same id# between various maps is ok for static objects and will most likely also work on defensive units found on various maps. Each grid map would have its own script anyway that defines objectives, hot zones, etc.

If the player picks up reinfocements during play, those need to fall into players lower numbering profile, so this has to be preplanned; including any para units dropped along the way.

Using "Get" and "Set" functions, some changes can be managed. (Get is the opposite of Set.) It is too early to know if script id# can be reassigned using these fuctions, but there is a way around this if not.

Also, using script, the player could benefit from local reinforcements by changing the relationship flag between player 1 and player 2. Player 2 neutrality/alliance stance can be switched, with scripts used for troop movements. This I have already done on previous work.

An example of this:

Player moves through a sector to reinforce local units enaged in defending a position. He can see "with their eyes". This function is in the BK script already. So while he can see them, and assist them, he cannot move or direct them. At the end of the sequence, they return to previous stance and say thanks. Player 2 units have the same parameters as p0 & p1; ammo, health, etc.

Benefit: Allied players can pass repair and resupply between them.

Exception: Troop resupply between allied players is not supported.

This code is already in BK, borrowed from Multiplayer.

Can assign any number of Players either neutral or allied-specific: Again, borrowed from Multiplayer.

Much to still work out...

[danzig70]

sounds good MP. If there are over 500 units on a map it usually slows down the game so that should work fine. You could assign permanent general script ids and then just change the name if necessary for the display trace. After all, one infantry regiment would be organized just like another. Then perhaps subtract killed units after the mission. Dont worry about the text files as those can be made in the c++ or c# program in the scenario editor.

I have the files for the HRA demonstration if anyone wants to try that out.

[Major Pain]

I figured we could handle text files outside of scripts, as you suggested. That could be handled in the Briefing or cut scenes.

This might be important as a player re-enters a map a second or third time.

Testing shows all variables are moving between maps.

I'm still looking at the read/write scriptunits id# inside a script. They can be read, but not changed so far. There is way to do this, you can give para units a script id after it lands.... assignment function.

I am still trying to read the Ammo and HPs. If I can break this code, then we can re-write them with the 'set' command.

As mentioned, 'Get' reads and 'Set' writes.

This might be a case where we need a define or declaration command in a .dll. It should already exist within the code since it is used in the combat data.

Once I get the entire 16 grid map completed, I'll send it with the scripts and minor objectives and hot spots. I'm trying to use container and patches from exisiting files in the Scenario folder to speed grids building. Maps built based on random maps. from BK vanilla, modifying scripts as needed.

This is purely for testing. I still haven't done anything about loading saved maps. That will be next.

[redvlastelin]

danzig70, this map made by the player, if I understand correctly? Show please generated map. May be you need to use the template of the army? I think it will ease the difficulties and such a condition of the army will be easier to control.

[Folgore]

If I understand correctly (...and I'm not sure of that...) there will be an huge amount of variables to be managed and the need of preplanning, at least, the first set of them.
That's a risky combination. Mistakes are around the corner.

Not sure to understand the grid approach applied to maps. Does it means that a chapter wold be transformed into a grid and that you can move into that chapter to any contiguous map to the one you are? If so it could be interesting knowing whether the cheat for enabling all map in a chapter could be managed in order to allow just contiguous maps.
[The cheat: SetIGlobalVar( "Cheat.Enable.Chapters", 1 )]
This for the first run, then .sav files can be used to enter again in maps you left.

Just an idea, it's not .sav files VS MP variables...

[danzig70]

Feb 26, 2012 1:28:20 GMT 1 Major Pain said:

I still haven't done anything about loading saved maps. That will be next.

The saved game can be loaded by clicking on an icon as in the screenshots above if that makes it easier.

Folgore, I think if we work in steps we can minimize the amount of troubleshooting necessary. The first step, I think, is to track the core units and allow them to exit a map/mission, save the game and then enter an adjacent map/mission. The core units could then either choose to reenter the first map or move to another adjacent map to progress in the chapter.

For example, in the Saar chapter the objective of the chapter is to capture Saarbruecken and Volklingen and secure the surrounding hills. This is accomplished by securing defensive positions and eliminating enemy. The core units consist of a tank platoon with motorize infantry and support vehicles. You need to cross a bridge.

The chapter starts in Forbach.



Here the exits zones are marked to show where you land after you exit.



I decide to follow the rail tracks and cross the rail bridge into Saarbrucken and capture the rail yard. This could trigger reinforcements by rail.



I find it is heavily mined with an artillery piece in a clearing on the hill. So I send a recon team to enter the map from another direction, call in an airstrike and destroy the battery. This could triggers infantry reinforcements with engineers. They go to their scripted positions. Since I want to advance quickly I decide to approach from another direction. The line represents the border. The box marks the bridges


This is a view of how terrain can determine exit points. The x marks where friendly units are positioned.


This is a map from the US 70th division of german defenses in Jan 1945. The defenses for the saar chapter would be similar except the a/t defenses will follow the border and the siegfried line.


So I think it will be difficult enough writing a function in the chapter script to control the movement of a few core units. The icons for each map could represent a company, battaltion or regiment HQ or just the position of an unit. Then as you advance, the icons can be moved around. I have a clumsy interface for that where you can manually enter the new lat/long.

[danzig70]

Here is an image of the first four maps showing the roads and railroad tracks


For a test, you start in the lower left, forbach.xml. The upper left is saar1.xml, the upper right is saar2.xml and the lower right is saar3.xml. I have a single tank with a script id of "1". I have added missions to the chapter named the same way and placed the mission folders in the scenariomissions directory. The map area names on the forbach map would be "north, northeast, east", respectively. In the map scripts, I used something like:


function ExitMap()
if ( GetNScriptUnitsInArea (1, "north") >=1) then
DeleteReinforcement (1);
DisplayTrace ("save map as forbach.sav");
SetSGlobalVar("NextMap","saar1");
Suicide();
end;
if ( GetNScriptUnitsInArea (1, "northeast") >=1) then
DeleteReinforcement (1);
SetSGlobalVar("NextMap","saar2");
Suicide();
end;
if ( GetNScriptUnitsInArea (1, "east") >=1) then
DeleteReinforcement (1);
SetSGlobalVar("NextMap","saar3");
Suicide();
end;
end;

function Init()
   RunScript( "ExitMap", 3000);
end;


MP, let me know what kind of globalvar would work best. I would like to try just moving this single unit around. If anyone wants the files just let me know. This is just a rough sketch right now

[Major Pain]

Use the integer


SetIGlobalVar(NEXTMAP, MAP#)


This defines the variable NEXTMAP to the next MAP#.

We'd have to back up define a table in order to do much more.

But you can use the compass positions:

Direction..... to Map
0 = North.....m0
1 = NE.........m1
2 = East......m2
3 = SE.........m3
4 = S...........m4
5 = SW........m5
6 = W..........m6
7 = NW........m7

as the move direction to calculate the next map on the grid.

[danzig70]

Not sure what you mean with that example.
SetIGlobalVar ("NextMap", 1); in the map script.

then in the chapter script have:


function MissionFinished( strMissionName )
       local bScenario = GetIGlobalVar("Mission.scenarios\\scenariomissions\\forbach\\1.Finished", 0);

  if ( NextMap ==  1) then

                       EnableMission("scenarios\\scenariomissions\\saar1\\1");
                       
  end;
                     
end;


I also dont know what the local bScenario is.