ROE and Automated Defense (Full Version)

All Forums >> [Current Games From Matrix.] >> [Modern] >> Harpoon 3 - Advanced Naval Warfare



Message

rsharp@advancedgamin -> ROE and Automated Defense (2/15/2009 11:33:56 PM)

Howdy,

I'm starting this thread to continue a discussion on the logic of Harpoon platforms engaging hostile units. Specifically, automated defense and the ROE settings.

From FreekS:
quote:

The 3.6 AI had a more sophisticated 'Weapon Tight' behaviour than most people think.

Namely the Players units would defend themselves against incoming missiles (so ships would fire SAM at incoming SSM) but it would NOT fire on SSMs aimed at other ships. This ensured that ships would defend themselves, but avoided lots of missiles fired at 'crossing targets' with poor Pk.
I was therefore quite safe to play constantly with Weapons Tight. I would have the advantage of self defense plus minimised expenditure of SAMs, no automatic firing on unarmed or low-threat targets in Weapons Tight mode, and I could close helo's or planes and kille them with sidewinder or guns and save my long range AMRAAM, for example. When things got hot it was little trouble to switch to Weapons Free and all other ships in my Task Force would start firing.

I'm not sure which group of people was unhappy with this bahaviour, but I submit that the discussion was probably not based on the true facts; there were statements made like 'of course you want your units to defend themselves' probably not realising that they did!

So when considering the new Weapons Tight/Weapons Free functionality; I'd request that this sophisticated Weapon Tight But Maintain Real Self-Defense is considered.
I have nothing against making this new Weapon Tight/Weapon Free behaviour configurable; but lets realise that the more configurable options; the more likely it is that players have them set up in ways that scen designers did not foresee. So the fewer options the better.


From Me:
quote:

Micromanagement and auto-defen(c|s)e
Within reason, the user should be allowed to play the game how they like. I'm not going to change the default behavior of the game because that gets us back where we started with a different group of people unhappy. What I'm going to do is the following:

Allow the user to configure the AI response. The user will be able to set some parameters to define how the game will design attacks. i.e. How many attacks to assign to an incoming missile.
Introduce new ROE sets. Weapons Really Free and Weapons Really Tight will be added to the current ROE sets of Weapons Tight and Weapons Free. Weapons Really Tight will only engage targets ordered by the player.
Allow the user to configure the default ROE.



rsharp@advancedgamin -> RE: ROE and Automated Defense (2/15/2009 11:51:27 PM)

Freek,

So the user will be able to configure the ROE defaults. I understand that this will have an impact on scenario design. We can mitigate the impact of the complexity on the user and scenario design with a few factors.

Allow the user to edit the default ROE parameters (as stated above). This means they can, if they want, set it once and forget.
The default settings only impact the player controled units.

Thanks and keep it coming.



jkruny -> RE: ROE and Automated Defense (2/16/2009 12:53:54 AM)

Rusty

For my part, I do agree with Freek, there is nothing more frustrating than a unit wasting SAMs on a doomed unit for instance.

Perhaps there would be a way to make individual units engage only attacks aimed at them, while grouped units would have a co-operative defense of sorts? This would allow you to detach peripheral units from a group to defend themselves and allow your group to still defend the HVUs.

Configurable ROEs therefore would have to apply seperately to units v groups to do it absolutely right, although a single selection for the player side would not bother me. I thought Classic at one time in the remote past had an option to select SAM rate of fire?

Please keep up the good work, many of the recent options are very encouraging.



FreekS -> RE: ROE and Automated Defense (2/16/2009 8:24:18 AM)


quote:

ORIGINAL: rsharp@advancedgamin

Freek,

So the user will be able to configure the ROE defaults. I understand that this will have an impact on scenario design. We can mitigate the impact of the complexity on the user and scenario design with a few factors.

Allow the user to edit the default ROE parameters (as stated above). This means they can, if they want, set it once and forget.
The default settings only impact the player controled units.

Thanks and keep it coming.


Russell,

I'm sure it will be possible to create user configurable ROE; for example through the .opt files.

However I have a few concerns

1. Complexity
ANW today has two levels of Weapon Free/Weapon Tight; namely on each side (Settings/Game Preference menu) and on each mission (Mission Editor menu). No combination of these delivers a situations where planes and SAMs do not autodefend (as most players micromanage with Plotted-missions). Adding a .opt file may well achieve this but it adds a level of complexity for no apparent benefit to me. Most players/designers (including me) probably don't understand what each of these two Weapon Tight levels do (or have not noticed them!).

2. Current Scens
I'm concerned about the work to reconfigure current scens. Once I've made a scen, its very hard to go back to it, as each scen is full of complex TOT attacks, side postures, missions with time delays and vicconds that are very hard to actually remember or 'see' inside the scen. So my concern is that the 300 or so scenarios available to players won't all work and that it will be so much work to test ech scen and if needed modify it that that will not be done.

3. Players setting .opt options in different ways.
I suspect that once a scen has been designed with one set of .opt options enabled on the designers PC, he (or she) is unlikely to review the potential impact of players playing with different settings. Now I suspect that in many cases there is no 'right' setting but that having a setting different from the designer may make scen unplayable.

Example: MissionPatrolRestrictedZone.opt

Having this .opt enabled will allow (for example) fighters to patrol a small area (PZ), intercept planes in a larger area (the pursuit radius, PR) but not exit the pursuit radius. If a designer uses this well (small, PU, large overlapping PRs) then it has obvious advantages (fighters defending an area but staying out of range of a SAM unit for example).
But if a designer disables it (as I have so far) and uses the disabled setting well (small PU counting on fighters going well outside these) than it also works well as fighers will intercept enemies far away, yet come bak to PU.
So both .opt 'enabled' as well as 'disabled' will work if the designer had the same setting when he designed the patrol area's.
However if a player enables MissionPatrolRestricted.opt when the designer had designed the scen with it disabled then suddenly the AI air patrols are limited to very small area's with big holes in the air defense for enemies to pass through.
So I suspect that when 394 comes out, there will be lots of discussion over 'recommended' sets of settings for each designer or scen. And more opportunity for errors or mistakes.

Freek



incredibletwo -> RE: ROE and Automated Defense (2/16/2009 1:03:08 PM)

Why not just change it back to the way it was in Harpoon 2/3? "Weapons Tight" is just that: nothing fires anything (except last-ditch systems like CIWS) without the player doing so. "Weapons Free" is open up with all you got at everything hostile.
I personally don't think a .opt file is necessary. As Freek said, it'll just complicate things way too much.
[sm=Evil-210.gif]



rsharp@advancedgamin -> RE: ROE and Automated Defense (2/16/2009 11:06:01 PM)

The problem with 'just change it back' is that there are scenarios designed for the current behavior. I'm not going to break one group to fix another. Like I said, there's no rewinding this sort of project.

Freek,

I'll read over your post later and give it the response it deserves.

Thanks



FreekS -> RE: ROE and Automated Defense (2/16/2009 11:11:30 PM)

Russell,

All my scens (and all PDB scens) will work with 3.6 behaviour. I believe without exceptions they are being maintained in 3.6 and rebuilt for each new GE or PDB version.
I believe that the .opt behaviors, the new land unit damage model, the autodefense behaviour of ANW are also making many previously designed scens not working as designed.
I would prefer to have the 3.6 ROE back - especially as I've never really heard a good rationale for changing it.

Freek



rsharp@advancedgamin -> RE: ROE and Automated Defense (2/17/2009 2:01:37 AM)

Jeff,

There actually is cooperative defense based on a unit's mission. If the contact is intercepting any unit, every unit on that mission is concerned. One will be selected to engage the contact. I think this gives you some control.

Freek,

I'm considering any such change to be included with 3.10. The ROE options would not be using .opt files but user selectable on a per mission basis like the current ROEs. This means the option is saved in the scenario itself.

This idea is very much in the design stage but I have laid out some requirements such as the per-mission option. The details of the implementation will depend on the feedback from here.

Thanks,



hermanhum -> Problem (2/18/2009 10:06:52 AM)

This is how H2/H3 originally worked and how ANW was supposed to work:

quote:

ORIGINAL:  ANW Manual

6.8.2 Weapons Free or Weapons Tight

There is an option in the Game Preferences dialog window under the Settings menu that determines whether or not your units will fire on enemy air targets independently. Weapons Free allows units under your command to engage independently and Weapons Tight prevents units under your command from firing without orders from you. The default setting on Harpoon 3TM is Weapons Free. When Weapons Tight is selected it will be up to you, the user, to engage incoming air and missile targets. It is important to note that Weapons Tight is only respected by units that are unassigned or on plotted missions. Units on other missions or out of comm range will always behave as if the Weapons Free option is selected.

Words like simple, basic, and elegant come to mind when describing this H2 feature.  Unfortunately, ANW was released with this option no longer available to the player.  The game would always operate as Weapons Free all the time in All instances.

Instead of simply removing it early and thereby rectifying the situation, AGSI tried all manner of jury-rigged repairs and modifications in vain attempts to bolster and prop up this unworkable state of affairs with every iteration significantly exacerbating the situation.

quote:

ORIGINAL:  rsharp@advancedgamin

The problem with 'just change it back' is that there are scenarios designed for the current behavior. I'm not going to break one group to fix another. Like I said, there's no rewinding this sort of project.

Emphasis added by HH


This explanation is simply untenable and makes absolutely no sense, whatsoever.

  • Weapons Tight is for human control, only.  The AI should always be operating under Weapons Free and thus be wholly unaffected.  Therefore, scenarios could not have been designed for WeaponsTight since it is entirely a human function.
  • Many ANW customers are former players who enjoyed H2/3 and are now returning to the game.  They remember how H2/3 ran and are looking for ANW to offer something similar.  This "AI controls everything" is not what they expected.  The two most recent examples are from incredibletwo and kondor999.
  • The argument presented by AGSI is outright contradictory to actions already undertaken by AGSI regarding the Doomed ground units.   Credit needs to be given when credit is due and AGSI was absolutely right to reverse this bad implementation.

    The revised Land Damage model (Doomed Ground units) was introduced with Patch 3.9.0 on March 25, 2008.  Over 50 ANW scenarios have been written since that time.  This Land Damage model has since been removed in the 3.9.4 RC13 Beta release.  Removal of this (bad) feature will likely affect the 50 scenarios written since the function was initially introduced.  It is neither fair nor reasonable for AGSI to make this preservation argument only when it is convenient for AGSI to do so.  Bad behaviour needs to be removed wherever it is found.  The same level of decisiveness is needed to remove the Weapons Tight / RoE changes.

AGSI has spent considerable time and effort implementing their new RoE behaviour.  They can continue to spend an additional significant number of hours trying to make their new rules work.  Or, they can spend that same (or fewer, probably) number of hours simply taking it out and restoring the previously functional state.  (Like removing the "Doomed Land Unit damage model".) Users tried desperately to save AGSI the pain, time, and expense of this bad implementation early on.  Unfortunately, they were ignored.  The only real choice seems for AGSI to 'bite the bullet' and fix the game properly.  When relative (returning) 'noobs' like incredibletwo and kondor999, along with the other veteran players and designers, can see the obvious solution why can't AGSI?




FreekS -> RE: Problem (2/18/2009 1:19:15 PM)

We seem to be having a rare level of agreement between the players/designers/DBeditors in this thread. Any more views?

Freek



rsharp@advancedgamin -> RE: Problem (2/18/2009 4:26:42 PM)

quote:

The argument presented by AGSI is outright contradictory to actions already undertaken by AGSI regarding the Doomed ground units. Credit needs to be given when credit is due and AGSI was absolutely right to reverse this bad implementation.

The revised Land Damage model (Doomed Ground units) was introduced with Patch 3.9.0 on March 25, 2008. Over 50 ANW scenarios have been written since that time. This Land Damage model has since been removed in the 3.9.4 RC13 Beta release. Removal of this (bad) feature will likely affect the 50 scenarios written since the function was initially introduced. It is neither fair nor reasonable for AGSI to make this preservation argument only when it is convenient for AGSI to do so. Bad behaviour needs to be removed wherever it is found. The same level of decisiveness is needed to remove the Weapons Tight / RoE changes.


Wrong. I did not remove the land damage model or reverse it to some previous state. The only change was that facility units (not runways) dealt damage equal or greater than their damage point capacity were immediately checked for destruction (100% chance to be destroyed at 100% damage).

This tweak was simple. The only 'feature' I've pulled was the alternate bomb ranges and I made that the non-default option. I have no such choice here.

Thanks and keep it coming,



hermanhum -> Problem (2/18/2009 6:29:48 PM)

quote:

ORIGINAL: rsharp@advancedgamin

quote:

The argument presented by AGSI is outright contradictory to actions already undertaken by AGSI regarding the Doomed ground units. Credit needs to be given when credit is due and AGSI was absolutely right to reverse this bad implementation.

The revised Land Damage model (Doomed Ground units) was introduced with Patch 3.9.0 on March 25, 2008. Over 50 ANW scenarios have been written since that time. This Land Damage model has since been removed in the 3.9.4 RC13 Beta release. Removal of this (bad) feature will likely affect the 50 scenarios written since the function was initially introduced. It is neither fair nor reasonable for AGSI to make this preservation argument only when it is convenient for AGSI to do so. Bad behaviour needs to be removed wherever it is found. The same level of decisiveness is needed to remove the Weapons Tight / RoE changes.


Wrong. I did not remove the land damage model or reverse it to some previous state. The only change was that facility units (not runways) dealt damage equal or greater than their damage point capacity were immediately checked for destruction (100% chance to be destroyed at 100% damage).

This tweak was simple. The only 'feature' I've pulled was the alternate bomb ranges and I made that the non-default option. I have no such choice here.

How typical of AGSI: latching onto a salient point in order to be 'right'. The bottom line is the resultant behaviour is the same -- Units disappear after being destroyed. Whether or not AGSI had to tear out whole chunks of code to do it or simply change a single value is totally irrelevant.

Since AGSI has chosen to avoid the crux of the matter, I'll re-iterate.

When is AGSI going to fix the Weapons Tight command so that it works the way it is described in their manual?

quote:

ORIGINAL: rsharp@advancedgamin

Thanks and keep it coming,

There's no point to 'keeping it coming'. It's pretty obvious that AGSI won't fix anything that isn't convenient for them. Your users told you 3 years ago of this problem when it was convenient to fix. Instead, AGSI insisted on following this road. So, who's fault is it that this is no longer convenient to fix?



rsharp@advancedgamin -> RE: Problem (2/18/2009 7:29:23 PM)

quote:

When is AGSI going to fix the Weapons Tight command so that it works the way it is described in their manual?


3.10.

More feedback and concrete examples are always welcome.

Thanks,



FreekS -> RE: No going back (2/18/2009 9:11:21 PM)


quote:

ORIGINAL: rsharp@advancedgamin

I have no such choice here.

Thanks and keep it coming,


Russell, you keep saying we cannot go back to 3.6 code.

What I'm not clear about is if there is any real demand for other functionality on Weapons Tight/Weapons Free than what was included in 3.6. I believe the side-based Weapons Tight bahaviour in ANW is generally felt to do auto-defense with too little player control, and I also believe nobody is using the Mission based Weapons-Free checkmark in scens.

What am I missing?

I may be wrong and I'd like to understand this and keep the discussion on player input on the level of functionality desired.
How its implemented (and of course final say of what is implemented) and in which future release is up to AGSI.

Freek



rsharp@advancedgamin -> RE: No going back (2/19/2009 12:09:36 AM)

Freek,

I do use the Weapons Free ROE for missions but that's irrelevant as I don't really take how I play into consideration for any design choices. When I say that there is no rewinding, I mean, I cannot make the code do what it used to because too many other factors have changed since 3.6. Additionally, if changing the behavior started all of this, then changing it again (not back but something else) will lead us to a different mess. If there was a switch I could throw that would change the behavior then I believe I proven that I would throw it.

What we will get is an aproximation of 3.6 behavior. The posts here, especially yours, have detailed where the differences are between the versions. This will lead to users having more choice and the choice to ignore the choices. But the users will get what they want. It will not happen overnight. I have a solution in mind for 3.10.

Thanks,



hermanhum -> Problem (2/19/2009 2:23:36 AM)

quote:

ORIGINAL:  rsharp@advancedgamin

When I say that there is no rewinding, I mean, I cannot make the code do what it used to because too many other factors have changed since 3.6. Additionally, if changing the behavior started all of this, then changing it again (not back but something else) will lead us to a different mess. If there was a switch I could throw that would change the behavior then I believe I proven that I would throw it.

What we will get is an aproximation of 3.6 behavior. The posts here, especially yours, have detailed where the differences are between the versions. This will lead to users having more choice and the choice to ignore the choices. But the users will get what they want. It will not happen overnight. I have a solution in mind for 3.10.

I'm seeing a pattern of AGSI behaviour.

2006
1. ANW Officially Released with WeaponsTight function nullified and no prior notification of this drastic change
2. Complaints pour in
3. AGSI response is, "It's too late to change.  Deal with it."

Fast foward to 2009
4. ANW releases New *.opt files to deal with WeaponsTight/Mission RoE problems
5. Reservations are reported
6. AGSI response is, "It's too late to change.  Deal with it."

There doesn't seem to be any point in giving any feedback.  It's always after the fact (the new functions are already released) and nothing changes.  The SS AGSI just sails wherever she darned well pleases and leaves hapless users to deal with fitting their round pegs into the (newly) formed square holes as best they can.

Freek and Ralf both expressed very valid reservations on the use of *.OPT files, IMO.  

quote:

ORIGINAL:  FreekS

3. Players setting .opt options in different ways.

I suspect that once a scen has been designed with one set of .opt options enabled on the designers PC, he (or she) is unlikely to review the potential impact of players playing with different settings. Now I suspect that in many cases there is no 'right' setting but that having a setting different from the designer may make scen unplayable.

ORIGINAL:  koelbach

Complexity can be killing: How will we discuss scens in the future when we have hundreds (just look at the math evolving from the opt-files) of possible combinations, leading to different game play?

Since scenarios are well calibrated to a certain AI behaviour, they only work correctly with ONE setting.

I totally agree with them.  Use of the *.OPT file is likely another bad implementation and is going create as many problems as it solves due primarily to differences between the various players', editors', and the scenario designers' settings.  Yet everyone is told by AGSI that *.OPT files  is how things are going to be handled. 

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

So, I'll ask again, what's the point when the answer from AGSI is inevitably, "Do the best you can with the new functions/features we putting out.  That is all."



rsharp@advancedgamin -> RE: Problem (2/19/2009 2:29:55 AM)

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.

But rant on Herman.

Thanks,



hermanhum -> Problem (2/19/2009 3:15:06 AM)

quote:

ORIGINAL: rsharp@advancedgamin

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

But rant on Herman.

Good to see the same old AGSI around. Some might have (mistakenly) thought that AGSI had really changed. Thanks for proving them otherwise.

I can't wait to find all the new buggy behaviour in 3.10 and I'll be certain to point them all back to this thread.



rsharp@advancedgamin -> RE: Problem (2/19/2009 3:27:09 AM)

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.

The only one that has not changed is you Herman.

Still, I welcome all feedback because I know you like to have the last post.

If anyone has more to say on the differences between 3.6 and ANW behavior, please add it to the conversation. Don't let the usual bickering derail any such attempts.

Thanks!



hermanhum -> Problem (2/19/2009 3:38:30 AM)

quote:

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.

quote:

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 -> RE: Problem (2/19/2009 3:51:58 AM)

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,



hermanhum -> Problem (2/19/2009 5:11:01 AM)

quote:

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 -> RE: Problem (2/19/2009 5:43:41 AM)

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,



hermanhum -> Problem (2/19/2009 8:06:12 AM)

quote:

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.

quote:

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?



FreekS -> RE: Problem (2/19/2009 8:19:49 AM)


quote:

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



FreekS -> RE: Problem (2/19/2009 8:43:28 AM)


quote:

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



hermanhum -> Problem (2/19/2009 11:06:07 AM)

quote:

ORIGINAL: FreekS

quote:

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 -> RE: Problem (2/19/2009 3:01:56 PM)

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



rsharp@advancedgamin -> RE: Problem (2/19/2009 4:59:50 PM)

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,



Page: [1] 2   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
1.716797