TonyE

Implemented: Expose the Harpoon events. These are things like Intercept events, path changing events, sinking events, and many more. These events are really the heart of the game. (2009.088) Implemented: Ability to pause the game so that the game structures will be in a consistent state for the DLLs to do processing. The DLLs should register with a callback function so that each DLL can have exclusive use of the game data structures when it requests and prevents other DLLs from modifying the structures at the same time. Without this capability, each ExportDLL cannot be sure a unit, group, etc. will still exist or be in the same state when the DLL starts and finishes operating on that item (and bam, crash the GE).(2009.088)

HCE - 2009.088 - 2013/08/16 =========================== - Chg:0000 GE ExportDLL Interface version is now 5. The changes from version 4 are adding two more parameters to the DLLInit call. PGEClosing: Pointer; PDLLBusy: Pointer which are each pointers to an 1-byte unsigned integer (so values 0..255). The GE will set the value of GEClosing to 1 just before the GE exits (currently not useful). The DLL sets DLLBusy to 1 (the integer, not the pointer!) when the GE should pause execution of Harpoon Events but should still process Windows Messages. In other words, when the DLL wants to work on the game data structures in a mostly consistent state while keeping the UI responsive. - Chg:0000 GE Fixed an integer overflow when reporting the number of missile hits when missile hits > 127. (thanks eeustice)

Yes, Missiles and Aircraft work in a similar manner, a single Aircraft unit may have an aircraft quantity > 1. Look at Unit->Air HomeUnit 0x0226c610 Unit * Endurance 46803 long DropTanks 5308 long PlatStart 2 '' unsigned char PlatNow 2 '' unsigned char Ammo_c 0 unsigned char Throttle 1 '' unsigned char DATA 205 'Í' unsigned char OATA 205 'Í' unsigned char Endurance should be seconds at Cruise though I haven't verified it works correctly in any regimes, let alone all regimes. Same with DropTanks. Sorry I haven't posted the next build yet, I'm having a very difficult time enabling the GE and DLL to both be responsive while the DLLs are doing heavy computations. Well, that works but lots of nasty crashing happens if you try to close the GE when the DLL has everything stopped up (reentrant windows message processing).

Good show

These have been exposed in 2009.087 and the related structures have been defined in uHCTypeDefs.pas in the StratsimsOSS SVN repository. I don't have the lazGUI example ExportDLL updated yet though (it is started but far from complete). Feel free to take a look at the code as always.

HCE - 2009.087 - 2013/08/05 =========================== - Chg:0000 GE ExportDLL Interface version is now 4. The change from version 3 is that StartGroup will now be called with a null group pointer where it would not have before. - Chg:0000 GE ExportDLL call "HarpoonEventHead" that sends a pointer to the top of the Harpoon Events linked list when that pointer changes. - Chg:0000 GE ExportDLL call "SonobuoyRegionHead" that sends a pointer to the top of the Sonobuoy linked list when that pointer changes. - Chg:0000 GE ExportDLL call "AllDeadUnitsPtr" that sends a pointer to the top of the linked list of killed units used for victory condition analysis. - Chg:0000 GE ExportDLL call "WeatherGroups" that sends a pointer to the top of the linked list of weather groups. - Chg:0000 GE ExportDLL call "VictoryConditionsList" that sends a pointer to the top of the linked list of Victory Conditions. - Chg:0000 GE Fixed an integer overflow when reporting the number of missile hits when missile hits > 127. (thanks eeustice)

Hi Bruce, welcome back! Your surveying of the landscape is correct, the only HC version being sold these days is in the Harpoon Ultimate Edition package that runs about $60 from Matrix Games. Your machine can run everything except the scenario editor. If you use some sort of virtualization to run a 32-bit operating system you would then be able to run the scenario editor as well. The easiest (and generally cheapest) way to do that is to do a Windows Anytime Upgrade to Windows 7 Professional (if you don't already have Pro) and then use the Windows XP mode included in Win7 Pro to run the scenario editor. See http://harpgamer.com/harpforum/index.php?/files/file/718-docs-scenario-editor-in-windows-xp-mode/ for the low-down. Speaking of the demo, I should update that one of these days too but it is still pretty recent. If you do grab the game, consider playing new scenarios here from HarpGamer. They make much better use of the updated capabilities of the game over the last decade.

Great Enrique! If you start to write code that really does something make sure to use the StartGroup pointer to grab unit and group information and not the SLOW UnitAlt, UnitSpeed, UnitLatLon, etc. calls. A solid approach is to note StartGroup when it is called and operate on any Groups/Units in the GameTime call. The GE will lock during the GameTime call for you to do any operations that you want to do each game second.

Oops, http://harpgamer.com/downloads/HCDLLv2.zip Hehe, Winharp32 , 32-bit application not that names haven't lied before but in this case it doesn't. I'm wondering if your memory is a bit hazy, __export would be used in the DLL, not the GE so you are consistently backwards anyway . My example uses a .def file instead of __export to list the exports. My HC Remote Viewer ran a TCP server in the DLL that was accessed by one or more client applications http://www.matrixgames.com/forums/fb.asp?m=1507362 . That post also shows the Google Earth ExportDLL which runs a little http server in the DLL that serves .kml files to Google Earth via network link. Yes, the DLL's are in the memory space of the GE but that is just how DLLs operate.

Hi HC players, Please help out your fellow players by being good beta testers. This means when someone posts an issue report, you go and try to recreate the situation. If you find the same lack of, or unwanted, operation of the game, mark the issue as "Confirmed". Add any commentary that you feel was missed from the original report (more detailed instructions to replicate the situation, desired behavior, etc.). Once someone has marked the issue as "Fix Coded" and the mentioned game version is released for testing, please go and test the issue to make sure it really is fixed. The original reporter would mark it as "Fix Accepted by Reporter". Anyone else would mark it as "Fix Verified". Thank you in advance.

Enrique, I think you have the process somewhat backwards, you would interrogate a DLL for which functions it exports, not the GE (Winharp32.exe). Here is a link to my old (and outdated) C example DLL for visual studio (2008). It might give you a starting point but it doesn't have the more capable exports worked in. I imagine you can glean the other exports from the Pascal code.

Implemented: Ability to pause the game so that the game structures will be in a consistent state for the DLLs to do processing. The DLLs should register with a callback function so that each DLL can have exclusive use of the game data structures when it requests and prevents other DLLs from modifying the structures at the same time. Without this capability, each ExportDLL cannot be sure a unit, group, etc. will still exist or be in the same state when the DLL starts and finishes operating on that item (and bam, crash the GE). Big thanks to Brains on this one hashing it out on IRC he realized what I was trying to do is already implemented. If the DLL exports GameTime() for instance, it can block the GE as long as it wants and do whatever it wants in that interval. There is no need for an additional interrupt mechanism.

I don't have a current example in anything other than Pascal but I imagine I can cobble up some C code, that's what the GE is written in and I have an outdated example DLL in C anyway. Once I publish that hopefully you can work from the Pascal to convert back to whatever language you choose. Yes, I see no reason you couldn't use Qt. Any 32-bit DLL that can export its functions via the cdecl calling convention can work. I've left myself a reminder to start updating the example C DLL on August 14th. As for variables, the money maker at present is "procedure StartGroup(StartGroup: PHCGroup);export;cdecl;" You can get a glimpse of the structures documented so far at https://tarzan.tgp.net:8443/svn/StratsimsOSS/HC/shared/pascal/trunk/uHCTypeDefs.pas , notably THCUnit and THCGroup Recently added in version 4 of the interface is the THCDLL_FUNC_REF, a pointer to which is passed in the DLLInit call. That represents a linked list of pointers to functions within the GE that the DLL can call. That list of functions will grow soon. Currently only Don's Toolbox makes use of those (see .pas and .lpr at https://tarzan.tgp.net:8443/svn/StratsimsOSS/HC/ExportDLLs/lazGUI/branches/ToolBox/ for some detail).

Thanks Enrique I still like that document very much, thanks for remembering it. http://harpgamer.com/harpforum/index.php?/topic/2272-hc-game-structure-redesign-idea-set-1/ The unstable builds were heading in that direction but I was not able to maintain tester momentum so I went back to stable builds and in so doing, less drastic changes. But yes, where we're going with the ExportDLL interface already enables some of the tricks you mention and I hope for it to enable many more in the next month or so. It will take longer for the example ExportDLLs to catch up though as fair warning. Already you could clone groups and units. Don in his Toolkit modifies group paths. Almost all of the new additions to the ExportDLL interface will allow direct modification of the exported game variables/pointers. That is very powerful in both good and bad ways. It is simple to crash the GE for instance but you can hide units, change RCS values on the fly, etc. One of the many challenges will be for those few with the ability to use the ExportDLL interface (i.e. programmers who actually know how to work with pointers) to share their knowledge and document as they go along. Unfortunately I don't have the time to "do it all." The SE remains a huge challenge as well, as we build flashy add-ons to the GE and replace models, the SE will still be stuck in 16-bit land unless someone gets really smart and uses the ExportDLL interface to make a new SE ...

HCE - 2009.086 - 2013/07/29 =========================== - Chg:0000 GE Fixed a crash that happened when all units of a group were moved into a new group. The crash happened when planes expected to land on now non-existent units from the source group. (thanks eeustice) - Chg:0000 GE More efficient calling of ExportDLLs. The GE now interrogates every DLL for every possible exported function when the GE is loaded. Once a scenario is running only the DLLs that implement a particular function are called. This vastly improves performance when multiple ExportDLLs are used and moderately improves performance in the single ExportDLL case. - Chg:0000 GE Fixed a couple of the ExportDLL functions that assumed the newest ExportDLL interface version was 2. They now use an arrangement of verInterface > 1 so that any future interface version will still call the older DLLs. Note that this only affected a couple of the calls, NukeRelease being one of them. - Chg:0000 SE -l command line option now works. - Chg:I031 SE Added a helper function for reading structs during scenario load. This should eliminate some of the Out of Memory errors on large scenarios. (thanks eeustice, Brains)

Implemented: More efficient calling of DLLs. Right now every DLL is queried every time an exported function is called. The GE should maintain a list of functions each DLL exports (built at GE start) and only call the DLLs that implement the given function. (2009.086)

Grumble, you aren't overlooking anything yet. I'm tentatively planning most of my Harpoon time the next few weeks to go towards the ExportDLL interface so some of these capabilities will start cropping up. See also http://harpgamer.com/harpforum/index.php?/topic/20881-exportdll-interface-task-list/

Haha, so did the US, maybe Russia actually will build something up instead of just talk and PowerPoint about it.

HCE - 2009.085 - 2013/07/20 =========================== - Chg:0000 GE Fixed a similar issue to 2009.084, except in ResetGroupCenter this time. (thanks eeustice)

HCE - 2009.084 - 2013/07/16 =========================== - Chg:0000 GE Group positions will teleport less frequently now. There was a integer overflow bug possible in groups with many units. The integer in question has been changed from a 'long int' to a 'long long int' and the test scenario no longer has the teleporting group. (thanks eeustice)

Yes to all.

Don, you've done better than I could have imagined when we started. Once I get this work project out the door I should have slightly more time (eta end of July). More people using the ExportDLL capability would certainly be good though for building libraries of functions and for introducing object-oriented concepts to hide the ugly pointers and linked lists and such.

Nicely done , haven't watched the video but hope to tomorrow.

Don't forget the groundwork donaldseadog has been establishing with http://harpgamer.com/harpforum/index.php?/files/file/809-toolbox/ . Source code at https://tarzan.tgp.net:8443/svn/StratsimsOSS/HC/ExportDLLs/lazGUI/branches/ToolBox/ (to someday be moved into a more sane location). IDE and such is http://harpgamer.com/harpforum/index.php?/files/file/763-codetyphon-lazarus-programming-tool/ Any intrepid programmer can help make it happen, I've been exposing the guts of the game as time permits and with the limited interface so far Don has added an initial ASW patrol pattern.

Try opening it with the SE (Scenario Editor/WSCENEDT.EXE) in the HC Beta forum here at HarpGamer. There is currently a zip file with many game components, just grab the editor out of it, plop it into your HC Gold directory and give it a try (as always, back up your existing SE or rename this newer one to a different name). I think it will work if the database file format hasn't changed too much.