A Tony status update

[TonyE]

As you may have noticed, we have a 32-bit SE. The main side effect of that from the programming side is that I no longer have to maintain backwards compatibility with the Win16 API. I can allocate memory in chunks larger than 64kB and pull off all kinds of other "fun" stunts without writing and debugging it all twice. I could even go wild and implement right-clicking, wow .

 

That said, even writing against the Win32 API natively is painful and that is where the GE and SE now reside. I'm more likely to take advantage of the underlying commonality to do things like work towards raising the items per annex limit in the database rather than add "pretty".

 

Recapping and pulling out key points from above:

*. I don't expect to distribute any new builds of the 16-bit SE nor maintain the ability to do so.

 

*. You can all run the 32-bit SE on 64-bit versions of Windows now.

 

*. The current builds of the GE and SE will only work properly on Windows XP and newer versions of Windows.

 

A potential glimpse into the future:

My current experiment (enabled by the 32-bit SE) is converting from a binary scenario file format to something easier to change. In the experiment that is XML via the libxml2 library. As I tinker I'll occasionally upload an example to http://harpgamer.com/temp/test.scq.xml . At the time of this post I'm not even to spitting out groups and units but you can see that at least the SE is spitting out some XML (showing which items from the database are used in the scenario).

 

Converting the scenario file format makes it easier to modify the internal game data structures. Currently they are linked exactly to the scenario and save formats, decoupling that, even in a minor way will help move forward.

 

With a less coupled Scenario File to data-structure situation we can look at using different Annex ID identifiers internally, escape the unsigned short integer situation we live in now. That in turn means billions and billions of items per data annex.

 

So the smart database editor says, wow, the PE (Platform Editor) would not be useable with billions of entries, not to mention it is harder to get it set up with each new version of MS Office. To you I say, yup, that's why a new PE is needed if my current SE experiments succeed.

 

What I need from you:

Start talking about what data points you can gather on platforms so we can add them to the database structure. I've been asking for this for the better part of a decade and apparently it is a challenging question .

 

Keep reporting issues. I'm going to make more of an effort to critique the style of issue reports on the utopian idea that it will gradually resort in better reports rather than totally choking off the flow of reports (why I haven't pushed it for a long while).

 

Happy weekend, carry on!

[Gopher]

Its a good idea to redesign the database structure.

From my point if view Harpoon2/3 had a good approach. They splitted it up to Propulsion, Sensors, Comm Devices and Warheads for the lowest level (See attachement H3.JPG) and cleaned some points up.

 

For example the "Edit Loadouts" Annex in the data base editor. Each aircraft has more or less a different number of pylons and its limitation. And the same loadout configuration on a F-15 leads to a different range than on a F-16. So, the number of loadouts could be reduced if the range value is added or calculated in the Aircraft Annex (what happend in the H3-database). Or lets define the loadout configurations in the Aircraft Annex (see Weapon 1, 2, 3 on Fighter_Mobhack.JPG)

 

 

On the top level was the country. This made it easier for non-expert-scenario writers. I guess for skilled scenario writers the country annex is obsolet.

 

The second top level should be from my point of view the Installation-Groups like ports, airbases and bases. This Installation-Groups are just virtual groups like a battle group and include fixed installations like docks, HQ's, Runways, open parks and so on and they could also include mobile elements like ships, tanks, aircrafts.

To make the life easier it would be goof when this groups could include also some other Installation-Groups like an airbase and mobile groups which may patrol. Also here I guess for skilled scenario writers the Installation-Groups are obsolet, but it makes the life easier for non-expert-scenario writers when they use in the database.

 

The third top level are the Facilities, some with a defined geografical location, some generic (international). With the Facilities start the issue with the hosting capacity like Carriers? Submariens? Ships? Aircrafts? Tanks? Platoons? Fuel? Ammunitions? How much?

Therefore I added a picture from Mobhack for WinMBT (LCAC_Mobhack.JPG) where the LCAC has an own Size, Weight and capacity (Carry). It is interessting to see, that they selected also the area for the capacity as on Harpoon 3 with the Hangar space.

 

The next level are the Groups. In Harpoon are no groups predefined. For expert is this no problem. But it is harder for novice to have no proposals.

 

Then we arrive on the level of the mobile units like Ships, Submarines, Aircrafts, Tanks, LCAC, Lorries, Solider. Some units could hosting other units.

 

For HCE it is questionable to have an own database Annex for Magazine (Weapon-Containers), Mounts and Fuel-Containers. At least an own Weapon Annex has sense.

 

I never understood why HCE used a own database independend from Harpoon 3.

 

 

I hope Tony this help a littel.

Cheers

 

 

 

Edit: Correction of attachment and made the text more readable.

[TonyE]

Thank you Gopher, that's a good start!

[TonyE]

My current experiment (enabled by the 32-bit SE) is converting from a binary scenario file format to something easier to change. In the experiment that is XML via the libxml2 library. As I tinker I'll occasionally upload an example to http://harpgamer.com/temp/test.scq.xml

Much progress has been made in the experiment, "just" paths and Harpoon Events to go (Harpoon Events being the toughest category outside of getting started in the first place). Same URL as in the quote.

[Gopher]

Just discoverd the test.scq.xml

There are 16 Annex's. What is the topic of each Annex?

From my point of view, the Annex structure of Subs, Ships, Lorrys and Airplanes shall be be the same, because sometimes it is difficult to have a clear line between this units. Example, a LCAC can swim an run on ground. Some subs from WWII have a gun and some an aircraft. Or Flying boats, they can swim, run on land and fly.

I guess the Groups structure and units structure isn't finish so far. There is missing the group path, group heading(?), group mission, group patrol area, group speed, sensor status ... The same for the units with more parameters.

By the way, could it be possible to implement some generic supply points, or points were reinforcement appears at a predefined time? In area like WestPac it is easy to just to add an additional group or base far away and it take time till the reinforcement appears. But in smaller BattleSets is the reinforcement available from beginning and this could unbalance the game. A solution could be to go toward multiplayer solution.

Should I create a counter proposal?

[TonyE]

Just discoverd the test.scq.xml

 

There are 16 Annex's. What is the topic of each Annex?

You can piece this together by comparing the IDs you see in the PE (Platform Editor) with the ones you see in the xml file.

 

By the way, could it be possible to implement some generic supply points, or points were reinforcement appears at a predefined time? In area like WestPac it is easy to just to add an additional group or base far away and it take time till the reinforcement appears. But in smaller BattleSets is the reinforcement available from beginning and this could unbalance the game. A solution could be to go toward multiplayer solution.

See http://harpgamer.com/harpforum/index.php?/topic/2176-replenishment-at-sea/ (and feel free to comment there of course)

 

Should I create a counter proposal?

Certainly. All I'm doing right now is replicating the existing binary scenario format in XML (and re-arranging pieces to make it more readable). If I get it working then we can think about making changes.

[TonyE]

Paths and events added though events are still very rough (unintelligible really).

[TonyE]

A little more work done on Harpoon Events, the flag field is now in textual form, an event_type and time_type.

 

<EVENT group_id="ZVa" dummy_2="204" dummy_1="204" time="0" unit_id="255" event_type="AIR_PATROL_EVENT" time_type="TimeAbs">

<DATA>8iggAwIACAj9/f39q6urq6urq6vu/u4=</DATA>

</EVENT>

http://harpgamer.com/temp/test.scq.xml

[TeTeT]

Is the xml format subject of discussion? I find that json and/or yaml are a bit easier to manipulate, especially to debug, but your mileage may vary. Using json might be quite nice for the scenario section of the website, as the scenario core information might easily be extracted from javascript itself. But I guess there are xml libs for javascript out there too...

[TonyE]

Is the xml format subject of discussion?

Too late for that discussion unless the experiment fails and so far that looks unlikely. I find XML easier to read and as you indicated there are many conversion tools. JSON and SQLite3 were both strong contenders (and we could still end up with a XML with embedded SQLite hybrid).

[Gopher]

I played a littel with your file Tony. Hopefully you don't start to screeming.

 

There are the basic question; shall the XML replace the scenario file and/or replace the commondb? From my point of view is the currend splitting of the scenario file and commondb very useful and I would keep it. So the annex entries shall be in a separate XML.

 

In a scenario XML could the datas be structured on a hyrarchical way (as you did) or on a flat way were all untis are in one set, all goups are in one set and the commanding structure is describe just the organisation like meta data how they are nested(?).

 

With which software did you create the XML?

 

 

2014-11-19_scen.scq.xml

[TonyE]

Thanks Gopher, I can see you put some serious time into that effort!

 

I agree that keeping the scenario and database split is good for editing. But when I think about distributing a scenario the idea of including the portions of the DB used for that scenario within the scenario file itself and giving the user the option of using the embedded DB information or loading from the newest database on file, I very much like including a copy of the DB in the scenario file.

 

For now they will remain entirely separate but that will likely change if the XML experiment is successful (i.e. if I get it to the point of it working).

 

To your sides I would suggest adding "stances". Is Blue the enemy of Red? Maybe Blue and Green share sensor data but won't protect each other. Maybe Cyan and Red share everything and will mutually protect each other. We had this in the 2012 series of HC builds that were abandoned. The defaults looked like:

		if (side == BLUESIDE)
		{
			// Sides[as BLUESIDE].Postures[view BLUESIDE as] = ALLIED;
			Sides[side].Posture[BLUESIDE]				= ALLIED;
			Sides[side].Posture[REDSIDE]				= HOSTILE;
			Sides[side].Posture[GREENSIDE]				= NEUTRAL;
			// Sides[sensors of BLUESIDE].SensShare[give to BLUESIDE][info about REDSIDE] = TRUE;
			Sides[side].SensShare[BLUESIDE][BLUESIDE]	= FALSE; // not to self
			Sides[side].SensShare[BLUESIDE][REDSIDE]	= TRUE;
			Sides[side].SensShare[BLUESIDE][GREENSIDE]	= TRUE;
			Sides[side].SensShare[REDSIDE][BLUESIDE]	= FALSE;
			Sides[side].SensShare[REDSIDE][REDSIDE]		= FALSE;
			Sides[side].SensShare[REDSIDE][GREENSIDE]	= FALSE;
			Sides[side].SensShare[GREENSIDE][BLUESIDE]	= FALSE;
			Sides[side].SensShare[GREENSIDE][REDSIDE]	= FALSE;
			Sides[side].SensShare[GREENSIDE][GREENSIDE]	= FALSE;
		}
		else if (side == REDSIDE)
		{
			Sides[side].Posture[BLUESIDE]				= HOSTILE;
			Sides[side].Posture[REDSIDE]				= ALLIED;
			Sides[side].Posture[GREENSIDE]				= NEUTRAL;
			Sides[side].SensShare[BLUESIDE][BLUESIDE]	= FALSE;
			Sides[side].SensShare[BLUESIDE][REDSIDE]	= FALSE;
			Sides[side].SensShare[BLUESIDE][GREENSIDE]	= FALSE;
			Sides[side].SensShare[REDSIDE][BLUESIDE]	= TRUE;
			Sides[side].SensShare[REDSIDE][REDSIDE]		= FALSE; // not to self
			Sides[side].SensShare[REDSIDE][GREENSIDE]	= TRUE;
			Sides[side].SensShare[GREENSIDE][BLUESIDE]	= FALSE;
			Sides[side].SensShare[GREENSIDE][REDSIDE]	= FALSE;
			Sides[side].SensShare[GREENSIDE][GREENSIDE]	= FALSE;
		}
		else // GREENSIDE
		{
			Sides[side].Posture[BLUESIDE]				= NEUTRAL;
			Sides[side].Posture[REDSIDE]				= NEUTRAL;
			Sides[side].Posture[GREENSIDE]				= ALLIED;
			Sides[side].SensShare[BLUESIDE][BLUESIDE]	= FALSE;
			Sides[side].SensShare[BLUESIDE][REDSIDE]	= FALSE;
			Sides[side].SensShare[BLUESIDE][GREENSIDE]	= FALSE;
			Sides[side].SensShare[REDSIDE][BLUESIDE]	= FALSE;
			Sides[side].SensShare[REDSIDE][REDSIDE]		= FALSE;
			Sides[side].SensShare[REDSIDE][GREENSIDE]	= FALSE;
			Sides[side].SensShare[GREENSIDE][BLUESIDE]	= TRUE;
			Sides[side].SensShare[GREENSIDE][REDSIDE]	= TRUE;
			Sides[side].SensShare[GREENSIDE][GREENSIDE]	= FALSE; // not to self
		}

		for (i=0;i<SIDES;i++)
		{
			Sides[side].PostureWarn[i] = 0;		// haven't given any warnings to
			Sides[side].PostureWarnLast[i] = 0; //anyone yet
		}

The XML file I upload is created by the game itself, my work-in-progress. When I do edit by hand it is most often with Visual Studio because it is handy on my development machine and does a good job.

[TonyE]

With which software did you create the XML?

To make the creation of the XML much easier in the game, I am using the libxml2 library.

[TonyE]

Inching forward again, found the bug I had coded in encoding the LAUNCH_EVENT Harpoon event type and fixed it.

 

http://harpgamer.com/temp/test.scq.xml(Example scenario file)

[TonyE]

More event types added such as sensor on/off and message, and alternate paths.