TonyE

Totally uninformed question but can all 8 ESSM be guided in that small of a window? I would think they would in in Home All the Way guidance in this case since we're not talking AEGIS.

Grunf, which scenario in particular. Usually it is just busy scenarios that are slow but we'd be happy to take a look. What version of the GE are you using (it will be in the title bar, 2009.050 or some similar looking number)?

Oh, this is going to be fun!

You probably have a dialog box that you can't see (beyond edge of monitor). Close the game, run http://harpgamer.com/harpforum/index.php?/files/file/228-hce-clear-game-options-registry-settings/ and then try again please.

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.

HCE - 2009.077 - 2013/04/16 =========================== - Chg:0000 GE Incremented ExportDLL interface version to 4 because of a change to DLLInit that adds a new pointer sent to the DLL called funcRefs: PHCDLL_FUNC_REF. This is a linked list of function pointers sent from the GE to the DLL. Function pointers sent so far: NewPtr DisposPtr del_HarpoonEvent_list

That is fantastic, thank you for putting in so much effort to publicize Harpoon!

http://harpgamer.com/harpforum/index.php?/topic/20912-battlesets-where-fighters-seem-to-have-no-guns/&do=findComment&comment=41924 is the correct instruction.

When we get a version we are mostly happy with we package up all of the changed files and send them to Matrix. 3-9 months later they release on their website that often makes it into the "check for update" application. Yes. The only issues not worth reporting are ones that already appear to be fixed from reading the ReleaseNotes.txt from the most recent beta version here or issues that don't exist when you try to replicate them in the most recent beta version here.

It depends which USNI battleset you mean. The one with five scenarios is quite old, released around 1991 and should show the old behavior. The re-made USNI battleset (ten scenarios)(called USNI - US Naval Institute) is very new and should show the new behavior. Yes, guns should operate the same in all battlesets EC2003 and newer.

In other words, severely damaged subs are forced to surface. They don't count as dead until you sink them, same as always on that front.

See http://harpgamer.com/harpforum/index.php?/topic/2395-hce-release-notes/?p=12359 (and other areas in the ReleaseNotes.txt.

yojimboguy, we are using this issue as a instructional moment of sorts so if you felt extra abused, that is probably why. From the thread so far you have at least tacit verification of the problem from Brad. The next step is indeed gathering a better understanding of what is expected in the commondb battlesets. I'll help you there, the AI should use the guns automatically and the player should have the option to use guns in the F1 (Attack) dialog. Once you have that it is time to craft the small test scenario. 1. Blue airbase, Red airbase in close proximity. 2. One type of Red aircraft, preferably without weapons. 3. One type of Blue aircraft with air to air guns. 4. Set up a Long Range patrol for each side. 5. Save, test, and file issue report with detailed instructions and the files. The small test scenario is very important for the sole reason that it makes finding and fixing the bug much easier. Using a scenario with 20 groups may mean I have to sift through literally hundreds of times more harpoon events than the simple test scenario. Yes, it sucks but we're in the position of one programmer, many players so the more the players do to make good use of programmer time, the more improvements you get.

It isn't instant action itself but rather that you are then running a second scenario after starting the game (some section of memory isn't being cleared properly). The subs stopping documented cases are happening on the second or later scenario played in a session.

Keep us updated please.

If you aren't feeling certain your issue is a game issue the General forum is a great location. Definitely add an issue to the issue tracker when you are comfortable there is an underlying game issue.

Thank you, I've updated that header in the Defect Tracking forum.

Maybe if you put some Standards on the thing Ratheon, but little stinking ESSM?

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.

Scraped these out of the old Issue Tracker listing (http://harpgamer.com/issuetracker_old/issue_list.php) http://harpgamer.com/harpforum/index.php?showtopic=2429 http://harpgamer.com/harpforum/index.php?showtopic=2428 http://harpgamer.com/harpforum/index.php?showtopic=2426 http://harpgamer.com/harpforum/index.php?showtopic=2427

It is an issue (or series of issues) with the GE (game engine/winharp32.exe) that few people notice. It is known by me (programmer guy) and I took a really good look at it around two years back. Unfortunately it is not an easy fix (or series of fixes). Honestly I keep putting it off because it means breaking the scenario file format which has been done twice in the 20+ year history of the game. Read into that the formation keeping seems to be more of a design problem, not just a bug or collection of bugs. Sure, the ships should sprint and drift without big changes but a group of ships continuing to sail East after a formation change when the group path shows North is an issue with bigger code implications and needs.

Now how are you going to modify the AI to understand logistics? Implementing it for the humans is one thing (far easier), introducing it to the AI is a whole additional ball-game.

Great discussion guys, yes, do dream!

For those of us aching to see fancy ASW patrols and auto-rendezvous of air refueling tankers this effort by Don Thomas is fantastic. Plus it is open source and free for you to improve upon should you feel that you can't play nice with Don. He has put a lot of effort into this and the results are improving faster than I had imagined they could or would. It was a real treat the other night to select a Super Hornet group, a Tanker group and tell them to meet. The little buggers headed right towards each other and I joined them when they were close enough and refueled with much less hassle than usual. Sure this is just the beginning but a very functional beginning!

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!