ExportDLL Tidbits and Q&A

[donaldseadog]

 

Any one ever notice how when two air groups are joined the resulting group takes up the throttle of the 'absorbed' group, this is so frustrating ha such is life.

Actually a whole lot seems backwards about group joining to me now that we've gone through the exercise of making it happen from a DLL. It feels like the wrong group entirely gets absorbed.

 

And putting it as a course event, having to ensure the group with the future events remains (or you loose the events). It is clever in some ways though, fiddling with allowable speeds (if only it took the 'absorbing groups' throttle setting ) and I was surprised not to crash the GE by removing aircraft before join but after setting up the join (but not thoroughly tested so maybe still an issue here - I guess joining was never set up with delayed action in mind).

Mcuh further down the track, when we have database access (at least for speeds/throttle) I think work arounds will solve all the issues I can see at present and in any case it is functional if you know the limits. I have the joining now operating with an optional stationary group2 (group1 goes to group2, group1 can retain its next destination) but need to tidy it up a bit and think further about problems if group1 has a speed changing event at its next destination (as it mightn't be applicable to the new group).

[donaldseadog]

An interesting problem with my toolbox when playing in a large IOPG 2003 scenario (not found it so far in other battlesets), the 'join' command - once the groups join - produces a new group out of thin air with 255 aircraft as a bonus for using this tool .

needless to say I'm trying to track down this unintentional player advantage.

[evaamo]

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

[TonyE]

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?

There are two ways to modify the aircraft loadout.

1. Use the THCReadyAirEvent event from uHCTypeDefs. This approach uses the default ready time, a minimum of 30 minutes.

 

The construct is like the other Harpoon Event types. You create a THCHarpoonEvent structure and assign the proper ourGroup and UnitID (so the airfield group pointer and airfield unit ID at which to ready planes). To the DataPtr you assign a PHCReadyAirEvent (pointer to a THCReadyAirEvent structure). The members of THCReadyAirEvent...

Identifier - this does nothing

oldLoadIDX - Index into the list of loadouts for this plane. Planes in commondb battlesets can have a maximum of 32 loadouts. Figuring out which index to choose is pretty much a guessing game at this point. As the name suggests, this is the loadout the plane is currently carrying. The good news is that it doesn't much matter what you choose here as long as it is a valid value. If you give the wrong value it could in theory confuse the AI but I doubt that would actually happen.

whichPlaneType - Interestingly enough, this is a Disk AnnexID for the type of plane we want to ready. This is the same index you see in the Platform Editor (PE) so you can get that from the csv files pumped out by a database import. I say it is interesting because most game functions use a Memory AnnexID which is a different number than what you see in the PE.

LoadID - Disk AnnexID of the desired loadout.

numberAircraft - How many you wish to ready with the given loadout

whichMissionCode - Can be ignored as it is only used by the SE (Scenario Editor).

 

2. Modify the planes directly.

From a UnitPtr look at myPlanes which is a PHCPlaneRec (pointer to a THCPlaneRec structure). That leads you into a linked list of chunks of planes landed at that unit. THCPlaneRec->LoadID is the current loadout for that chunk of planes. Unfortunately this LoadID is a Memory AnnexID. Looks like I'll need to expose the disk_id_to_annex_id function.

 

 

Can I read the scenario actual weather conditions and elevation/bathy data from a specific lat/lon via the interface?

You can kind of read the weather conditions. The WeatherGroups Group pointer is a linked list of weather systems active in the scenario. The alert member (i.e. WeatherGroups->alert, WeatherGroups->toSouth->alert, ...) indicate the strength of the weather system. The strength can be from 0-12 (Beaufort scale in essence). The closest weather group to a group of units defines the weather conditions at that group. If there is no weather group within 200nm of the group of units, the weather has no effect. I can enumerate individual weather impacts if you decide to move forward with weather tinkering. (Effect2.c ~ ln 680).

There is not a way to determine whether a lat/lon is land or a certain water depth but I'll add that to the list of things to expose as well.

[evaamo]

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

[TonyE]

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

See http://harpgamer.com/harpforum/index.php?/topic/20881-exportdll-interface-task-list/?p=44049 for information on the newly exposed functions to help you along.

 

lazGUI has been updated a bit on SVN as well as the shared Pascal code to give a toehold.

[TonyE]

disk_id_to_annex_id() is more powerful than it might seem. It obtusely gives you a way to look up database information if you have prepped the .csv files from your commondb.res. By building a map of all of the Memory AnnexIDs Disk AnnexIDs with disk_id_to_annex_id() you suddenly expose all of the database information used in the scenario. Granted it is a pain, but it is possible.

[donaldseadog]

Eek, more work, but then heeee heeeee.

[mavfin]

I don't need other DLLs to load this, right? I don't see the cover function, etc...

[donaldseadog]

I don't need other DLLs to load this, right? I don't see the cover function, etc...

If you are after the functions in "Toolbox" then you need to get the latest file from:

http://harpgamer.com/harpforum/index.php?/files/file/809-toolbox/

and put the zipped DLL into the exportDLL folder of your installation.

The toolbox should appear when you start the game, you will need a recent beta main program.

Is this what you are after?

[mavfin]

 

I don't need other DLLs to load this, right? I don't see the cover function, etc...

If you are after the functions in "Toolbox" then you need to get the latest file from:

http://harpgamer.com/harpforum/index.php?/files/file/809-toolbox/

and put the zipped DLL into the exportDLL folder of your installation.

The toolbox should appear when you start the game, you will need a recent beta main program.

Is this what you are after?

 

Just making sure there wasn't a prerequisite DLL package to download in addition to your Toolbox. I've played with it some, and I'm getting an idea of how it works.

 

Found the missing stuff, too. I'm just old and blind, that's all.