Priority ranked list of capabilities to add to the ExportDLL interface:

 

Implemented:

• Write functions that can look up platform information from the database. This doesn't necessarily need to be via the ExportDLL interface but is required to do things like see which weapons are in a loadout.
• Expose the disk_id_to_annex_id function.
• Expose the GetLoadoutIndex function.
• Expose a CheckLocationDepth-like function that takes lat/lon instead of map coordinates. See SCENCHEK.C ~ ln 707 for components.
• Expose functions to the ExportDLL to replace the EventHead, TopGroup, and such passed by the GE. Currently the DLL is notified when there is a change but the DLL cannot change those root items and should be able to.(2009.095)
• Allow the DLL to say that it wants to over-ride each of the GE "effects" individually. Effects are things like MoveUnits, Submarine AI, Weather, ... The first DLL to over-ride each effect will be the only one to do so (so you won't be able to have two DLLs successfully MoveUnits).(2009.089)
• Allow the DLL to call each stock GE "effect". This is for if you write a DLL and want to re-order the effects processing, throw them into threads, add additional effects, or whatever else.(2009.089)
• 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)
• 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)
• 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)
• Let DLLs request the GE allocate and free memory for them. Initial use-case is for editing group paths, each point on the path needs to be free/allocated by the GE, not the DLL.(2009.077)

Please post to this thread with additional items and reasons why you would change the rankings (and how you would change them). Thanks!

Inserted: Let DLLs request the GE allocate and free memory for them. Initial use-case is for editing group paths, each point on the path needs to be free/allocated by the GE, not the DLL.

Implemented: Let DLLs request the GE allocate and free memory for them. Initial use-case is for editing group paths, each point on the path needs to be free/allocated by the GE, not the DLL.

My preferences

1. Harpoon events
2. Platform lookup functions.

The way I see I can not do much without the events.

Same for the platform data but the raw data can at least be dumped from the GE via the ExportDLL which enable creating test cases for specific platforms.

Data structure operations would be too early for me just yet.

DLL calling is (sounds like) an efficiency improvement, can wait from my side.

Great things, folks! Regrettably I don't understand almost nothing, but ... go on it

just to make waiting hard for you too, with access to the events it will be possible (among many other things) to create an exportDLL that controls long range ASW patrols, have it patrol an area, drop buoys.

 

Don has already created his Toolbox DLL which creates very nice patrol routes.

With (1) it will be possible to have the patrolling plane actually drop buoys (dropping buoys, or loitering or dipping are controlled through events).

With (2) it will be possible for the DLL to query if an a/c has an ASW loadout and determine how many sonubuoys it has on board.

Great!

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)

Hola Tony! I'm mostly an H3/ANW guy which is looking to spend more time in HUCE due to your great updates to the game engine.

I have a question for you: is it possible to send information or "push" stuff to the GE using ExportDLL?

Let me elaborate a bit more with regards to my question: I think it would be pretty cool to have the ability to both read and write data to all of the variables you are "exporting" through your DLL. I reckon the game's original source code is probably far from easy to expand to support things like HLA/RTI, but it would definitely be cool to "plug in" other software agents to the game engine/core simulation using your DLL.

 

Where am I'm going with this?: Imagine a stand alone application simulating different stations for training purposes (such as what the old Dangerous Waters tried to do) interacting with the entire "battlefield" through your DLL? Maybe this particular "simulation" which is now "hooked" to the game via your DLL can override some of the database values for its (existing) unit type due to the fact that it's able to perform an out-of-the-game-engine more complex hi-fidelity modeling of its sensors or weapons systems (not to mention physical characteristics). These new publishedf/injected values would become standard through the simulation during runtime to avoid problems of course. Imagine a stand-alone software agent to inject weather after its own weather model? Let's say "connecting" a semi-automated ATO generator (I designed and co-developed a prototype of such a thing 3 years ago) that would "read" the "known" assets contained in the running scenario for generating the next 24, 48 and 72 hours of sorties of an air campaign? Imagine hooking up an entire simulation built around Lockheed Martin's Prepar3D using a wrapper of its own SDK/API (called Simconnect) around your DLL? I understand there are a bunch of loose ends I'm not even considering (things like the GE's performance and scalability and how it would deal with latency and other aspects etc.), but if anything like this is remotely possible without overhauling the GE, it would open a very interesting world of possibilities (don't even get me started at things like external modules for a more evolved AI, a dynamic campaign running on a dedicated server, complex logistics, external topograhic/bathymetric models, a complex underwater acoustic model, etc etc etc). In the end the GE would still be monolithic (for playing the way it's played right now: as a stand alone air/naval tactical-operational level simulator) but also become a framework or common environment for distributed simulations. I think this was the vision that Spectrum Holobyte had in mind when they were trying to build Falcon4.

 

Needless to say, I'm not implying that all of this work should be done by a single individual (Tony in this case)... if it is indeed possible to massage the current source code to support something like this, then the "ExportDLL" would become a sort of IPC module with an accompanying SDK that supports multiple programming languages (C, C++, Java, .Net, Python, Javascript, LUA, etc.) . In other words, the DLL would serve as the in/out "interface" and the SDK would serve as the public document (specification) of the "protocol" supported by such interface to guarantee a correct interoperation between the modules and the core GE.

 

Anyway... I better stop here to avoid getting carried away by the excitement ... because my list could go on forever ;-)

thanks for reading.

Enrique (not as knowledgeable as my "tocayo" Broncepulido)

As a follow-up: Tony, I remember reading a document you wrote some years ago called "HC Restructuring ideas" or something like that... back then I was enthusiastic about your vision for HC because (I just remembered after writing the post above) that you had in your R&D road map the intention to build into the GE support for things similar to what I've just mentioned. Am I hallucinating ?

 

Thanks!

cheers

-E

As a follow-up: Tony, I remember reading a document you wrote some years ago called "HC Restructuring ideas" or something like that... back then I was enthusiastic about your vision for HC because (I just remembered after writing the post above) that you had in your R&D road map the intention to build into the GE support for things similar to what I've just mentioned. Am I hallucinating ?

 

Thanks!

cheers

-E

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

Hi Tony, that's it! that's the document I'd read indeed! Glad to see It's still very much valid after all this time!

 

I'm also very happy to hear about the ExportDLL bi-directionality ... this is going to be a very interesting feature once you're "done" implementing it.

 

I will certainly start spending more time playing with this feature. Is there any sort of documentation to get me started? are there any other example using a different programming language besides Pascal/Lazarus?

Is there a list of currently published/accessible variables using the DLL as a reference?

 

As a side story: I did an interesting "hack" involving an Elta EL/M-2238 3D STAR onboard a Venezuelan Lupo-class FFG and Global Conflict Blue (when it was open source);

I would read the binary protocol from the Ethernet connection and pull the radar tracks in real-time and then I would "push" them into the running GCB instance (modified version tho'). Then I'd save these tracks and use them to build scenarios using real world radar tracks. I wanted to do the same for another Navy which I'd rather not mention, that consisted of pulling the AIS tracks from a ship borne WAIS transponder and using nav info (through talking to the CMS and sniffing the Ethernet network) from the gyros and other navigation devices, in order to build some sort of shore based C2 using GCB with an ECDIS layer on top. All of these things could be possible using the ExportDLL feature.

 

I'd love to learn more about the actual and future capabilities... I'll re-read your design document and please let me know if there is sample code or an updated version of such doc. I can do C,C++, Java, Python and a few others. My intention would be to use Qt instead of Lazarus, if such as thing is possible of course.

 

Thanks again for your message

take care

-E

 

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

Hi Tony, thanks for the info. I'll check it out over the next few days. Looking forward to your sample in C as well ;-)

 

For the time being I'll start becoming more familiar with HC from a player's point of view... I've been an H3 'Pooner since the Jesse Spears days but that version has been stale for a while now (Francois and Mark's dedication being the only exception to this remark) but after learning about the possibilities of your ExportDLL... things are looking much better. If I can ever be of assistance let me know!

 

Thanks again

cheers

-E

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.