Your opinion on the beta patch 3.7.3

[jpkoester1]

Well, the only thing about the beta I heared so far is that Herman managed to successfully play a MP game without a crash and some blanket statements that the patch sucks compared to the 3.6 version. So far so good, but we are looking for more detailed info.

So in case you have tried out the beta please give us a hand and let us know what you think about it. What would be most helpful of course are detailed bugreports (of course we'd also love to hear that you didn't find any) but I have also posted a poll so you can give some more generic feedback (note that you can select more than one option).

I am looking forward to your responses.

Cheers,
JP

[ComDev]

I'm sorry to say, but if this is what the final 3.7.3 release looks like, I will continue to use 3.6 until we get something that actually works...

[Valgua]

I've not played 3.6 so can you explain why you prefer it to 3.7.3? What bugs are still there?

Filippo

[ComDev]

I've posted up my newest findings in 3.7.3 here, in the HarpoonHQ forum:

http://www.harpoonhq.com/phpBB2/viewtopic.php?t=4197

My 3.7.0 + 3.7.1 buglist can be found here:

http://www.harpoonhq.com/phpBB2/viewtopic.php?t=3778

[Anonymous]

[Deleted by Admins]

[ComDev]

ORIGINAL: VCDH

Some comments regarding these reports

<reads the thread>

1. Weapon allocation is based on two weapons per target. I'll take a look at it.

Two weapons per target is correct. The way the AI handles it, with one missile per platform/launcher is incorrect. Like I said it worked fine in 3.6 but is broken in 3.7.

ORIGINAL: VCDH

2. Air targets are never engaged at max range. If they were, they'd be able to instantly fly out of the weapons envelope and evade. Weapons will not fire until the program engine is sure that the weapon will make it to the target no matter what the defending platform does. This is why you see anti-ship missiles engaged at max range but not tactical aircraft.

Sounds like you need to test this... manually you can get an AIM-7M in the ODB to fire at 18nm, the AI will not launch until the target is within 10-11nm. Again, this works fine in 3.6 but is not in 3.7.

ORIGINAL: VCDH

3. I have never experianced this 180 degree turn that you speak of. However, it is moot since the lack of a proper physics model means all platforms can turn instantantly. There isn't very much point in worrying about aircraft aspect in relation to launch parameters if platforms can turn instantly (point defence weapon arcs are not respected for this very reason). A new physics model will probably come with the new UI.

Happened in most engagements I saw. And I ran through a lot of them.

ORIGINAL: VCDH

4. Drag select of multiple friendly units is for grouping them only. It's actually a good idea and if it's doable then we will consider it.

Nope, this is how things have always worked pre-3.7. In 3.6.3 you can drag-select multiple friendly units and then use the Attack button to attack a single enemy unit or a selection of enemy units.

Likewise, the multiple-select clicking (ctrl+mouse clicking) units no longer works.

ORIGINAL: VCDH

5. Altitude bands have been changed to reflect the H4 rules. What your experiancing is due to the fact that you're using the ODB. In the future, DB compliance will require that all altitude bands conform to H4 rules. You can start working on that when we release the in game DB editor, hopefully by this weekend.

So in effect you cannot limit missile firing altitudes in the database?

And before we can start working on a 3.7 database we need a SBR that works, so that I don't have to rebuild all of the 250 DB2000 scenarios manually with each database update.

ORIGINAL: VCDH

6. You're going to have to be more descriptive. Please Amplify.

Related to #1, only it affects ships too. Here's a couple of examples from my other buglist:

- AI weapon allocation is, mildly put, horrible. It worked fairly well in 3.6 but in Harpoon 3.7 it is pretty hopeless. I have two Farragut DDGs engaging incoming ASMs. Both DDGs fire one missile each at the first two missiles, which means both DDGs egange the very same targets with one SAM each. This in turn means that four SAMs get fired against two targets, rather than eight SAMs against four targets as it was in Harpoon 3.6. This is not logical, and very unrealistic. What has happened here really?

- A pair of F-14s with AIM-7s will fire one missile each at the same target. This will lock up both radars, only two missiles are fired and only one target is engaged. This is not logical, and very unrealistic. Each F-14 should fire two missiles at seperate targets, as they do in Harpoon 3.6.

ORIGINAL: VCDH

7. Remember that your using the ODB. Use ANWDB and see what happens. For further infomation on missile seekers please read: Harpoon 3 ANW DB Compliance Thread

This is a problem with the 3.7 game, not the database.

The solution described on that page you link has nothing to do with the seekers picking up the wrong targets in the game. Besides, the "-1500 sensitivity and 1.5 the weapon range trick" you suggested doesn't work too well because the sensitivity isn't high enough to pick up most targets. So you'll prolly have problems with the missiles going after the wrong targets in that database too.

Your suggested solution is also *very* unrealistic. Most missile seekers have really short ranges, and have to lock on after launch. Besides, when fired from low altitude at distant targets, the missiles will not be able to see their targets no matter what database changes you make.

ORIGINAL: VCDH

8. I'll look into it but it's a minor issue at best.

Thanks [:D] For those of us who produce lots of scenarios, it is quite annoying.

ORIGINAL: VCDH

9. Speeds can be set manually by the player in game. This is the whole premise of STOT anyway with regards to the current UI implementation. With regards to weapon launch issues, please see comment #5

Yes... of course... but that wasn't the point...

This bug makes it impossible to create AI-side strike packages in 3.7 that perform realistically.

ORIGINAL: VCDH

10. You're going to have to be more descriptive. Please Amplify.

Don't think I can... that's exactly what happened.

ORIGINAL: VCDH

11. We set this up quite some time ago. The program engine will no longer pick the first weapon record in numerical order but rather take stock of the current tactical situtation from the subs perspective and try and load the best possible weapon for the job. I have not experianced any issues with how the engine reloads sub torpedo tubes.

It is really messy and degrades AI performance compared to 3.6.

ORIGINAL: VCDH

12. The program engine requires speed info to calculate evasion parameters in the event that a torpedo is detected. If the speed vector wasn't there then the sub wouldn't evade. It's more important to have the sub evade and have a speed vector on the incoming weapon.

The subs evaded just fine in 3.6 IIRC, and then they didn't have speed vectors.

ORIGINAL: VCDH

13. Just like real life. If you want BDA, close with the taget. Don't come crying to me if you get smoked by a still fighting platform though. [;)]

It went like this, changing every 5 seconds: *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*, *On Fire*, *Probable Kill*...

Doesn't make much sense in my mind... Sticking to one or the other is a lot more logical.

ORIGINAL: VCDH

14. There have been changes to the way fragmentation warheads work. They now comply with the H4 paper rules. Fire damage is no longer applied immediately (as was previously the case), and is much lower. The unit report for units on fire will now display the level of fire damage (% of original DP per 30 minutes), and a message has been added to indicate when all fires are out. We also partially applied 4.x fragmentation, in that frag warheads will now cause a number of DP of hull damage (frag penetration, which means any level of General armor will stop it cold) equal to the number of critical hits generated to ships and facilities. As as aside, we also added amessageto indicate when critical hits are stopped due to armor.

Still seems like a single Frag hit will set the ship on fire and eventually sink it...

ORIGINAL: VCDH

15. yeah that doesn't seem right. I'll take a look at this.

Thanks 8)

ORIGINAL: VCDH

16. Terrain Avoidance/Following have been changed to reflect the H4 paper rules.

I *seriously* doubt this is how the H4 paper rules work.... Are there no Terrain Following / Avoidance flag in the game now?

ORIGINAL: VCDH

Remember that you used the Original DB from back in the day. In the future we'd appreicate if if players used one of the custom DBs (DB2K, ADB, Colonial, etc) or the ANW DB for testing in the game. We'll be using the HUD3 DB for the stock scenarios when we get the time (and the money).

Ragnar, keep in mind that DB2K does the great job that it does in v3.6 because you tweaked the DB to get around the limitations of that version. Fortunately we've managed to fix many of these limitations so that the work arounds are no longer required. By working together we'll be able to get your scens and DB to make the most of the new patch.

Later
D

Uhm yeah I know... but I seriously doubt any of the above bugs have anything at all to do with the database design...

[ComDev]

Darren just sent me the signature file I needed to get DB2K v10.0.0 up and running, and after testing this stuff again it has become clear that none of the above bugs are related to the ODB (aka WackDB) database design. All of them are errors in the 3.7 exe.

...so, the game runs killingly slow and the mousepointer is jumpy, the AI refuses to fire any AAMs at long range, the AI strike aircraft launch missiles at the wrong targets, the missiles themselves go after the wrong targets, the AI wastes half of the available channels-of-fire due to buggy weapon allocation, manual weapon allocation is problematic because I can't select multiple units, waypoint orders are ignored, etc etc etc...

All of this worked fine in 3.6 I'm afraid.

I also added new bugs to the list:

http://www.harpoonhq.com/phpBB2/viewtopic.php?t=4197

BTW, as for the ECM mods, I've been quiering AGSI repeatedly about what changes that have been made to the game engine but no answer yet.

[Anonymous]

[Deleted by Admins]

[jpkoester1]

1. We'll look into having the 2 missiles coming from 1 engaging aircraft

2. Just tested this in ANW-DB and it appears to work fine for me. It's probably related to missiles that are non-datalinked and non-BOL capable which now require lockon before launch.

3. I don't see the 180 degeree turn maneuver either

4. Agree, this one isn't working any more. Will look into it.

5. haven't checked into this one yet

6. glad to hear an improvement. weapon allocation bug you mean 2 ships firing at one missile? If so we'll look at it together with the aircraft missile allocation thing.

7. Can't reproduce, but have only tried with datalinked missiles so far. BTW, the weapon retargeting works like a charm too. Will try with non-datalinked weapons next.

8. Might be annoying but I guess you would agree that it's lower prio than the rest of them.

9. Haven't tested this, but I see your point

10. Haven't experienced this one yet

11. The logic is actually a bit more complex. Submarines will reload the same weapon that was fired. If no more of the weapon type are in the magazine the submarine will automatically load the weapon from the magazine that most closely resembles the one that was previously fired (based on valid target type). So if an ASW torpedo was fired another ASW torpedo will be reloaded.

12. Explained by Dale

13. Ship are assumed sunk (probable kill) if no emissions, movement or weapon firing is detected for a certain amount of time. The jumping is probably caused by one of your aircraft finding out the actual damage state. After a certain amount of time the presumed sunk logic kicks in. Units on Patrol missions will still investigate contacts that are presumed sunk, but aircraft on strike missions won't prosecute these any more in order not to waste precious weapons on burning hulks.

14. Haven't tested that

15. being checked into

16. Haven't checked

17. Is this with the slow/accurate setting or did you change that?

25. did you have the default window scheme thing activated?

Cheers,
JP

[ComDev]

ORIGINAL: VCDH

ORIGINAL: emsoy
So in effect you cannot limit missile firing altitudes in the database?

Did I say that? Read above what I said earlier. You've been playing long enough now to know better. Weapon altitude limitations are set in the DB editor. Both in the weapon and propulsion annex.

It really doesn't seem like the AI can adjust to those altitudes, as today's tests suggest. Which would be pretty bad since this is a very neat feature that works fine in 3.6.

ORIGINAL: VCDH

ORIGINAL: emsoy
And before we can start working on a 3.7 database we need a SBR that works, so that I don't have to rebuild all of the 250 DB2000 scenarios manually with each database update.

Define 'works' please? In our initial testing we didn't suffer any problem. If you want us to look at something you're going to have to give us a little more than '3.7 doesn't work'

For a starter, it can't read my INI files... And if it can't read my INI files, there isn't very much to report...

ORIGINAL: VCDH

ORIGINAL: emsoy
- AI weapon allocation is, mildly put, horrible. It worked fairly well in 3.6 but in Harpoon 3.7 it is pretty hopeless. I have two Farragut DDGs engaging incoming ASMs. Both DDGs fire one missile each at the first two missiles, which means both DDGs egange the very same targets with one SAM each. This in turn means that four SAMs get fired against two targets, rather than eight SAMs against four targets as it was in Harpoon 3.6. This is not logical, and very unrealistic. What has happened here really?

What has happened is that you don't agree with the way the game operates and thus it's 'broken'.

Err... you're joking right? Did you even read what I wrote? [8|]

ORIGINAL: VCDH

ORIGINAL: emsoy
This is a problem with the 3.7 game, not the database.

Most of the items here are related to DB settings which are set by the DB author. Use your own DB, NOT the ODB. We are not going to look at anything related to the ODB.

Nope. These are 100% game engine issues.

ORIGINAL: VCDH

ORIGINAL: emsoy
The solution described on that page you link has nothing to do with the seekers picking up the wrong targets in the game. Besides, the "-1500 sensitivity and 1.5 the weapon range trick" you suggested doesn't work too well because the sensitivity isn't high enough to pick up most targets. So you'll prolly have problems with the missiles going after the wrong targets in that database too.

Missile seekers now act in such a manner in that if there was 2 targets in the seeker cone then it would pick the closest one. If that happened to be a flaming wreck then you just wasted a missile. Make sure you BOL your missile after the target in that case. This happens to all seekers.

I don't know the exact parameters on missile seekers. It's classified and there's no point in getting into trouble over it. I just set the sensitivity really high when I have no data to ensure that a target will be picked up. Around the -2000 mark.

That's a rather clever way to hide a bug... Not... But I guess you should know that something is broken when even datalinked weapons go after the wrong targets...

The attack aircraft also shoot at the wrong targets, so something is seriously wrong with 3.7. By comparison, 3.6 worked fine.

Oh yeah and you just changed the sensitivity setting in your "sensor hack" because I brought it up. Nice try, but -2000 won't get you there either Dale [;)] Do the math and you'll see.

ORIGINAL: VCDH

ORIGINAL: emsoy
Your suggested solution is also *very* unrealistic. Most missile seekers have really short ranges, and have to lock on after launch. Besides, when fired from low altitude at distant targets, the missiles will not be able to see their targets no matter what database changes you make.

This is a computer simulation/game....reality takes a break here. Enjoy it. Seekers have been well explained and I'm not going to repeat myself here.

Nah, there are big logical holes in the stuff that you wrote. Your "solution" doesn't even take into account targets that are over the horizon. So the seekers in 3.7 are totally broken, and any scenario that involves any kind of missiles will suffer.

ORIGINAL: VCDH

ORIGINAL: emsoy
This bug makes it impossible to create AI-side strike packages in 3.7 that perform realistically.

Again, realistic to whom? Keep in mind that you aren't the be all and end all. If you want total 100% realism then I suggest you join the Navy.

You can use the real world as a reference, for instance...

Of course, if you don't know what the real world of naval warfare looks like, then it might be a good idea to go and find out. And perhaps stop making these kinds of statements in a naval simulator forum, where there are people who actually do this "stuff" for a living...

ORIGINAL: VCDH

ORIGINAL: emsoy
It went like this, changing every 5 seconds:

Doesn't make much sense in my mind... Sticking to one or the other is a lot more logical.

And minor. Just like the sub vectors. Something that crashes the game? Locks it up? Sure we'll look at it. A simple display error? Unless you're willing to pay Darrel's fee for making the fix (and rest assured it's pretty high) then we'll be dealing with other stuff first.

Well if you're going to play that card then I guess we all known that you have already wasted a lot of Darrel's time on tons of weird and utterly useless stuff... So fixing this one would actually go in the 'useful' category.

ORIGINAL: VCDH

ORIGINAL: emsoy
I *seriously* doubt this is how the H4 paper rules work.... Are there no Terrain Following / Avoidance flag in the game now?

They are still there. As for how the paper rules work, I'm the wrong guy to talk to. You know who to contact if you have any comments regarding how the paper rules work.

I'm not tryin to offend you Ragnar but it seems to me like you are too used to playing in 3.6. There are a large number of changes that affect gameplay in 3.7.3 and you're going to have to learn to adopt. I was quite a difference to me but I adjusted eventually.

I see. But the 3.7 exe is clearly broken, and I can't say I'm particularly impressed with the way things are being handled. Especially the way you try to cover up obvious bugs and unrealistic behaviour with a bunch of blah-blah. And if I was a professional user (i.e. a US Navy guy) I think I'd take the hint and rather go and buy my simulation tool somewhere else...

[ComDev]

ORIGINAL: jpkoester1

1. We'll look into having the 2 missiles coming from 1 engaging aircraft

Thank you, I must say I'm a lot more relaxed with this reply than Dale's. I hope you'll be able to figure out what's wrong and fix it.

ORIGINAL: jpkoester1
2. Just tested this in ANW-DB and it appears to work fine for me. It's probably related to missiles that are non-datalinked and non-BOL capable which now require lockon before launch.

Nah, I'm afraid they pick the wrong target.

ORIGINAL: jpkoester1
3. I don't see the 180 degeree turn maneuver either

Hm, will run some more tests [:D]

ORIGINAL: jpkoester1
4. Agree, this one isn't working any more. Will look into it.

Brilliant, thanks! [8D]

ORIGINAL: jpkoester1
5. haven't checked into this one yet

K.

ORIGINAL: jpkoester1
6. glad to hear an improvement. weapon allocation bug you mean 2 ships firing at one missile? If so we'll look at it together with the aircraft missile allocation thing.

Yes. 2 ships that have two channels of fire will not select two targets each (4 total), but rather shoot at the same 2 targets.

ORIGINAL: jpkoester1
7. Can't reproduce, but have only tried with datalinked missiles so far. BTW, the weapon retargeting works like a charm too. Will try with non-datalinked weapons next.

Thanks [:D]

ORIGINAL: jpkoester1
8. Might be annoying but I guess you would agree that it's lower prio than the rest of them.

Lower priority, yes, but should certainly be fixed before we start building scenarios on a larger scale.

ORIGINAL: jpkoester1
9. Haven't tested this, but I see your point

Great [8D]

ORIGINAL: jpkoester1
10. Haven't experienced this one yet

Will try to reproduce.

ORIGINAL: jpkoester1
11. The logic is actually a bit more complex. Submarines will reload the same weapon that was fired. If no more of the weapon type are in the magazine the submarine will automatically load the weapon from the magazine that most closely resembles the one that was previously fired (based on valid target type). So if an ASW torpedo was fired another ASW torpedo will be reloaded.

Hm... explains why I got such weird loadouts... Maybe it can be improved by tweaking the database. I'll look deeper into it.

ORIGINAL: jpkoester1
12. Explained by Dale

Still pretty weird.

ORIGINAL: jpkoester1
13. Ship are assumed sunk (probable kill) if no emissions, movement or weapon firing is detected for a certain amount of time. The jumping is probably caused by one of your aircraft finding out the actual damage state. After a certain amount of time the presumed sunk logic kicks in. Units on Patrol missions will still investigate contacts that are presumed sunk, but aircraft on strike missions won't prosecute these any more in order not to waste precious weapons on burning hulks.

Hm, but in this case this wouldn't work because the AI would fire when the status changed back and forth to 'on fire'...

ORIGINAL: jpkoester1
14. Haven't tested that

It's pretty easy to reproduce. Will try to create a testfile.

ORIGINAL: jpkoester1
15. being checked into

Thanks.

ORIGINAL: jpkoester1
16. Haven't checked

K.

ORIGINAL: jpkoester1
17. Is this with the slow/accurate setting or did you change that?

Changed the H3 Launcher to use the fast/unaccurate setting.

ORIGINAL: jpkoester1
25. did you have the default window scheme thing activated?

Cheers,
JP

Don't think so. Another new feature huh? [8D]

[jpkoester1]

ORIGINAL: emsoy

ORIGINAL: jpkoester1
2. Just tested this in ANW-DB and it appears to work fine for me. It's probably related to missiles that are non-datalinked and non-BOL capable which now require lockon before launch.

Nah, I'm afraid they pick the wrong target.

I thought this one was missiles not firing at full range...

ORIGINAL: emsoy

ORIGINAL: jpkoester1
7. Can't reproduce, but have only tried with datalinked missiles so far. BTW, the weapon retargeting works like a charm too. Will try with non-datalinked weapons next.

Thanks [:D]

Could you send me a DB and savegame so I can reproduce? Having no luck so far.

ORIGINAL: emsoy

ORIGINAL: jpkoester1
13. Ship are assumed sunk (probable kill) if no emissions, movement or weapon firing is detected for a certain amount of time. The jumping is probably caused by one of your aircraft finding out the actual damage state. After a certain amount of time the presumed sunk logic kicks in. Units on Patrol missions will still investigate contacts that are presumed sunk, but aircraft on strike missions won't prosecute these any more in order not to waste precious weapons on burning hulks.

Hm, but in this case this wouldn't work because the AI would fire when the status changed back and forth to 'on fire'...

Yea, the AI would fire when your patrol aircraft detects that the ship hasn't actually sunk (less than 100% damage). In this case the 'presumed sunk' would be a false positive detection which gets corrected when the patrol aircraft makes a proper BDA.

ORIGINAL: emsoy

ORIGINAL: jpkoester1
14. Haven't tested that

It's pretty easy to reproduce. Will try to create a testfile.

Testfiles are much appreciated

ORIGINAL: emsoy

ORIGINAL: jpkoester1
17. Is this with the slow/accurate setting or did you change that?

Changed the H3 Launcher to use the fast/unaccurate setting.

Not sure we can do much about this as a lot of things have been changed "under the hood" that simply require more processor power. (i.e. Sonobuoys now actually working, navigation and intercept logic, etc...)

ORIGINAL: emsoy

ORIGINAL: jpkoester1
25. did you have the default window scheme thing activated?

Cheers,
JP

Don't think so. Another new feature huh? [8D]

We discussed this before. It's actually a feature already implemented in 3.7.0 so we didn't list it as a new 3.7.3 feature. When starting a scenario uncheck the "Use default window scheme" checkbox and see if that helps.

Cheers,
JP

[jpkoester1]

Hello Ragnar,

it's me again. Couple more points and updates about the bugreports, but first let me ask you if you are testing in Scenedit or if you are using the Game engine (because I am using the Game engine to try to reproduce the errors you report and I am not sure if that makes a difference)

1. Checking this

2. AAM engagements not at max range
I testet this with ADB an F-14/Phoenix combo and the missiles were fired at max range. DB/Scenario combo to reproduce would be appreciated

3. Still haven't seen those 180 degree turns

4. This one we're checking. Not sure what was changed and if getting the behaviour back will break something else new.

5. Altitude adjustment.
I just tried this with an ADB scenario and the aircraft correctly rose to 2000m to drop their bombs. Another group armed with Shrike missiles also fired them without a problem. Additionally both flew with the same speed. Could you send me a DB/scenario combination so I can check into it?

6. see 1

7. Just tried in Dawn Patrol. Only one missile missed the intendet target and went for a neutral that was quite close. Again, a savegame would help us.

8. Think I remember something on Mantis about this. Will check there again.

9. Haven't personally seen the problem in the scenarios I played so far, but that doesn't mean it isn't there.

10. Haven't seen that one either.

11. Discussed before.

12. I believe some new code was put in to prevent subs from evading as soon as they detect a torp that is miles and miles away. Might be the reason.

13. explained above

14. Not tested yet

15. still checking

16. Reported and someone is checking it.

17. see above. BTW, we are moving to a new compiler which might help in this regard...

18. tested with Fighting withdrawal (over 1MB) and indeed the mouse gets a bit jumpy. Not really bad for me though and I only have 1.66 GHz. Will pass it along anyways. Scenario ran at about 1:15 time compression but who would want to run it at any more than 1:5 anyways, soo much going on...

19. I'm not a pro on ECM, but I know some stuff was changed. Might need some DB-adjusting but for details best ask Dale.

20. see 19

21. see 7

22. see 16

23. checking

24. checking

25. Default window scheme?

26. Checking

28. Just tried and can't reproduce

29. I remember something in Mantis, will have to check

Cheers,
JP

[jpkoester1]

26. Here is the deal about strike package targeting problems:
Basically AI units often used to get slaughtered while ingressing towards their intended target (for example strike aircraft flying towards their target (lets say a hanger) flying right over a SAM-site and all getting shot down in the process). The AI a bit dumb that way so Darrel made it smarter.

Strike packages can now determine if something in their way to the target is a threat to them and will then automatically engage those threats as well. I do see the problem this causes for those pre-determined-outcome tricks used for some scenarios. For example in Fighting withdrawal the LHA is supposed to be sunk at the beginning but the new smarter AI detectes a big threat close to the LHA (a CG and a CVN) and engages those first

I am sorry that this change wasn't properly documented but do hope that this at least explains where the problems are coming from. I have opened a feature request for a checkbox in the mission editor that will allow this 'self defense' to be turned off, but am not sure that it will make it into this release.

Thanks for listening,
JP

[Bucks]

7: - Missile seekers are such a mess... Anti-ship missiles will *NEVER* hit the target they're aimed at, but rather go after anything else they might come across. Even smaller ships that are outside their seeker arcs and further away than the intended target. Also true for land-attack missiles. This really needs to be fixed guys!

Ragnar,

I've looked into this as I was experiencing a similar issue. I was attempting to have some Osa II's fire their SS-N-2B Styx's at a group of hotels/resorts on the coast. I'd had the same issue with the missiles always attacking something other than the intended target.

Checklist:
1. Range of missile seeker
2. RCS of intended target as compared to RCS values for other valid targets in the immediate area the SSM is being fired into.

I looked at the RCS of the original buildings is the scenario. The scen designer used ODB "Small building" to represent a Beach Resort/Hotel. Of course this didn't take into account the RCS of the nearby Runway or Hangar's etc which dwarfed the RCS of the small building/hotels. So my incoming Styx's would always pick something other than the hotel -> Scen wont work...

The two points on the checklist sorted out this problem. I decreased the range and sensitivity of the missile seeker. Then substituted the small building-hotels for a new facility with appropriate RCS values. Now they select the correct target always.

Your point about missile seekers having a short range is valid here Ragnar. I cut the seeker values by 50% ie range from 10nm to 5nm and adjusted I/O accordingly. In combination with the RCS correction I have eliminated the issue.

The example applying to ships is related to something else. I am firing a Styx at a group of ships but have selected a particular one for my target. I fire and in the course of the missile's flight time another vessel crosses the flight path of the Styx after it reaches it's activation point, ie becomes a valid target by being within the seeker's detection cone.

Even if the "new" unintended target is of smaller RCS than the intended target, radar return strength is a function not only of the I/O value of the radar itself but also range. Therefore it would be possible that if the targets were separated by a distance close to the maximum range of a low power missile seeker, upon activation the smaller RCS/closer target, may be returning a greater strength signal than the more distant larger RCS "intended" target.

This would cause the seeker to lock on to what you consider to be the wrong target but is in fact a true and correct function of the game and reality. Just bloody painful wasting missiles like that and I know!!! [;)]

Hope this helps

Darren

[Anonymous]

[Deleted by Admins]

[ComDev]

ORIGINAL: Bucks
This would cause the seeker to lock on to what you consider to be the wrong target but is in fact a true and correct function of the game and reality. Just bloody painful wasting missiles like that and I know!!! [;)]

When the missiles go after targets that are outside the seeker arc, something is most certainly broken...

[Anonymous]

[Deleted by Admins]

[z1812]

Hi All,

I wonder how many potential buyers have been scared off by all the the confusion.

Lots of discussion of databases by those in the know, leaving others confused.

Questions not clearly answered. For instance. Will existing scenarios work with the new patch. Thats a yes or no.

Multiplayer. Oops, forget that, don't want to start a war. Wait a minute.................this IS a wargame!!

And thats just obvious issues. I like the game but I will stick to the package as bought until some grand chef appears, hopefully ending the reign of what seems like too many cooks with their fingers in the promising, but overly fussed over, aquatic stew. ( hopefully I will not be shot.................that is by 2 weapons systems when there should only be one) All in fun. So fanboys and sonorbouys please keep your distance!!!

Regards John

[TonyE]

fwiw, I've played three scenarios multiplayer on the Stratsims server (hehe, my server) with the 3.7.3.0 beta and had good results, sure the game has bugs but it didn't crash and I had fun, now if there were just more people coming out to play things would be even better. It is even running on my Windows Vista machine as of about 6 hours ago (I moved the H3 server piece over to it).