ROE and Automated Defense

Harpoon 3 Advanced Naval Warfare is the result of decades of development and fan support, resulting in the most comprehensive, realistic, and accurate simulation of modern combined air and naval operations available to the gaming public. New features include, multiplayer support, third party databases, scenario editors, and OVER 300 pre-built scenarios!

Moderator: Harpoon 3

User avatar
hermanhum
Posts: 2209
Joined: Wed Sep 21, 2005 10:48 am
Contact:

Problem

Post by hermanhum »

ORIGINAL: rsharp@advancedgamin

So I invited feedback. Take it in from all the willing in the best forum available. Then I lay out how I'm going to make the changes to suit the user. The planned changes don't have anything to do with .opt files, I don't know where that came from except that it was a comprimise used in 3.9.4.
Nice evasion of the original question, again. So, I'll re-iterate, again.
ORIGINAL: hermanhum

The 394 (Beta RC13) isn't even an official patch release and it's already too late to fix the problem.
You intend to release the *.opt files for use in 394 and then take them out again in 3.10 As an interim fix, they are going to cause all kinds of problems. When you take them out, they will create even more problems. So, the Patch hasn't even been released and they somehow seem to be etched in stone.
rsharp@advancedgamin
Posts: 430
Joined: Mon Jun 19, 2006 7:39 am
Contact:

RE: Problem

Post by rsharp@advancedgamin »

I don't see any question mark but okay. It's in release testing. RC means Release Candidate and I would expect it's official release sometime next week. Not a hard date mind you.

Also, RC13 is as official a release as it gets as far as test or beta releases go. I set it up to be as open as possible to be as inclusive as possible. Something you have been recommending.

The actual patch release will, of course, still go through Matrix.

Thanks,
Russell
Advanced Gaming Systems
Home of Computer Harpoon
User avatar
hermanhum
Posts: 2209
Joined: Wed Sep 21, 2005 10:48 am
Contact:

Problem

Post by hermanhum »

ORIGINAL: rsharp@advancedgamin

Also, RC13 is as official a release as it gets as far as test or beta releases go. I set it up to be as open as possible to be as inclusive as possible. Something you have been recommending.

The actual patch release will, of course, still go through Matrix.
Beta and Release Candidates are official only in the sense that they come from AGSI. They are are still experimental software and not Official Patches unless released by Matrix. Thus, while they are still in the experimental stage, why are they considered sacrosanct and inviolate?

IIRC, the last Beta release from Matrix was Beta 10 (10/31/2008) and first public knowledge of these new *.opt files was in RC12 (2/5/2009).

When introducing something so drastic as these new *.opt files, why didn't the process return to the Beta stage in order to hammer out all the potential problems?

It certainly seems to the outside observer that there was never any possibility to prevent this potentially devastating implementation. It appears in RC12 and is immediately deemed unchangeable regardless of how bad it may be. If I am mistaken, please indicate at precisely what time and point in the process could such a bad implementation have been terminated.
rsharp@advancedgamin
Posts: 430
Joined: Mon Jun 19, 2006 7:39 am
Contact:

RE: Problem

Post by rsharp@advancedgamin »

Okay, so aside from arguing over what official means, let's get to the heart of it. The issue of micromanagement vs. auto-defense wasn't the subject of so much hyperbole until last week. You point to threads made before I was at the helm and I would have liked to have seen those previously. If it had come to my attention in December or perhaps early January, I could have done something about it then. It is a larger issue than those addressed with the option files. The option files can be disabled and have no impact. I have no such choice here.

Also, a good solution presents itself in 3.10 so the issue will be handled in a way that should please everyone. So I'm giving the issue the proper attention and I want the other players to know they are being heard. At this point, my only puzzlement is why do you suddenly believe this is the doom of the Harpoon 3 world? Take a breath man.

Thanks,
Russell
Advanced Gaming Systems
Home of Computer Harpoon
User avatar
hermanhum
Posts: 2209
Joined: Wed Sep 21, 2005 10:48 am
Contact:

Problem

Post by hermanhum »

ORIGINAL:  rsharp@advancedgamin

The option files can be disabled and have no impact.  I have no such choice here.
I don't which leaves me more aghast.  The fact that AGSI:

1) Does not see that problem at all, or
2) Sees the consequences and does not regard them as problematic

Correct me if I'm wrong.  AGSI is going to:

a) Introduce *.opt files in 394
b) Expect designers to write and test scenarios with them
c) Remove them in 3.10 (the next release)

The problem is that scenarios written with them in place are going to rely upon those modified behaviours.  There will be an impact.
ORIGINAL:  rsharp@advancedgamin

Also, a good solution presents itself in 3.10 so the issue will be handled in a way that should please everyone.  So I'm giving the issue the proper attention and I want the other players to know they are being heard.  At this point, my only puzzlement is why do you suddenly believe this is the doom of the Harpoon 3 world?
So, if there is already another 'solution' being prepared for 3.10, why not simply implement it now instead of putting something in and then taking it back out and causing all the compatibility problems?
User avatar
FreekS
Posts: 323
Joined: Fri May 12, 2006 7:50 pm

RE: Problem

Post by FreekS »

ORIGINAL: rsharp@advancedgamin

I'm not going to continue using .opt files in 3.10. I'm going to change the default ROE in 3.10 with the ability to modify it as well.

Russell,

I'm hopefull that the .opt files put in:
- maintain compatibility with scens made pre-ANW
- make 394 maybe as good as 3.6 (with different bugs in each version) with the added MP functionality. It certainly looks like the AI has regained much of its old agressiveness in making air intercepts (smaller UZ zones), and pressing attacks (target can be partly localised).

I have no objection to them being replaced by a 'better' way in 3.10 - though I hope:
- that maintains compatibility with scens made pre-ANW
- that 394 will be supported (effort made to fix bugs in it) even when 3.10 will be different again
- that the specific functionality you have in mind can be openly and publicly discussed as to try to predict issues with it.

Regards

Freek
User avatar
FreekS
Posts: 323
Joined: Fri May 12, 2006 7:50 pm

RE: Problem

Post by FreekS »

ORIGINAL: hermanhum

The 394 (Beta RC13) isn't even an official patch release and it's already too late to fix the problem.

Herman,

You complain about AGSI not being willing to change the RC13 Beta but you've not been willing to participate in the Beta testing.
Luckily its still Beta and its not too late for you to share your insights in RC13. Then you can ask to be listened to.

Freek
User avatar
hermanhum
Posts: 2209
Joined: Wed Sep 21, 2005 10:48 am
Contact:

Problem

Post by hermanhum »

ORIGINAL: FreekS
ORIGINAL: hermanhum

The 394 (Beta RC13) isn't even an official patch release and it's already too late to fix the problem.

You complain about AGSI not being willing to change the RC13 Beta but you've not been willing to participate in the Beta testing.

Luckily its still Beta and its not too late for you to share your insights in RC13. Then you can ask to be listened to.
Yup. I'm very glad that I didn't waste a second on the supposed beta testing since once a feature makes it into any Beta or Release Candidate, it can't be changed; the latest *.opt implementation being the perfect example of this.
jpkoester1
Posts: 162
Joined: Fri Jun 24, 2005 12:28 pm
Contact:

RE: Problem

Post by jpkoester1 »

Hey Russell,

could you post a "concept" of the idea that you have for 3.9.10 (maybe with mockup screenshots, etc...) including a clear definition of what the differences in unit behaviour would be regarding the different ROE-options you have in mind for 3.9.10. I think that would greatly enhance the potential for positive feedback fromm the community even before you have written the first line of code. So give us all a chance to give AGSI some feedback on your ideas before you creat facts that would be lots of work to change afterwards.

Cheers,
JP
"I cna tyep 300 wodrs per minuet"
rsharp@advancedgamin
Posts: 430
Joined: Mon Jun 19, 2006 7:39 am
Contact:

RE: Problem

Post by rsharp@advancedgamin »

Hey JP,

My solution for this has changed a bit with user feedback from this thread so I believe laying it out is certainly in order.

3.10, which has been in the works for a while, has a feature called mission parameters. This allows the user to edit several variables on a per-mission basis. The parameters control such things as airgroup size, standard submarine speed, EMCON, target priority, and other factors of doctrine. These parameters, once set, will be part of the mission data. When the scenario designer has set them they will stay set for sides played by the AI.

My solution is to take this a bit farther and allow the user to edit mission defaults (and non-mission defaults). I can find the points in the game engine that collectively define the ROE. Then I can connect those points to the mission parameters and they will be user configurable.

Now, what exactly will the user see? At the moment I'm thinking a new dialog with a list of Yes/No questions. Should a platform engage incoming missiles? Should a platform engage contacts intercepting craft on a mission they share? Etc.

So a user that is happy with or does not care about the ROE can carry on without any new dialog in his way. They will see two options, Weapons Free and Weapons Tight. Those that want a different ROE behavior can edit those two ROEs.

What will be the default settings out of the box will be up for a poll or three held on the forums. 5 or 6 people do not make a majority.

Thanks,
Russell
Advanced Gaming Systems
Home of Computer Harpoon
User avatar
noxious
Posts: 177
Joined: Fri Jun 13, 2008 12:07 am
Location: Montreal, Qc, Canuckistan

RE: Problem

Post by noxious »

What will be the default settings out of the box will be up for a poll or three held on the forums. 5 or 6 people do not make a majority.

Glad to hear you say so, as I totally don't agree bomb range calculations should be optional : they're the realistic option and should be the default.
It's about time that the inertia of hundreds of old scenarios stop being used as a reason not to change anything : a dangling, damocles sword always over the devs...
A few people are confusing their personal investment of time and skills with what's better for the sim.
If any scenario is so closely tied to a particular implementation, one might ask about the validity of the scenario in the first place (not saying that's the case, just raising a point. But, no doubt, I'll be shot down for that too: if you don't agree with Herman & co, or AGSI, you don't have a voice atm, or can't be heard for the surrounding noise)
Having bombs behave as in reality is a plus for me, and it shouldn't be an issue.
I truly hope this feature is properly developed further, with appropriate flags in the DB for high drag and other aerodynamic aspects, etc. so that bomb ranges not only vary with launch altitude, but also the flight envelope of its casing.
Whining that it makes it possible to attack from outside the SAM defense coverage is not a bug : it's modelling reality in certain cases.
Using this to underline a certain trend, or undercurrent that seem to prevail in all dealings between the community and AGSI.
I'd venture to say that now is the time to break free from the past, and not wish for wholesale backwards compatibility : the good scenarios and DBs will find loving hands to take care of them.
There is no absolute need for them to be all available in ANW from the get go, or automatically translated.
It's totally unrealistic to wish for such backwards compatibility, as a lot of those classic scenarios include numerous workarounds of their own to overcome engine limits at the time, as well as mostly undocumented DB hacks (the fact that all a/c can land on carriers in PDB was only documented, fleetingly so, by Herman when I complained about it)

Flame on if you have to.

The only way to move forward, people seem to forget, is to let go and break stuff. There is no way around that, period.
Yes, mistakes have been made, yes I'm also unhappy with the current state of ANW, but the vocal minority is taking up way too much space and polarizing the debate in a AGSI vs Them (not us) battle, where only their very personal interests are represented, not the common good as they like to think.
The argument about the hundreds of scenarios that could be left behind because of changes is passe and dead stupid when we're talking about adding realism to a game/sim... (and yes I'm going to take a ton of flak from both people I don't know and my harpoon buddies, I bet on this one ;))
You guys clamoring for backwards compatibility to boot, already have legal copies of 3.6.3, so you can play those scenarios with AI intact as much as you want.

The way it's going, you want 3.6.3 with MP. You've been told again and again, it's not going to happen.
Get over it already and let's work on the future :)

Special note to Herman : You know I like and respect you (went so far as to vote for your as Pooner of the  year, remember ?), but I'm considering reducing my very limited involvement in ANW vs public forums to nothing. I'm tired of having to wade through litteral tons of your vicious ranting to find the elusive needle of good data in the haystack (hint, more often than not, NOT in your posts nowadays)
You don't want to beta, fine, we know.
Could you stop telling us that little fact and the countless others you're so keen on repeating ? For someone who refuses to beta-test, and thus be part of the solution, your attitude makes it hard for anyone else to have any pleasure in trying to move things forward.

I know for a fact I'm not the only one who's disturbed by your incessant rantings and your co-opting if not outright derailing of most if not all threads where Russell, the only regular AGSI contact we have, shows himself around here.

With 2 or 3 guys acting like that you know what happens ? Yes, you have it on the tip of your tongue : the old situation with AGSI and ANW, with multi tiered closed betas, and a closed content management group, whatever it was called.
You want people to be responsible, in this case, show the example and start with yourself.
Or please, STFU : I also paid for ANW, and I've had enough of you holding us hostage in your vendetta against AGSI
.

Sorry for using some strong words, but I've refrained myself long enough from addressing this (litterally months)
You're not just "hurting" AGSI or Matrix with your demeanour, you're also affecting us, the community for which you so often posture as championing. [end of special note to Herman]

Food for thought, I hope.
Now, I crawl back in my hole :)
(incidentally, my hole is in no way financed by AGSI or Matrix Games, I have no vested interest, financial or otherwise, in either company, beyond wishing they keep on doing what they do ;))
Be Kind. Everyone is fighting a hard battle.
User avatar
hermanhum
Posts: 2209
Joined: Wed Sep 21, 2005 10:48 am
Contact:

Problem

Post by hermanhum »

ORIGINAL:  noxious

I totally don't agree bomb range calculations should be optional : they're the realistic option and should be the default.
It's about time that the inertia of hundreds of old scenarios stop being used as a reason not to change anything : a dangling, damocles sword always over the devs...

A few people are confusing their personal investment of time and skills with what's better for the sim.

[snip]

Having bombs behave as in reality is a plus for me, and it shouldn't be an issue.
I truly hope this feature is properly developed further, with appropriate flags in the DB for high drag and other aerodynamic aspects, etc. so that bomb ranges not only vary with launch altitude, but also the flight envelope of its casing.
Whining that it makes it possible to attack from outside the SAM defense coverage is not a bug : it's modelling reality in certain cases.
Since you chosen this feature as an example of realism, allow me to fill in a few details that you obviously are unaware.

With this new ballistic bomb drop calculation, you can have your aircraft cruise (500kts) towards the target, then instantaneously accelerate to Afterburner (1300kt) and flick-release your bombs towards the target from a distance of over 13nm.  If you think that is realistic, that's certainly your choice.  I don't know of any attack profile that allows for bombs to be delivered on afterburner, but I could be mistaken.

Another fact that seems to have overlooked is that I never complained about it.  I resigned myself to it as a new feature.  It isn't listed as a bug anywhere because it was a deliberate implementation by AGSI.  So, even though I may not have liked it, I did simply keep quiet and accepted it.

The second issue is the claim that everything must work as H3 did.  That's not quite true, either.  This thread, alone, is evidence enough. 

The problem with "6.8.2 Weapons Free or Weapons Tight" comes from the game not doing what is explicitly claimed in the ANW eManual.  It just happens to coincide with what actually worked in H3. 

Most of the complaints appear as though there is a desire to maintain status with H3 only because the H3 worked as opposed to the current situation in ANW.  If ANW actually worked (even in its own way), those complaints would likely cease.  Another example of this is the Navigator function.  It works fairly well in H3, but is unable to execute some of the most basic calculations in ANW.
User avatar
CV32
Posts: 1046
Joined: Mon May 15, 2006 4:36 pm
Location: The Rock, Canada
Contact:

RE: Problem

Post by CV32 »

ORIGINAL: hermanhum
I don't know of any attack profile that allows for bombs to be delivered on afterburner, but I could be mistaken.

Dropping bombs while using the afterburner wouldn't be the problem. Dropping them at supersonic speed might be, but even that's sometimes possible. The F-111 could (can, for our Aussie friends) do it. And I suspect you've heard that the F-22 did it fairly recently with an SDB dropped from the internal weapons bay. My contribution to the discussion, such as it is. [8D]
Brad Leyte
HC3 development group member for HCE
Author of HCDB official database for HCE
Harpgamer.com Co-Owner
User avatar
hermanhum
Posts: 2209
Joined: Wed Sep 21, 2005 10:48 am
Contact:

Problem

Post by hermanhum »

Looks like another *.opt file  [:D]

AussieF-111SupersonicBombDrop.opt
User avatar
FreekS
Posts: 323
Joined: Fri May 12, 2006 7:50 pm

RE: Problem

Post by FreekS »

ORIGINAL: noxious

Having bombs behave as in reality is a plus for me, and it shouldn't be an issue.
I truly hope this feature is properly developed further, with appropriate flags in the DB for high drag and other aerodynamic aspects, etc. so that bomb ranges not only vary with launch altitude, but also the flight envelope of its casing.
Whining that it makes it possible to attack from outside the SAM defense coverage is not a bug : it's modelling reality in certain cases.

Noxious,

I have requested Russell to make the alternate bomb ranges optional and not default not because they break scens, but because they are unrealistic. Basically at vLow ans Low alt the bomb range should be 0nm (allowing point defense guns to bear on the attacking plane). Today they cannot be set lower than 2nm. Likewise at vHigh/burner they are 12nm which is way longer than ballistic and also does not give an immense penalty in Pk (as far as I know).

If the feature is developed further to realistic ranges and Pks linked to altitude and speed as well then I'm fine with the feature. And anyway, you can still switch it on if you want to in 394.

Tested drop ranges of bombs.
>> Vulcan and 454kg bomb (nominally 2nm in DB)
>>
>> alt speed range
>> ----------------------------------------
>> 31m 580 (cruise) 2nm
>> 2001m 570 (cruise) 3nm.
>> 7501m 560 (cruise) 5nm
>> 19810m 543 (cruise) 8nm
>>
>> and these:
>> F16 990knots (burner), vHigh alt: 12nm
Note the RL Vulcan attack on Stanley was made from 10000ft (3000m) with 2nm forward drop of the bombs.

Freek
User avatar
hermanhum
Posts: 2209
Joined: Wed Sep 21, 2005 10:48 am
Contact:

Problem

Post by hermanhum »

ORIGINAL:  rsharp@advancedgamin

3.10, which has been in the works for a while, has a feature called mission parameters.  This allows the user to edit several variables on a per-mission basis.  The parameters control such things as airgroup size, standard submarine speed, EMCON, target priority, and other factors of doctrine.  These parameters, once set, will be part of the mission data.  When the scenario designer has set them they will stay set for sides played by the AI.

My solution is to take this a bit farther and allow the user to edit mission defaults (and non-mission defaults).  I can find the points in the game engine that collectively define the ROE.  Then I can connect those points to the mission parameters and they will be user configurable.  

Now, what exactly will the user see?  At the moment I'm thinking a new dialog with a list of Yes/No questions.  Should a platform engage incoming missiles?  Should a platform engage contacts intercepting craft on a mission they share? Etc.

So a user that is happy with or does not care about the ROE can carry on without any new dialog in his way.  They will see two options, Weapons Free and Weapons Tight.  Those that want a different ROE behavior can edit those two ROEs.

There seems to be a lot of interesting new ideas in this new mission parameter setup.  It also share some of the limitations faced by the *.opt arrangement.  Overall, it is good to see that individual settings can be specific to each side and mission.

Some concerns that come to mind with the issue of parameters are:
  • The Map Pref window is a good dialogue example.  Instead of a Yes/No question, a simple checkbox is sufficient.
  • Once a parameter is set, it is good to see that is should stay set according to side and mission.  This is, IMO, superior to the *.opt arrangement which sets (or re-sets) a behaviour globally for an entire scenario.
  • With all these new parameters, the user is probably going to need more information on his Map.  For example, if planes can have both Weapons Free and Tight settings, he is going to need to quickly differentiate between them on his tactical display without the necessity of constantly calling up Preference menus.
  • How are parameters to be determined when none are initially present?

    This problem will be common to all pre-3.10 scenarios.

    One possible solution is through the use of a file such as MissionDefaultWeaponsFree370.opt (included with the 394 patch).  This file re-sets all sides to Weapons Free when the Battleset Re-build command is issued.  The problem with this file is that it is indiscriminate and it overwrites some scenarios that might actually need to start with Weapons Tight.  Also, a file such as this has no specific value setting that might need to be associated with future parameter (i.e. airgroup size).  I think that this process could work so long as there is an initial check like, "Do not overwrite parameter if pre-existing parameter is present."
  • Storage of scenario parameters

    A major concern voiced over the use of *.opt files was that they are global in nature.  With many users each having their own personal parameters multiplied by the potential for different specific parameters between individual scenarios, this is a daunting obstacle.  I think that a mechanism already exists in the form of the Weapons Edit Export function.  This function saves all the specific ammo loadouts for every scenario and is truly a powerful tool.  Although it took two years to become fully functional with Patch 3.9.0, it serves its purpose admirably.

    If mission parameters could be viewed  in the same manner as 'ammo loads' within a scenario, then this command could be used to export those settings to a file not unlike the current *.sem files.  In this way, all settings could be preserved as new patch versions are released without fear of any settings being lost.  This ensures compatibility in the long-term.  Once a setting is determined, it stays set until the author decides to change it.

    Also, instead of just having the various *.opt files appearing in the message log when a scenario is loaded, the message could also display the parameters that the scenario was originally written under.  This way, every user can know if he is playing it in the manner originally intended by the author.  He can always ignore them (i.e. activate nukes in a scen meant for conventional arms), but at least he will see what the original settings were.  This would sure satisfy all parties equally and allay any fears of mis-matched settings while continuing to respect individual player wishes.
ORIGINAL:  rsharp@advancedgamin

What will be the default settings out of the box will be up for a poll or three held on the forums.  5 or 6 people do not make a majority.
Unless they are called a CCC... [8|]
rsharp@advancedgamin
Posts: 430
Joined: Mon Jun 19, 2006 7:39 am
Contact:

RE: Problem

Post by rsharp@advancedgamin »

Current Implementation
Currently the mission parameters will be edited, imported, and exported using ini format files. There a set number of mission profiles (a group of mission parameters) that define the default settings for the different sorts of missions you are familiar with. i.e. ASW Patrol, Ground Strike, Electronic Support, etc. The user will be able to make their own mission profiles and optionally inherit a default mission profile. This inheritance means the new profile uses all the default parameters and allows the editor to override which parameters she wants. Then, in the mission editor, they can select that new profile from a drop-down list.

Backwards Compatibility
The mission parameters available so far do not overlap with the mission options available in the mission editor. They do affect them however. For example, in ANW the focused strike flag changes the maximum airgroup size from 4 to 24. There is now a mission parameter to set both the normal airgroup size and the airgroup size for focused strike missions.

To the heart of the backwards compatibility issue is how to apply this new feature to older scenarios. What I believe will solve it is to allow the editors to edit the actual mission default profiles for themselves. Then on import, the older missions will have these default profiles applied to them as normal. The mission parameters are saved with the mission data in the scenario file (.SCN) so once imported, it is there until the mission is deleted by the game or user.

For ROE
What I'm considering as well is exposing a limited number of these in a preference dialog. The limited number of exposed parameters would be the ones used to define what is Weapons Free and Weapons Tight. Since these are simple yes/no decisions (checkbox is pretty much standard for such), I feel any player (noob or vet) can handle them easily without digging through text files. These settings would apply to any craft on a human controlled side on any mission according to which of the two ROEs are set.

But will it work?
This feature is not only a scalpel, it is a chainsaw with laser beam teeth with shark teeth on the end of each laser tooth. I assure you houses will be burned and the wrong limbs amputated before your first try is complete. It will take at least a few iterations and possibly different implementations before we get it right. It will give the editors that dare access to inner workings of the missions. When this design is firm and tested I will provide examples of different mission profiles to demonstrate what they can do and provide some popular behaviors.

The best case is a feature 95% of the users do not use but all enjoy. The worst case involves super Godzilla with that chainsaw knocking on your door in the early morning to sell you magazines.
Russell
Advanced Gaming Systems
Home of Computer Harpoon
rsharp@advancedgamin
Posts: 430
Joined: Mon Jun 19, 2006 7:39 am
Contact:

RE: Problem

Post by rsharp@advancedgamin »

On the launch range behavior for bombs, I'll cover that in another thread.

Thanks,
Russell
Advanced Gaming Systems
Home of Computer Harpoon
User avatar
FreekS
Posts: 323
Joined: Fri May 12, 2006 7:50 pm

RE: Problem

Post by FreekS »

ORIGINAL: CV32

Dropping bombs while using the afterburner wouldn't be the problem. Dropping them at supersonic speed might be, but even that's sometimes possible. The F-111 could (can, for our Aussie friends) do it. And I suspect you've heard that the F-22 did it fairly recently with an SDB dropped from the internal weapons bay. My contribution to the discussion, such as it is. [8D]

Brad,

In H3/ANW the SDB bomb, which is a guided bomb would be modelled (I believe) in the same way that the LGB precision munitions are. The drop distance of LGB in RC13 does not depend (I believe) on speed/altitude. Only Iron bombs have this optional functionality.

Freek
User avatar
hermanhum
Posts: 2209
Joined: Wed Sep 21, 2005 10:48 am
Contact:

Problem

Post by hermanhum »

ORIGINAL: rsharp@advancedgamin

Current Implementation
Currently the mission parameters will be edited, imported, and exported using ini format files. There a set number of mission profiles (a group of mission parameters) that define the default settings for the different sorts of missions you are familiar with. i.e. ASW Patrol, Ground Strike, Electronic Support, etc. The user will be able to make their own mission profiles and optionally inherit a default mission profile. This inheritance means the new profile uses all the default parameters and allows the editor to override which parameters she wants. Then, in the mission editor, they can select that new profile from a drop-down list.

[snip]

To the heart of the backwards compatibility issue is how to apply this new feature to older scenarios. What I believe will solve it is to allow the editors to edit the actual mission default profiles for themselves. Then on import, the older missions will have these default profiles applied to them as normal. The mission parameters are saved with the mission data in the scenario file (.SCN) so once imported, it is there until the mission is deleted by the game or user.
I want to know if I understand the situation correctly. I believe that if I, as the editor of the PlayersDB, load up the Scenario Editor, I will do so with my personal set of parameters since they are saved in my Harpoon.ini file.

If I want to re-build all 300 scens made for the PlayersDB, I will then be setting all their parameters to match my personal settings. If we have 10 different authors with scenarios written for the Players DB, the only way to preserve the individual author settings for their groups of scenarios is to run the Re-build Battleset command 10 separate times and change the parameters in between runs. Is this how it would work or am I missing something?

Secondly, would I physically need to load each scenario individually, set the mission parameters for it, then re-save that file before doing the next one or could this be handled with a Batch re-build function? This is because each scenario (or group of scenarios) might have their own particular mission settings.
Post Reply

Return to “Harpoon 3 - Advanced Naval Warfare”