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

Hi Steven... I played your scenario last night and initially I didn't take it too seriously as I was playing it to kill some time... but boy did I pay a heavy price for my lack of commitment!!! I ended up playing it for 4+ hours to salvage the little honor I had left after such a beating!!! I will give it a second try this weekend and I really hope to obtain a different result this time!!! SPOILER ALERT... DON'T CONTINUE TO READ IF YOU HAVEN'T PLAYED IT: My main problem was detecting the russian base to the north-east on a timely fashion... and I ended up with an incoming volley of nuclear Kent's that saturated the Turkish base AAD and basically destroyed it. I had most of the aircraft in the air at that moment, taking care of both syrian bases... some of them ended up ditching when they ran out of fuel since there wasn't a field to divert to, and some others casualties of Mig-31s. The other problem I had was due to my underestimation of the Slava cruiser's offensive jamming activities... I spent a lot of time (and foolishly lost a few A/C) dealing with it, since it was disrupting my operations. Once the Slava was taken care of, the rest of the ships were easy. I wasn't planning to use many of my tomahawk missiles on the two land bases... but using the D variant was definitely a great aid for dealing with the S-200s. The rest was setting up a few SEAD raids using Growlers and JSOW-laden SuperHornets. In the end, losing the base in Turkey forced me to use the rest of the Tomahawks to wipe the land facilities. I had to use the stock of 109's from the CG, the DDG and the Ohio to accomplish the task. In the end I ended up losing the scenario because I was unable to trigger the Victory Condition for the SEAL's rally point. I set the CH-53s to hover there for way more than the required 3 minutes... and I did that before 21:00, at 21:00 and after 21:00. No luck. Will try again and if I'm unable to make it, I will let you know. Boarding the bulk cruiser was no problem (after dealing with the rest of the ships of course). All in all this was a fun scenario, which I failed mostly due to my "informal" attitude towards it at the beginning. Making good decisions from the start is fundamental to winning it with minimum losses. Shall report back after my second round with it!!! Thanks for sharing it. cheers -E

These are both really neat ideas... there is an inlet to the west of Venezuela, the Maracaibo lake (http://www.britannica.com/EBchecked/topic/363734/Lake-Maracaibo), where tanker ships transit on a daily basis both to and from the Caribbean, carrying crude oil which is the main export product (95% of exports and the 20% of the GDP as of 2011 I think). Problem is these ships must sail waters that are under a silent but always present threat by our neighbor, Colombia, which claims ownership of the "Gulf of Venezuela" (both countries where close to a skirmish back in 1987, if you can read spanish (maybe using google translate) you can get more info here: http://es.wikipedia.org/wiki/Crisis_de_la_Corbeta_Caldas). As a former consultant for the venezuelan navy, I have participated in some interesting situations that can result in interesting scenarios, and mine warfare is an attractive topic considering the geography of that particular zone. So your ideas just helped me develop some of my own... I'll have to sit down and try to implement them (thank God holidays are coming soon!). In addition, these waters are very shallow, meaning that acoustic conditions there are a nightmare for ASW and minehunting operations. Thanks again for the interesting tips. Cheers -E

Great! Let us hope it stays this way ... the community has seen enough already, I agree. cheers -E

Hi Mgellis... thanks for your reply. I had created a few scenarios in the past which I intended to release, involving mostly forces from my native country, Venezuela (although I live in Panama nowadays), and I recall encountering some strange issues in the scenario editor which stopped me from continuing with the building process. That was some time ago tho', and maybe things have changed. If I ever get a hold of them (must be somewhere in my hard drive) I'll try to update them to HUD4 and see if there I manage to avoid the problems I've had before. Thanks! -E

Brad: Didn't mean to get anything started, don't worry ;-) Francois: Yeah I'm aware of Darren's passing, sadly. On the other hand I'm glad his legacy is in good hands now, since I remember you as a responsible fellow Harpooner since the hhq days ;-). I think migrating all the stock scenarios to the HUD4 will greatly improve the actual state of the game and will somehow reduce the complexity for newcomers who want to start developing new ones... congratulations on this undertaking... must be incredibly time consuming! Good to hear about Taitennek as well. Thank you for all your work! cheers -E

Thank you for the clarification Francois, let's hope they implement mine warfare correctly in the near future.

Hi Mgellis,I will try your scenarios in the weekend. Thanks for all your work (and to Francois/Gunny for HUD4). I have a question for you: are you using the H3:ANW scenario editor or the H3:3.6.3 one? Any strange behavior so far? thank you! cheers -E

I think one important factor to promote the use of HUD4, is to create a sorts of review about it (what it is, what it does, what units are in it, the benefits of using it, etc.). I remember Taitennek was working to do something along the lines, but by looking at the state of his site, I think he must be busy with real world chores. Then we need to start creating new scenarios for it and resume hosting multiplayer sessions every two weeks or every month or so. I have been away from active H3:ANW gaming for a while now, but I often check the Harpoon's forum over Matrix Games only to get depressed at the little (or none) improvement done to the game by AGSI. If the default scenarios and battlesets that come with the stock game would be converted for the HUD4, then I think releasing the official 3.11 update with these updated scenario files and with the updated HUD4 db as a default selection, then revitalizing the H3 community could be a matter of doing the right PR job in the forums so that other fellow Harpooners can migrate their scenarios and try new ones for the HUD4. Am I dreaming? Maybe... but if the game is able to hold its own without serious bugs, both in single and multiplayer, and the H3:ANW is stable enough to use for scenario authoring, then perhaps the latest inactivity of the community would start to be a thing of the past. cheers all, and a big thank you to everyone involved in not letting Harpoon die. -E

Hi Francois, I've been away from H3:ANW for a while now... can you please share what is wrong with mines? Is there any hope for a fix in the 3.11 update? thank you -E