Return To Base bugs

Matrix Games Forums

Forums Register Login Photo Gallery Member List Search Calendars FAQ

My Profile Inbox Address Book My Subscription My Forums Log Out

Return To Base bugs

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [Current Games From Matrix.] >> [Modern] >> Harpoon 3 - Advanced Naval Warfare >> Harpoon 3 ANW Support >> Return To Base bugs

Page: [1]

Message

<< Older Topic Newer Topic >>

Return To Base bugs - 5/27/2008 2:43:04 AM

KlubMarcus

Posts: 41
Joined: 10/5/2006
Status: offline

Aircraft returning to base ignore threat zones and end up getting shot down. Aircraft returning to base go back to flying default low altitude even after they are told to fly high altitude and end up getting shot down. So stupid.

Post #: 1

RE: Harpoon - 5/27/2008 7:16:59 AM

hermanhum

Posts: 2209
Joined: 9/21/2005
Status: offline

quote:

ORIGINAL: KlubMarcus

Aircraft returning to base ignore threat zones and end up getting shot down. Aircraft returning to base go back to flying default low altitude even after they are told to fly high altitude and end up getting shot down. So stupid.

I've checked and re-checked all the various manuals right back to H2 and cannot find any reference as to how aircraft should behave when they return to base after the completion of a mission with respect to Nav Zones. However, since the very beginning, aircraft have always ignored Nav Zones on their return to base. I think that most Harpoon players have long regarded this behaviour as normal and expected.

I agree that:

1) aircraft ignoring Nav Zones while returning to base, and
2) aircraft returning to base at low altitude

are examples of bad behaviour. However, I disagree that they are necessarily bugs.

I think that the game was designed that way so the aircraft can get back to base in the most efficient manner possible once their mission was complete. In all likelihood, this was probably done to simplify fuel calculation matters and navigational concerns in order to ensure the planes returned. Period. In this case, I believe that the original designers accomplished this very nicely and that this function works well over the 90% percentile. I believe that I have only ever encountered one instance of a plane running out of fuel while returning to base in all the thousands of games I've run. This puts it very high on my personal list of things that work.

However, if they try to change the behaviour to what you would like to see (i.e. planes fly identical ingress and egress routes), I can foresee all kinds of problems arising such as:

a) planes running out of fuel from miscalculations
b) planes running out of fuel because they had to go to afterburner to evade a missile
c) planes unable to plot a return path
d) planes unable to plot a return path because the player introduced a new nav zone after the mission launched
e) planes wrongly penetrating Nav Zones and then getting stuck/hung on/within them and unable to plot return path
f) incredible (and possibly prohibitive) CPU consumption as the GE attempts to track all the new fuel variables

I have posted an example of what might happen. Planes will launch from the Blue base to attack RAF Flyingdales and the path is shown. Two aerial nav zones [red] have been entered to help the strike avoid the SAMs at Bergen base and to ensure that the strike attacks from behind the base. This is pretty common practice in PlayersDB scenarios.

If the new feature is implemented, I think that the strike planes may:

1) Accidentally breach one of the nav zones. once inside, they can't get out and crash
2) Can't navigate a proper return path and will simply loiter over the target until they are shot down or run out of fuel
3) May get hung up on one of the other Blue/Green nav zones

AGSI has had a most difficult time trying to implement new features. I cannot think of many new ANW features that have not resulted in serious unwanted consequences (ofttimes disastrous ones). In fact, the game has enough problems calculating navigation paths in its current state. You can see by the number of navigator issues currently listed:

Plane ignores Nav Zone

Nav Zones re-set by mission editor

Planes jammed against Nav Zone

NAV improperly drawn

Ships are unable to navigate around ice

Helos violate NAV zone

Unable to plot path around NAV zone

IMO, to request this additional feature is like throwing a handful of bullets into a bonfire. Be careful what you wish for.

Attachment (1)

_____________________________

(in reply to KlubMarcus)

Post #: 2

RE: Harpoon - 5/27/2008 5:56:20 PM

Shemar

Posts: 205
Joined: 1/25/2008
Status: offline

There are two types of 'return to base'. The one where a plane will get to bingo fuel and turn back to base and the one where a player manually gives the 'return to base' command or the plane's mission is complete without the plane being in a critical fuel situation.

For the reasons Herman described above, attempting to change the bingo fuel 'return to base' would probably be a bad idea. It will create a whole lot of additional CPU load for very little benefit.

However with the non fuel critical 'return to base', the plane could attempt to plot a return path respecting nav zones, current altitude and current speed (in that order i.e. preferring to obey nav zones over altitude and speed and altitude over speed). Since all the calculations only occur once it is no different than most other flight operations.

Having said that, I agree that this is not fixing a bug, it is introducing a new feature.

(in reply to hermanhum)

Post #: 3

RE: Harpoon - 5/27/2008 6:30:51 PM

hermanhum

Posts: 2209
Joined: 9/21/2005
Status: offline

quote:

ORIGINAL: Shemar

Since all the calculations only occur once it is no different than most other flight operations.

This is inaccurate. Referring to the previously attached example in (http://www.matrixgames.com/forums/fb.asp?m=1815878), if an AEgis destroyer was detected at the same position as the S164 unit, the player might very well decide to change the Blue/Green Nav Zones currently in the area into Red ones to prevent his aircraft from entering them. The change would compel the AI to re-calculate the path and fuel cost.

If the Nav Zone change was made before the strike flew past them the first time, it would be easier. However, it might also occur after the strike planes are already past the DDG or the DDG moves into the position after the strike planes have passed.

_____________________________

(in reply to Shemar)

Post #: 4

RE: Harpoon - 5/27/2008 7:21:29 PM

CV32

Posts: 1046
Joined: 5/15/2006
From: The Rock, Canada
Status: offline

quote:

IMO, to request this additional feature is like throwing a handful of bullets into a bonfire. Be careful what you wish for.

You need another analogy, H. This one is a myth (and a pet peeve of mine). See SAAMI - Sporting Ammunition and the Firefighter

_____________________________

Brad Leyte
HC3 development group member for HCE
Author of HCDB official database for HCE
Harpgamer.com Co-Owner

(in reply to hermanhum)

Post #: 5

RE: Harpoon - 5/27/2008 7:46:59 PM

Shemar

Posts: 205
Joined: 1/25/2008
Status: offline

So, if a player decides to change the nav zones, at the same time as aircraft are returning to base, something extremely rare, then you will have the recalculation twice insrtead of once. Something the engine already does for all other aircraft not currently in 'return to base' mode anyway. Still an insignificant CPU load. If the engine recalculates all flights when nav zones change, then doing so for the 'return to base' a/c is no different than for any other airborne a/c.

Generally any calculation that does not occur continuosly but only after a specific event or trigger (such as player input or a mission being complete) could not add any CPU load that a modern computer could not easily handle.

A simple way for the engine to handle it would be to just put the aircraft in a regular "go to" mode towards the base, instead of putting it in 'return to base' mode. That way there would not be anything different about the plane's flight to base than any other flight on the map. If while returning to base it gets to bingo fuel it switches to 'return to base' in a straight line mode, just like any other airborne unit would.

< Message edited by Shemar -- 5/27/2008 8:04:14 PM >

(in reply to hermanhum)

Post #: 6

RE: Harpoon - 5/28/2008 1:28:21 AM

hermanhum

Posts: 2209
Joined: 9/21/2005
Status: offline

quote:

ORIGINAL: Shemar

So, if a player decides to change the nav zones, at the same time as aircraft are returning to base, something extremely rare, then you will have the recalculation twice insrtead of once. Something the engine already does for all other aircraft not currently in 'return to base' mode anyway. Still an insignificant CPU load. If the engine recalculates all flights when nav zones change, then doing so for the 'return to base' a/c is no different than for any other airborne a/c.

Generally any calculation that does not occur continuosly but only after a specific event or trigger (such as player input or a mission being complete) could not add any CPU load that a modern computer could not easily handle.

It is presumptive to state that changes are something "extremely rare" when, they could be quite common for someone who actively employs missions and Nav Zones. This would be arguing, "Facts not in evidence", as my favourite TV drama, "Law and Order" would put it.

Currently, the engine continuously tracks the direct path back to the base. As this is a simple direct path calculation, it is probably relatively simple. Once the plane has reached RTB state, it automatically goes into RTB mode and no further calculations are required since it is just a straight flight home after one computation. Requiring planes to observe Nav Zone rules inbound and outbound would mean that they need to be tracked continuously all the way back to the base in case new Nav Zones appear. While this might not double the CPU usage, I think that it would be far from insignificant because it affects not only planes returning, but planes still on active missions. They need to constantly calculate a path around all the Nav Zones instead of a simple direct path to the base.

The example previously presented was for a simple strike mission to and from the target. However, the RTB behaviour needs to apply to ALL missions (recon and area patrols, too). So, missions that have a fighter on a distant CAP mission or a recon plane searching for the enemy need to also have a continuous track of the fuel required to return to base around all the Nav Zones. If something changes that would require them to make a big long detour in order to make it back safely (i.e. a large new Nav Zone created around a newly detected CVBG/SAM), they need to calculate right away and navigator calculations are very slow. (If you don't believe me, just compare how long it takes for a ship to calculate a path through the Philippine Islands as opposed to a direct path through open water.) Not only that, they need to constantly update it i.e. a CAP/Recon mission could conceivably fly far enough that the shortest return path is now via the *other* side of the Nav Zone.

The large new Nav Zone might/should even force them to abort their initial mission if they don't have the new fuel requirements to fly to the target and return. Also, this sets up one of the many aforementioned quandries. What if the new Nav Zone is so large that the planes simply cannot return to base safely? Do they continue on a suicidal mission to the target? Turn around and make their best efforts to RTB? Sit and loiter and do nothing?

_____________________________

(in reply to Shemar)

Post #: 7

RE: Harpoon - 5/28/2008 3:59:42 AM

Shemar

Posts: 205
Joined: 1/25/2008
Status: offline

quote:

ORIGINAL: hermanhum

Currently, the engine continuously tracks the direct path back to the base. As this is a simple direct path calculation, it is probably relatively simple. Once the plane has reached RTB state, it automatically goes into RTB mode and no further calculations are required since it is just a straight flight home after one computation. Requiring planes to observe Nav Zone rules inbound and outbound would mean that they need to be tracked continuously all the way back to the base in case new Nav Zones appear. While this might not double the CPU usage, I think that it would be far from insignificant because it affects not only planes returning, but planes still on active missions. They need to constantly calculate a path around all the Nav Zones instead of a simple direct path to the base.

The example previously presented was for a simple strike mission to and from the target. However, the RTB behaviour needs to apply to ALL missions (recon and area patrols, too). So, missions that have a fighter on a distant CAP mission or a recon plane searching for the enemy need to also have a continuous track of the fuel required to return to base around all the Nav Zones. If something changes that would require them to make a big long detour in order to make it back safely (i.e. a large new Nav Zone created around a newly detected CVBG/SAM), they need to calculate right away and navigator calculations are very slow. (If you don't believe me, just compare how long it takes for a ship to calculate a path through the Philippine Islands as opposed to a direct path through open water.) Not only that, they need to constantly update it i.e. a CAP/Recon mission could conceivably fly far enough that the shortest return path is now via the *other* side of the Nav Zone.

The large new Nav Zone might/should even force them to abort their initial mission if they don't have the new fuel requirements to fly to the target and return. Also, this sets up one of the many aforementioned quandries. What if the new Nav Zone is so large that the planes simply cannot return to base safely? Do they continue on a suicidal mission to the target? Turn around and make their best efforts to RTB? Sit and loiter and do nothing?

I don't think you understand what I was talking about in my latest paragraph. There is no need to continuously track anything more than the game is already tracking. The engine is already tracking if a plane is in bingo fuel (a state that requires the plane to return to base immediately, in a straight line and flying optimum fuel consumption parameters). When that is the reason the plane is ordered to RTB, then nothing changes from the existing behavior. Additionally, the engine does not attempt to calculate fuel consumption around nav zones and define bingo fuel that way. Bingo fuel is still only calculated for a straight line RTB.

But, when the plane is ordered to RTB because its mission is over, or because it is out of ammo, or because the player ordered it to (so it has not yet reached bingo fuel), instead of putting it on an RTB mission, the engine could simply put it in a transit mission to base (therefore automatically observing nav zones and altitude/speed orders just like every other transit mission, without adding any functionality or calculations at all), and only changing to a true RTB mission if it goes into a bingo fuel situation, in which case it goes into the standard straight RTB.

There is actually zero, absolutely zero calculations that this functionality would add, beyond those of a standard transit mission. So, in case it is still not clear, with the method I propose the game does not attempt to calculate fuel consumption for observing nav zones at all, ever. The only fuel calculation is still the one for a straight line return to base. However, by putting it on a transit mission, it will still observe the nav zones for as long as it has extra fuel, and revert to straight line to base flight when/if it reaches bingo fuel, just like it would do if it was patrolling or loitering.

(in reply to hermanhum)

Post #: 8

RE: Harpoon - 5/28/2008 6:15:15 AM

hermanhum

Posts: 2209
Joined: 9/21/2005
Status: offline

quote:

ORIGINAL: Shemar

I don't think you understand what I was talking about in my latest paragraph. There is no need to continuously track anything more than the game is already tracking. The engine is already tracking if a plane is in bingo fuel (a state that requires the plane to return to base immediately, in a straight line and flying optimum fuel consumption parameters). When that is the reason the plane is ordered to RTB, then nothing changes from the existing behavior. Additionally, the engine does not attempt to calculate fuel consumption around nav zones and define bingo fuel that way. Bingo fuel is still only calculated for a straight line RTB.

But, when the plane is ordered to RTB because its mission is over, or because it is out of ammo, or because the player ordered it to (so it has not yet reached bingo fuel), instead of putting it on an RTB mission, the engine could simply put it in a transit mission to base (therefore automatically observing nav zones and altitude/speed orders just like every other transit mission, without adding any functionality or calculations at all), and only changing to a true RTB mission if it goes into a bingo fuel situation, in which case it goes into the standard straight RTB.

Let's walk through an example of what you are suggesting. For the sake of simplicity, I will refer to the image previously attached so that a graphic reference is available. Please indicate where I am in error.

1. Plane launches on strike mission to Flyingdales. Plane will observe all Nav Zones outbound to the target.
2. After the strike is conducted, the plane has some discretionary range remaining and does not need to go directly back to base.
3. It now goes onto a Transit mission (proposed new programmed behaviour) that will lead it to the home airbase and will observe all Nav Zones along the way.
4. After it flies a few miles away from the target, the plane reaches "true" RTB state and goes into a "bingo fuel situation" that only a direct path back to the base ("standard straight RTB") is possible so it flies through all the Nav Zones on its return.

Without even considering if there are any additional calculations or potential problems, does this example cover the idea you proposed? If not, please elaborate because I feel that my example follows your reasoning and I do not think that this behaviour will not solve the problem originally posted at the beginning of this thread. I believe that KlubMarcus wanted the planes observe the Nav Zones all the time so that they do not run afoul of SAMs and threats.

_____________________________

(in reply to Shemar)

Post #: 9

RE: Harpoon - 5/28/2008 6:51:17 AM

Shemar

Posts: 205
Joined: 1/25/2008
Status: offline

Yes, your example is accurate to my proposal. From my very first post I already agreed that when the plane is in bingo fuel, nav zones are irrelevant by necessity. What I am proposing is a way for RTB planes to use any extra fuel they have to avoid danger as much as possible.

While the plane�will not always avoid the Nav Zones, it will avoid them as long as it has fuel to do so, so in every case where the fuel situation is not marginal. Even if it does end up reaching bingo fuel, it still minimizes the danger by avoiding danger zones up until that point (so if we are talking about a big nav zone in the middle of the plane's path it will circle around it to the best of its fuel capabilities rather than just fly through the middle of it). And best of all, barely any new code is required and no additional CPU load. Frankly, compared to the current behavior, I don't see a down side.

< Message edited by Shemar -- 5/28/2008 6:53:03 AM >

(in reply to hermanhum)

Post #: 10

RE: Harpoon - 5/28/2008 11:06:01 AM

hermanhum

Posts: 2209
Joined: 9/21/2005
Status: offline

Okay, the proposal does not solve the bad behaviour mentioned by KlubMarcus and is, in itself, a request for a new feature.

I agree that, superficially, it could look like a marginal improvement on current behaviour, but I will hope that AGSI does not attempt to implement it because actually is not. My rationale being:

1) The improvement is marginal at best. It seeks to squeeze a few more miles out of the current behaviour and isn't any great leap forward.
2) There are just too many ways for this to go badly. Adding 1% additional function at the risk if reducing the present 90%+ behaviour seems a bad gamble to make. There have been several really bad implementations of new features lately. The most recent is the Active Sonobuoy Boondoggle.

I bet that when they went about removing the use of Active sonobuoys, they also thought, "This won't hurt anything else and we'll be improving the game by making it more realistic", too. We all just saw and experienced the unwelcome results of this fumble... er... failure to consider all the implications of a fundamental change in mechanics before implementation. There are several other examples of crippling "new game behaviours" introduced by patches that broke perfectly functional features.

3) The potential gains are far outweighed by the potential loss of function, IMO. The ability of a user to assign units to more than one mission has likely been the desire of many for a long time. In essence, this seems to be the basis for your requested feature - a "second mission" appended to the "first mission" once the primary has been completed.

Instead of a haphazard (ad hoc) approach to implementing new mission behaviours, I personally hope that AGSI revamp their entire Mission table and add many more missions with much more control to the user. A proper Mission planner with Primary, Secondary, Ingress/Egress route control, etc, would be a generational improvement for Harpoon. I believe that this would entail many more risks, but the payoff in the end would be significantly higher than trying to customize little interim changes.

_____________________________

(in reply to Shemar)

Post #: 11

RE: Harpoon - 5/28/2008 2:49:38 PM

Shemar

Posts: 205
Joined: 1/25/2008
Status: offline

1) I completely disagree with your conclusions. The OP requested that units RTB respect nav zones and altitude/speed settings. My proposal solves that by 100%. Your extreme scenario of adding huge nav zones blocking the return path of the airctaft and pretty much hugging the base when it is already low on fuel are far from the norm.�I highly doubt the OP was asking for planes already in bingo fuel to avoid nav zones as that would mean certain loss of the unit anyway. There is no possible fix or feature that will make an aircraft that does not have enough fuel to complete its mission and return safely to base do so, so I am making the assumption that the OP is making the reasonable request of having aircraft returning to base respect Nav zones as long as they have the fuel to do so, rather than the unreasonable request of having them avoid nav zones even if they do not have the fuel to do so.

Unless somebody is in the habit of sending planes off in suicidal missions, the most common situation would be that aircraft on a mission have enough fuel to complete it and return home without violating nav zones.

2) Examples regarding other bugs and features are irrelevant. I am not going to share your paranoia that any change will bring about doom. And of course it is quite funny to see words like 'crippling' used for minor annoyances. I guess some people get crippled way too easily. Additionally throwing around arbitrary percentages and then using them to make statements regarding software development is quite funny. Let me throw my own completely arbitrary and pulled out of a hat percetages around... Current game functionality: 98.5%, Proposed change: 0.001%, Improvement of behavior in regards to the requested feature: 100%, chance or additional bugs: 1%, chance of additional bugs after next patch: 0.001%. Heh.

3) Wrong again. There is already a new 'mission' added after the completion of the original mission. The RTB mission. Additionally any units on a travel path with more than one node are technically already in a multi-mission state as they can make speed/altitude changes per waypoint. The proposed change will add no new functionality, it will just replace a piece of existing functionality with a different piece of existing functionality.

It is actually very interesting how you object to a minor change with huge improvement in functionality without making hardly any changes, proceed to claim that any change however minor will bring about doom, only to ask for a complete scrapping and redesign of missions which is one of the most complex and key elements of the game. I very much doubt anybody is willing to put that kind of time investment on a free upgrade. Change of the magnitude you suggest would only be possible with a whole new version of the game. And I don't think many people want to see that.

< Message edited by Shemar -- 5/28/2008 4:24:41 PM >

(in reply to hermanhum)

Post #: 12

RE: Harpoon - 5/28/2008 6:13:53 PM

TonyE

Posts: 1551
Joined: 5/23/2006
From: MN, USA
Status: offline

Where I see such a solution going bad is with existing scenarios. AI planes used to be able to get to the target going around Nav zones but didn't have the fuel to get back to base except going thru the Nav zone. With the new and improved RTB function those planes can't even take off in the first place because they don't have the fuel to reach the target (evading nav zones) and returning to base (also evading nav zones). Otherwise it seems to me like a fair way of gaining some improvement at a manageable risk.

Just my 2 not very well thought out cents...

_____________________________

Sincerely,
Tony Eischens
Harpoon (HC, HCE, HUCE, Classic) programmer
HarpGamer.com Co-Owner

(in reply to Shemar)

Post #: 13

RE: Harpoon - 5/28/2008 7:26:34 PM

Vincenzo_Beretta

Posts: 440
Joined: 3/13/2001
From: Milan, Italy
Status: offline

quote:

ORIGINAL: Shemar
I am not going to share your paranoia that any change will bring about doom. And of course it is quite funny to see words like 'crippling' used for minor annoyances.

I agree that being paranoid about "changes that will bring about doom" is not good: there are enough occourrences where this already happened that there is no need for the mind to make up more.

And I also agree that words like "crippling" should not be wasted for minor annoyances, exp. when they are so sorely needed for the many, many major ones that plague the game as of now - like the one being discussed here.

I know that I may be sounding like a broken record, but (just to make an example among many) when in an ASW intensive scenario you discover that ASW doesn't work, any word beyond "sorry, we are working to fix it" becomes superfluous.

< Message edited by Vincenzo Beretta -- 5/28/2008 7:29:30 PM >

_____________________________

(in reply to Shemar)

Post #: 14

RE: Harpoon - 5/28/2008 7:27:46 PM

Vincenzo_Beretta

Posts: 440
Joined: 3/13/2001
From: Milan, Italy
Status: offline

Double post

< Message edited by Vincenzo Beretta -- 5/28/2008 7:28:43 PM >

_____________________________

(in reply to Vincenzo_Beretta)

Post #: 15

RE: Harpoon - 5/28/2008 9:32:36 PM

FreekS

Posts: 323
Joined: 5/12/2006
Status: offline

quote:

ORIGINAL: TonyE

Where I see such a solution going bad is with existing scenarios.��AI planes used to be able to get to the target going around Nav zones but didn't have the fuel to get back to base except going thru the Nav zone.� With the new and improved RTB function those planes can't even take off in the first place because they don't have the fuel to reach the target (evading nav zones) and returning to base (also evading nav zones).� Otherwise it seems to me like a fair way of gaining some improvement at a manageable risk.

Just my 2 not very well thought out cents...

Tony I'm with you. I like the idea that both Shemar and Herman allude to of making the missions (including the RTB mission) better. It would be great if the RTB mission stays low a bit longer. Just like it would be great if many other mission behaviours (such as ferry missions flying at 2001m and at midpoint descending to 31m, or all sub missions using creep speed) were improved. But I don't like the idea that existing scenarios would need to be rebuilt. I still have 2 battlesets to rebuild for 3.6 to 3.8/3.9/3.9.2. As a designer of many scens that use nav-zones to create off-axis attacks that would be ANOTHER tedious cycle of rebuilds. Often aircraft, loadouts and locations of airbases have been selected to be at the limit of fuel and there would be a lot of work (including finding out which scens/bases/planes/loadouts are affected) to rebuild these.

So its a cost-benefit equation. Yes I'd like ANW to become better. Yes I'm very skeptical of AGSI/Matrix ability to make the scen better without creating more bugs. And Yes I hope AGSI takes into account all the work that changes in features bring for existing scenarios when they make the decision to create a new feature, relative to the value of that feature.

Freek

_____________________________

(in reply to TonyE)

Post #: 16

RE: Harpoon - 5/28/2008 10:37:53 PM

Shemar

Posts: 205
Joined: 1/25/2008
Status: offline

quote:

ORIGINAL: TonyE

Where I see such a solution going bad is with existing scenarios.��AI planes used to be able to get to the target going around Nav zones but didn't have the fuel to get back to base except going thru the Nav zone.� With the new and improved RTB function those planes can't even take off in the first place because they don't have the fuel to reach the target (evading nav zones) and returning to base (also evading nav zones).� Otherwise it seems to me like a fair way of gaining some improvement at a manageable risk.

No, I am not suggesting any change in the fuel calculations. The planes will still take off and avoid nav zones on their way to the target just as they are doing right now. The only change comes after they have expended their weapons. In that case instead of going to RTB, they go to 'transit to base' which allows them to avoid nav zones. at least as long as they have enough fuel. And as with any aircaft in flight as soon as the fuel gets critical they go to RTB mode.

There should be no need for any existing scenarios to be changed as all the mission currently firing properly should continue to fire properly, as any change should only take effect after the mission is complete.

< Message edited by Shemar -- 5/28/2008 10:41:59 PM >

(in reply to TonyE)

Post #: 17

RE: Harpoon - 5/28/2008 11:11:38 PM

hermanhum

Posts: 2209
Joined: 9/21/2005
Status: offline

quote:

ORIGINAL: FreekS

Yes I'd like ANW to become better. Yes I'm very skeptical of AGSI/Matrix ability to make the scen better without creating more bugs.

Bingo. Right on target.

_____________________________

(in reply to FreekS)

Post #: 18

RE: Harpoon - 5/29/2008 2:59:46 AM

Bucks

Posts: 679
Joined: 7/27/2006
From: Melbourne, Australia
Status: offline

How many angels can fit on the head of a pin?

(in reply to hermanhum)

Post #: 19

RE: Harpoon - 5/29/2008 11:57:31 AM

Vincenzo_Beretta

Posts: 440
Joined: 3/13/2001
From: Milan, Italy
Status: offline

One for every 1000' of height of the pin

_____________________________

(in reply to Bucks)

Post #: 20

RE: Harpoon - 6/15/2008 3:36:13 PM

KlubMarcus

Posts: 41
Joined: 10/5/2006
Status: offline

Having the planes Return To Base at the altitude the player sets would help a lot. I noticed that there are default RTB altitudes such as 301 m or 601 m, well within range of AA systems that aren't immediately destroyed because you prioritize more lethal threats. So I set the RTB altitude to High or Very High. Unfortunately, the AI will eventually drop the plane back down and back in range of enemy AA.