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)

After you have submitted an issue I highly recommend you click on the "Track Issue" button to set up e-mail notifications when the issue is updated.

Great article, much clearer than the original!

With sadness I am removing the CodeTyphon installer from the HG downloads. I've examined some of the source-code first hand (for some of the GIS components) and it appears to be an unlicensed derivative of a commercial component. There have been other (less concerting to me) charges levelled against CodeTyphon for having treated open source material incorrectly (renaming files and such, lack of proper attribution) as well. In any event, you can still get CodeTyphon directly from its publisher but I would encourage using other solutions (such as Lazarus directly). There have been multiple efforts to help the CodeTyphon folks to a more compliant situation but they have not been interested in such help.

I just want to give a shout of thanks to broncepulido for the issue reports he has created the last week or so. It is heartening to see them documented. Please support him and the game by verifying his reports (i.e. does the problem happen for you too?), adding detail, and adding your own thoughts on what the correct behavior might be. My Harpoon time is currently focused on the XML scenario file experiment so I won't get to the issues for a while, show your support by taking part in the issue tracking process. Thank you

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

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.

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

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

Yes, SBs last for an hour , SR->time = GameTime + 3600L; The second biggie with Sonobuoys is that the GE will only keep 768 of them at a time in the scenario, when SB #769 is dropped, #1 is destroyed even if it hasn't been deployed for an hour. This is pretty obviously an artificial limit to keep the game running at a decent speed on older computers. It may well be time to change this limit as well. I'm open to the changes, you guys figure out what you want.

Thanks, much better! Too bad it wasn't a Russian boomer or something similarly sinister.

Did the link to the article get cut off? I'm not able to quickly find the article on the Defense Aerospace site either.

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

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. See http://harpgamer.com/harpforum/index.php?/topic/2176-replenishment-at-sea/ (and feel free to comment there of course) 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.

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.

Thank you Gopher, that's a good start!

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!

Scenarios can be larger than 64kB these days. Thanks to one eeustice I've seen > 250kB.

HCE - 2014.020 - 2014-10-22 ========================== - Chg:I065 SE Fixed char overflow and around 50 uchar overflows dealing with number of plane units on an airfield/carrier. Probably good up to 255 of them now. (thanks eeustice) http://harpgamer.com/harpforum/index.php?/tracker/issue-65-memory-allocation-fault-in-se-westpac-backyard-scenario/ - Chg:I088 SE Fixed uninitialized variable that triggered the issue as well as a few others that came after the first. (thanks eeustice) http://harpgamer.com/harpforum/index.php?/tracker/issue-88-new-se-run-time-check-failure-3/ - Chg:I090 SE SSBN Launch Missile attack as part of a group's course was affecting the group's course. This was fixed accidentally in 2014.019. (thanks eeustice) http://harpgamer.com/harpforum/index.php?/tracker/issue-90-ssbn-launch-missile-attack-in-new-se/

From IRC Chat

And what I mean here is that by allowing the scenario editor to vary ready times, there is potential to effectively limit magazines. I'm not understanding here. Please elaborate on where you would be entering ready times and how they would impact the game. Allowing the scenario editor to vary ready times is too broad, is it per installation, per loadout, per plane, ...?

I have no real-world experience of knowledge to apply. My thoughts are more broad as a result. Factors influencing ready times (in no particular order): * Weather - Readying during a Typhoon, whether on a ship or land will be slow. * Installation damage - a severely damaged airbase or carrier will be less efficient. * Workload - If my re-arm crew has been working non-stop for 24 hours they are probably going to slow down. * Type of aircraft * Aircraft workload - if it has flown 30% of the last 72 hours the maintenance is probably going to catch up with you and slow down the readying process. * Type of ordnance * Quantity of ordnance * National affiliation? - Always a tough one I know, are the Israeli's better than the Americans at re-arming F-15s, etc. So I might imagine each aircraft type has a base re-arm rating that indicates how easy it is to re-arm. That is modified by each of the other modifiers to come up with a ready-time. As usual that is the easy part compared to teaching the AI how to manage its planes but that doesn't mean we shouldn't make changes.

HCE - 2014.019 - 2014-10-12 ========================== - Chg:I089 SE Fixed short int overflow counting units in the scenario analysis. Also expanded to show Green unit tallies and format it all nicely. (thanks eeustice) http://harpgamer.com/harpforum/index.php?/tracker/issue-89-scenario-analysis-window/

Keep going guys. I'd like to hear what you'd really like and work back to something manageable from there, possibly building in structure for later advancement toward what you really want.

eeustice and I participated in a Harpoon 4.1 (paper) scenario along with the umpire (Raymond Runge) and another pleasant fellow. Here was a shot of the action, Brits trying to slow up the Soviet invasion force near Andoya before the Americans showed up. It was a great experience, both rewarding and painful at the same time. Anyone who umpires a H4.1 game is either naïve, insane, or unreasonably dedicated! That said, I could see myself running a scenario with 3-4 ships (none of which are carriers). The Harpoon Classic portion of the convention was fantastic, with at least a handful of variable start point display bugs fixed in the 32-bit SE (most of which also existed in the 16-bit SE) as well as other 32-bit SE bugs and a GE tweak or two. Thanks to eeustice for keeping me focused, it was great to meet another Harpooner in person! https://www.facebook.com/NavConGames