Jump to content

ExportDLL Tidbits and Q&A


TonyE
 Share

Recommended Posts

Please see the current lazGUI source for an example of keeping the UI responsive when undertaking a long interaction in the DLL without the game clock or effects running.

 

If you don't mind blocking the UI, go ahead and do your calculations during GameTime without messing with the DLLBusy flag.

 

For donaldseadog and the toolbox, see that same GameTime tab for an example of how to read and interpret Harpoon Events. You specifically will want to be making events on the path itself, not as part of the HarpoonEventHead linked list.

 

Events for each course point are stored in the pathEvents linked list made up of THCHarpoonEvents

PPathLeg^.pathEvents

 

(untested code below but it should give you an idea)

PPathEvent:= NewPtr(SizeOf(THCHarpoonEvent));

PMessageEvent:= NewPtr(SizeOf(THCMessageEvent));

PMessageEvent^.Message := PAnsiChar('My fancy message');

PPathEvent^.DataPtr := PMessageEvent;

PMessageEvent.flag := MESSAGE_EVENT OR ; // I don't know which Time flag to OR with MESSAGE_EVENT in your case. I would try looking at the MessageEvent created with the GE on a course leg to try to figure that out.

PPathLeg^.pathEvents := PPathEvent; // only if you don't have existing path events on this course leg. If you do and want to keep them, iterate through them until next is null and tack it on there. If you have existing and want to delete them, DisposPtr them to death from the tail of the linked list back to the start or you'll leak memory.

Link to comment
Share on other sites

As Grumble astutely noted, while all of these pointers are great and super-fast, you are at my whim in terms of changing the data structures. When I change the Group or Unit structures (and pretty much any other structure) in the GE, any DLLs that aren't updated to match will tend to fail with nice big crashes of HC.

 

These changes have historically happened in bunches over a period of a few months, with a year or more pause in between those bunches. For reference, the last few changes were: 2009.072 (a non-breaking change), 2009.070 (also non-breaking), 2009.027, 2008.046, 2005.b07.

 

Which brings up the second good point, I haven't described the entire Group and Unit structures in the example pascal code. I hope to do that in the next couple of weeks.

Link to comment
Share on other sites

  • 2 weeks later...

Just a quick word of warning, my THCJoinGroupEvent structure definition in uHCTypeDefs.pas is wrong. I'll be correcting it in 6-12 hours.

 

Never mind, the structure is correct but the game does a (clever|stupid) thing and starts the DataPtr with a short(int) containing the number of THCJoinGroupEvents in the DataPtr. This allows the joining of multiple units in one JoinGroup event.

 

Code to loop over them could look like:

     numjoins := short(PEvent^.DataPtr^);
      PJoinGroupEvent := PEvent^.DataPtr + sizeof(numjoins);
      for intC := 0 to numjoins - 1 do
      begin
        Memo1.Lines.Add(Format('Joining: %s unit=%d qty=%d to %s',
         [PJoinGroupEvent^.SplitGroup, PJoinGroupEvent^.UnitID,
          PJoinGroupEvent^.Number, PJoinGroupEvent^.JoinGroup]));
        PJoinGroupEvent := PHCJoinGroupEvent(NativeUInt(PJoinGroupEvent) + sizeof(THCJoinGroupEvent)); // ALE 20130828 move to next join
      end;
Link to comment
Share on other sites

Cool. And just where do you get Toolbox version 1.1.4 from?
C'mon Don, upload it! :)

Idea for Don: how about adding a Staff Note event too?
Just before the join event, to have SA pop up, saying:

post-2539-0-71092000-1378102891.png

Creates a fully integrated look&feel for the DLL expansion,
plus might even be useful to Show/Select/1:1 the merged group.

post-2539-0-71092000-1378102891_thumb.png

Link to comment
Share on other sites

Currently working on splitting a selected number of aircraft from a selected unit.

In this case group AFA comprises two fighter (AF00) ~15 mile ahead of the 4 strikers (AF01) at the group centre - both units flying vlow - and two further fighters (AF02) flying high and ~15 mile astern with intermittent radar. An incoming interceptor has just been detected and with a few mouse clicks I will split off one of the forward fighters to defend against the enemy interceptor.

The strike formation was formed from a strike group comprising 4 each F18s and F111s, once air borne two F18s were split of then joined back to the original group, then the off set feature of the toolbox was used to push one fighter unit ahead and one astern and each units altitude set as desired.

Note the AEW doing a couple of circles of home base with intermittent radar - set up using the AEW patrol function.

post-804-0-80999200-1378606221_thumb.jpg

  • Like 1
Link to comment
Share on other sites

Also started playing with changing sides, two different applications:

Capturing an enemy this is working but a little primitive as we can't access load out or weapon data to give an aggressors power but based on damage points and distance it is working 'for fun' standard;

Political change: a scenario with neutrals of significant power , what if they turn to the enemy side? This adds a new element. Rudimentary this is working so I think I'll make it a random possibility and in a separate DLL so the player can choose before game start to include it or not.

Tony's latest additions to the DLL capability means more time on some of the basic stuff so these will be awhile away (unless people say they'd like this toy).

Link to comment
Share on other sites

Just checked in changes to lazGUI and the shared code. For the shared code, only uHCTypeDefs.pas was modified. The changes were adding the definitions of the new function pointers passed by the GE to the ExportDLLs new in 2009.095.

I highly suggest using QueueHarpoonEvent any time you are wanting to add a HarpoonEvent to the HarpoonEventHead list.

 

lazGUI was updated to show an example of that, adding a Staff Note that goes off 5 game seconds after being entered.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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 :wacko: ha such is life.

Having ago at some work a rounds for this with the auto joining in the toolbox DLL.as I'm currently extending the function so that one group may be loitering.

If people have any questions or comments on operation please let us know, there are bound to be glitches all through it, goodness knows I find them all the time :P

Link to comment
Share on other sites

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 :wacko: 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.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...