evaamo

Thank you very much Francois!

That's a great deal of information. Thank you Tony. I'll be making some tests in the next few days and if I hit a wall you'll be the first to know ;-)

Hi Tony, few questions: Is it possible to read and modify an aircraft loadout when it's still on its airbase (or carrier / ship) via the ExportDLL interface? If the loadout is modified via the interface, does it trigger the ready-time defined for that loadout or does it happen immediately? Can I read the scenario actual weather conditions and elevation/bathy data from a specific lat/lon via the interface? Thanks! -Enrique

Hi Tony, quick question for you: does the current version of the ExportDLL allow the control of sub-units, like a cruise missile for example?

Tony, just to let you know that your C sample worked great under Qt/Mingw. Next will be to translate the samples in Pascal to C. Thanks for the help!!! -E

You can bet a million bucks on that! Hazy and fubar due to the lack of sleep the last few weeks I misread your post with regards to the 16-bit limitations... it's now clear to me that it's about the SE not the GE! My bad. Btw, I remember doing what I mentioned in my post above both in SCO (using it's C compiler) and in Visual C++ (VC6 not .NET, long ago tho')... you actually just made me Google such a thing because I swear I'm not nuts So here goes: http://stackoverflow.com/questions/594703/exporting-class-from-executable-to-dll/597344#597344 Errata (yeah, another): I meant to say "a more stateful UDP" in my last post... I cannot imagine an even less stateful UDP Anyway, I will take a look at your sample code... thanks again! I promise to write here only after my caffeine levels have become nominal, not before! -E

Hi Tony, thanks for your reply. I definitely think I got it wrong. Since I couldn't see/find a particular DLL to ask for "symbols", I imagined the process was something like this: Winharp32 being a 16bit application, used the rather old Windows API "__export" function to expose it's inner functions to the outside. It then would look in the "ExportDLL" directory for any existing DLL files. It would then load these available DLLs at runtime (that is, they would share the same Winharp32 process memory... specially since working with the stack due to the use of cdecl is a "delicate" issue), and then I would be able to "talk" to the GE via its exposed functions using the cdecl. Maybe I went a bit too far with this and should have asked you first... but I remember doing this in the past (specially in the UNIX world). As a matter of fact, my initial intention is to get these Winharp32 internals exposed through an TCP socket (or through a less stateful UDP implementation if the case requires it). So please... let me know how bad I got the way it works!!! Also... you forgot to include the link to your C example Thanks again Tony! Take care -E

Tony, when you build any of the DLLs in Delphi/Pascal do you actually specify to the compiler that it must "link" your DLL to the WinHarpoon32 executable? I tried to obtain via cdecl the pointer to the function lists (using Mingw, not MSVC) and had no luck... then tried using dumpbin and a few other tools to inspect the executable to see if I was missing something but couldn't find anything there to help me. I will try later today a few other tricks, however I was curious with regards to the building process and decided to ask you. I know you're busy with other more interesting priorities... don't want to sound like a pushy guy with that C sample code... I can wait :-) THanks again -E

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

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

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

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)

Hi Mark, I will restart playing this scenario with the just released beta of the ANW and HUD4 1.11. Should I just "rebuild all units" using the editor or have you made any changes to the original scenario file? Thanks, -E

Hey all... do you think the new version of the 3.11 beta would bring any improvements in this specific area?

Thank you for your hard work Francois!!! cheers -E