TonyE

I know it is late notice but I'll be gaming in about 45 minutes and would welcome some wingmen and targets...

Nope, you only need the one pfBuild file.

At this time there is only hdsm.res and so must be swapped. This will change but we don't have it planned out yet. Any time you import a DB into the editor, it overwrites any data already in the pfData file, so just make a copy of pfData for each DB you use, no need for the blank DB (which is in the downloads section at HarpGamer here) unless you are starting a DB from scratch.

the old G suit definitely would kill me right now but a scheduled event sounds promising.

As far as i know the Edit fuction is missing => something Tony is working on for the future and as long as we haven´t got an edit function for the BS-Creator you can use my workaround. Regards René What I'm working on isn't an editing of a battleset but rather saving of the settings used to create a battleset. So a file will be created that has the coordinates of the battleset, text of the battleset, filenames of the scenarios. As to how much farther the capability will go, I'm not sure. I'm tempted to save also in that configuration file of sorts a copy of the scenarios and such but I'm not sure. The other approach is as you both suggest, allow editing of a battleset (which already holds all of the information of interest).

Yup, we want to know too. I'm a bit slow due to prolonged and ongoing health problems but I aim to release an update to the BS Builder this coming weekend, in part with greater logging so that we can pin down the issue you are having.

I'll be trying again later to replicate the problem (your hdsm.res gives me the same error as you get) but so far don't have an issue in creating a battleset with your scenario. The screenshot of your export looks fine, it has no unexpected error messages but it would still be good to zip up your commondb.res and attach it here. Anyway, for now I've attached a copy of your battleset that I created here in case you were hot to play it more . For everyone's reference the BS Builder creates a log file called BSBuilder.log in it's directory, it doesn't say much useful for debugging right now but it will kick out your coordinates. BuddhaCarib.zip

Welcome to the fray. From your screenshots I can say that I'm going to pick on you in the future because you have the debug libraries in the first place (most people don't unless they have some development tools on their computer). It definitely appears that the battleset went together wrong, leading to the problems. A few questions and requests: 1. What language and version of Windows are you running (i.e. English 32-bit Windows XP Home or 64-bit Windows 2000 Pro)? 2. Please attach the scenario + orders files, commondb.res, and if you have them, the map coordinates you used in the BS Creator. Stick them in a zip file and you should be able to attach it to your next reply to this thread. 3. If you know the text you used in the BS creator, please include that as well so others can try to replicate your results. The key task with the battlset creator right now is testing the limits, perhaps you found one but I'm thinking it isn't as serious as a permanent problem. Thanks for working through it.

Now what do you really think? I think Iraq and Afghanistan are good excuses for the Air Force to whine about money. There aren't many people I know who aren't CEOs who think they're getting the resources they need to best do their jobs. People don't get paid what they are worth, certainly don't get the other resources (multiple monitors, fancy data analysis tools and training, ...). Another argument, when we aren't at war the people at war always sound good, they are getting battlefield experience that no amount of money can buy in peacetime. When people are at war, it is the current mantra, there isn't enough money in R&D, acquisition, pool parties. Now I'd rather not be at war but that just isn't the reality, maybe it is time for a war bond drive if money is needed. I'm no fan of deficit spending, long term stupidity for short term gain. I'd rather go the bond route with short term stupidity for longterm gain. Third argument, China was coming on strong before we infiltrated Afghanistan, and nobody (except perhaps India? or Russia?) could possibly keep pace. My point on this argument, long before war, the stage was set for the decline of US military dominance, funding the wars has just steepened the pace of relative decline a bit. 4th rant, It isn't called a little crappy ship for nothing, nor are 4 copies of a hugely expensive destroyer going to help that, nor were those same two programs going to help before the wars. How many nice little European hotrods could we have purchased with the same funds, I'd bet a whole lot more and they'd even have mission modules! I'd love to point a big finger at the acquisition process but frankly I don't know squat about it except it is awfully strange that a country can buy at least four modern Flankers for the price of one Raptor... Even scarier is seeing my friends deployed to Iraq and they go to the local sporting goods stores to properly outfit themselves, something is very very wrong. I guess I just needed to rant a bit

The only changes were to the ExportDLLs, test them if you like, but keep playing anyway

GoogleEarth.dll version 1, interface version 1, for GE 2007.022 Runs a tiny webserver that serves a kml file to GoogleEarth on port 8180 to the local machine. Installation: Extract ZIP with directories in tact to your HC directory, the GoogleEarth.dll will end up in an ExportDLLs directory and a GoogleEarth directory will be created with each unit icon separated into its own file. See the Word document in the ZIP file for further instructions. HCExportDLL_GoogleEarth_v001.zip

DataDump1.dll version 2, interface version 1, for GE 2007.022 Writes all of the exported data to HC directory in a file named datadump.txt which is over-written each time the game is loaded. WARNING: The text files can get very large! Installation: Extract ZIP with directories in tact to your HC directory, the DataDump1.dll will end up in an ExportDLLs directory. HCExportDLL_DataDump1_v003.zip

HCE has, as of version 2007.022 the ability to send some game data out to external DLLs. I'll work up documentation as able. As implemented in 2007.022 every piece of data that AGSI allows us to export is being exported. We'll work with AGSI to increase the exported data items (for instance, number of missiles or planes in a unit would be nice, weapon launch events would be nice, etc.). The DLL files will live in C:\Matrix Games\HCE\ExportDLLs\ in a default installation. To disable a DLL, rename it so that the file extension is not .DLL, i.e. rename DataDump1.dll to DataDump1.dll.bak to turn it off. The DLLs will slow the game somewhat depending upon how much processing each one does, some of them like DataDump1.dll make large files. The DLLs also throw their errors back to the GE, so if there are bugs in the DLL, it will crash your game. This was common in my first generation of DLLs. I have yet to optimize the GE for this process to reduce the amount of data sent and will do that as time permits. Data exported by the DLL Interface in 2007.022 (version 1 of export specification): // Functions to send the data to DLL void dllexUnitLatLon(UnitPtr Uptr); (Position in decimal lat/lon of each unit) void dllexUnitShowing(UnitPtr Uptr); (Visibility of each unit as viewed from each side) void dllexUnitURegion(UnitPtr Uptr); (Uncertainty regions of each unit as viewed from each side) void dllexUnitCourse(UnitPtr Uptr); (Unit heading in degrees) void dllexUnitSpeed(UnitPtr Uptr); (Unit speed in knots) void dllexUnitAlt(UnitPtr Uptr); (Unit altitude band) void dllexUnitShowingSide(UnitPtr Uptr); (Unit side as viewed by each side) void dllexUnitSink(UnitPtr Uptr); (Unit is sinking) void dllexGameTime(long GTime); (Current game time starts at 10,000 and increments in seconds) void dllexMsgLog(char *MsgLine); (Message Log line) void dllexUnitToGroup(UnitPtr Uptr, GroupPtr GroupOld); (Unit changing from old group to new) void dllexUnitNew(UnitPtr Uptr); (New unit, i.e. plane launched, missile, etc.) void dllexUnitFree(UnitPtr Uptr); (Unit freed, leaves map) void dllexScenLoad(void); (New scenario/save loaded, report info to DLL) I should note in case anyone is into programming and wants to get right to writing a DLL, holler and I'll help, but more importantly the version 1 specification isn't set in stone yet for what data is exported and how it is exported.

As an end user you would not notice any difference. It is indeed mainly for programmer types. It has the potential to lead to neat things. Two of the neat things with the original interface were the Google Earth exporter and the Delphi GUI application. I might make the Google Earth one work with the new interface tonight, then it will be useful to the end user. A couple of other neat things that could be done with the interface: 1. Track how many sorties you had during the game 2. Print out a list of units sunk during the battle (since the GE just gives us numbers but the export interface gives us names as well, not to mention when and where they sank).

I put a lot of effort into the export DLL interface again today, if lucky we have a good first interface version. Added export of scenario name/number, battleset name/number, harpoon path Fixed export of visibility status of unit Fixed export of side each unit is know as (unknown vs proper side) Fixed export of uncertainty regions Improved exported data so it will no notice the change from missile to torp for ASROC type weapons Improved exported data unit name Cleaned up the sample DLL code Anyway, you'll see these changes in 2007.022 but I figure nobody cares so why release it until more used changes are made.

Try 2 at the guns only working at their database limited altitude bands. Same tests as 2007.020 1. Test AAA guns in pre-EC2003 battlesets 2. Test AAA guns in EC2003, test for altitude Also you'll see in the zip file a DLL file that wants to go in a directory called ExportDLLs. When you have appropriate DLLs in that folder they will be sent information from the game (to be documented eventually). I'm hoping you can test somewhat with the DLL in place but it will slow the game down and will make a pretty large file datadump.txt in your HC directory so once you get sick of it, rename the dll to datadump1.dll.bak. Naturally if you have crashes and such please document as usual.

[17:08] AOA: could the capture of an enemy crew be translated into a temporary increase of sensors range and effectiveness? [17:09] TonyE: it is possible, yes, I have to wonder if that is going too far for HC though. [17:09] TonyE: that or something along the lines of what you mentioned before, maybe show a few of the other side's units for a bit [17:10] Bucks: wow [17:11] Akula: hmm, why couldn't it just give you a quick locate on a group (similar to the old sosus net in the GIUK battleset)? [17:11] AOA: I think the important factor that currently we are missing is that in any conflict, there will be assets allocated to SAR, and currently, nobody is in the need to allocate those resources. [17:11] Akula: you get the contact for a few seconds, then it dissapears [17:11] TonyE: hehe, yah, what Akula said [17:12] Akula: I do remember that playing the old DOS version....giving away my age again...lol [17:12] Akula: basically you could get an exact fix, and the uncertainty box grows over time till the contact dissapears [17:13] AOA: Yeah!!! the old SosuS!!! LOL that was long time ago! [17:19] Akula: does that even still exist in the latest version? I haven't really played the GIUK BS, since I played it so many times all those years ago. lol [17:19] TonyE: yep, SoSUS is still there [17:19] AOA: wow [17:20] Akula: well then you sort of have something to work from, lol [17:22] AOA: OK, I admit that it may be unrealistic to expect that a captured crew will speak immediately, but, what if when you pick up the crew you can also pick up from the debris maps, codes and orders? I know, overkill, but still trying to provide a good reason for a commander to allocate forces to SAR. [17:23] * TonyE leans towards overkill on that one [17:23] TonyE: ANW can have it [17:24] AOA: I know... [17:24] TonyE: not that it isn't doable, and gives a good reason to drop a bomb on the crash site [17:24] Akula: lol [17:25] AOA: I mean, the concept would still be the same, Tony, pick up a crew --> increase sensors efficiency for some time. [17:25] AOA: I was thinking about how to justify such a behavior. [17:25] Akula: well there is a real reason why navies scuttle damaged ships that look as if they could be captured

I honestly hadn't thought about water landings. Probably a good tie in with amphibious units, floatplanes, etc. There would be no incredibly difficult thing about having a land type and a water type if it came to that.

SAR is a longtime dream of Unclepoon (Don Gilman) so it is one of the few directives we have, to implement SAR in HC. Chat 9/26 on IRC: [22:36] TonyE: one thing DonG wants to see is Search and Rescue, I'm interested to hear what he has to say. [22:37] AOA: I like that [22:38] TonyE: seems easy enough to me in HC, we have mobile land units, we just need to make a land unit type that the friendly side must detect (player side as it stands can see all player units, all the time) [22:38] AOA: simulate emergency beacons after the destruction of a unit? [22:38] TonyE: yah, I suppose that would help [22:40] AOA: then the unit has to be "attacked" with rescue equipment?? [22:40] AOA: WHat would be the objective?? The benefit? [22:40] TonyE: I think you are right with the attack with rescue equipment [22:41] AOA: In real life, rescuing a pilot is important because it is expensive, but crews are not simulated in the game, so loosing the crew is not an issue. [22:41] TonyE: I imagine the objective is to rescue before the enemy kills the rescuee, thereby allowing victory conditions to work [22:41] AOA: ok, so it would have victory conditions purposes.... [22:43] AOA: could the rescue help in reducing ready times for A/C, simulating that some of that time is crew rest, and therefore, if a pilot is rescued, there are more pilots, then aircraft are ready more often? [22:44] TonyE: I'd dream bigger and think about logistics where the rescued pilot goes back into the pool of pilot resources, which may affect how often you can fly, sure. [22:45] AOA: exactly [22:45] AOA: wow, here is an idea! [22:46] TonyE: I wonder if planes randomly create downed crews as they are killed, boy that could be a mess. [22:47] AOA: So the beacon goes off, but it can be detected by either side, right? If your enemy picks the crew up, then, after a Guantanamo treatment session, your enemy obtains imformation, such as location of certain units. [22:47] AOA: no need for sensors. [22:47] AOA: your prisoner talks! [22:48] AOA: yes, random [22:48] TonyE: hehe, it was a manageable situation until you had that last idea [22:48] AOA: some die, others survive and want to avoid being captured by the enemy, therefore, you are forced to rescue them [22:50] AOA: or they will talk! So every time you pick up an enemy prisoner, you get a momentary update of the positions (or certain positions) of the enemy., [22:50] TonyE: I certainly like the idea [22:53] AOA: For example, if you pick up a fighter crew, you get an update of all aircraft positions, if you pick up an E-2 crew, you get an update (estimate) of the aircraft and subs positions... Don Gilman e-mail notes after seeing the chat: The Intel part is probably a bit overkill as it takes a few days to get someone to talk, most scenarios are over by then. Talk to Rabbit about how all of that works. Eventually doing crew morale to impact search and attack values would have a fatigue factor, pilot crews as cargo, repair crew as cargo (might as well model them too). But really I was looking for crew units, crew count and rescue capacity as attributes of Platforms, SAR missions and VC penalties for NOT rescuing crew if you are Western. So it's a BIG modifier. That was in the ORIGINAL 1988 design. And I believe the architecture still supports just that.

Definitely, very nice work Pete. How where are your Bradleys and M113s?

Sorry about Word document, will convert to a regular post at some point. The formative ideas came from TonyE, pmaidhof, Brains, CV32, Akula. HC_Amphibious_and_Land_Warfare_Expansion.doc

2007.021 is looking better on this front. With Rene's test scenario I can now fly my Tornado above the AAA ceiling. Might get 2007.021 posted tomorrow, perhaps Wednesday.

EWCM, take a look at http://harpgamer.com/harpforum/index.php?s...entry5434 please. Might you be entering an order number instead of a serial number in the Help menu of the game?

We can't help you much here until you have the serial number. eSellerate after sales support http://store5.esellerate.net/store/support/Default.aspx If that doesn't do the trick, contact Don Gilman, http://www.computerharpoon.com/contact Once you have the serial number we can help you further, or if you get no reply from Mr. Gilman we can knock on his door per se, for you. Hint, an HC-Gold SN looks like HCGOLD-000-0000-0000-0000-0000-0000

I'm not sure how far you've gotten, when you start up the game in demo mode, go to the GIUK battleset and load scenario 1.0 which is the tutorial. Once you are in the scenario go to the Help menu and try the registration there. Any luck?