Command v1.11 Service Release 7 - Release Candidate [CURRENT: B906.21]

[tjhkkr]

Thank you VERY MUCH!

[Hongjian]

I cant really confirm, but I have the feeling that in this version, SAMs and AAMs DLZs are kinda messed up for a bit. I had multiple instances where A/Cs doing CAP missions are launching their AAMs at targets at the far edge of their missile range, only to waste the missiles as they run out of energy not even near their targets. This doesnt seem to happen, when you manually control the aircrafts.

Anyone else noticed this? Maybe it's just me.

[Dimitris]

ORIGINAL: Dysta
I've tested the SR7 with my scenario Northern Phantom, and I found both PL-15 and AIM-120D descending very slowly at mid-course flight, usually way above targets and missed.

You know the process for actually getting this resolved.

[lamboman43]

ORIGINAL: Sunburn

You know the process for actually getting this resolved.

So will you guys only act on bug reports in the tech support sub-forum?

[Dimitris]

ORIGINAL: lamboman43
So will you guys only act on bug reports in the tech support sub-forum?

There is an established process for submitting and investigating potential issues: tm.asp?m=3585262

The process exists for a reason.

[Sardaukar]

BTW, what is reason behind this?

* Revised "Realism Options" window: http://i.imgur.com/4gnjYZB.png . It has two features: (a) The activated and disabled options are more clearly visible, and (b) the player cannot change these options in normal play, only through the Scenario Editor.

Only thing I could think is not allowing it in future Multiplayer.

EDIT: actually got answer from Baloogan already in chat.

[lamboman43]

ORIGINAL: Sunburn

ORIGINAL: lamboman43
So will you guys only act on bug reports in the tech support sub-forum?

There is an established process for submitting and investigating potential issues: tm.asp?m=3585262

The process exists for a reason.

I get that there is a process that should be followed. Yes, he should have done that. Shame on him. The process is more efficient than having tons of bug reports sprinkled around the entire Matrix forums. I completely understand that rationale. But all I'm asking is will the devs ignore a bug report that they have seen (that's the important part) just because it isn't in the right forum? Because that is what I am understanding right now and I want to know if that is true. That's all I'm wondering. I'm not trying to be a dick, I promise. I'm genuinely curious because I'm fairly new here.

Perhaps there should be a warning on future Update Release posts telling people that they shouldn't post bugs in that thread because they probably won't be seen by you and the other devs. I think it is easy to be confused, especially for newcomers, by the idea that devs aren't looking for bug reports on the post that they put the update in. (I know Dysta isn't new. Again, shame on him. Bad Dysta[:-]) But some of the other people on this thread posting bugs as well probably don't understand that. I think a disclaimer would be a win-win for everyone.

[mikmykWS]

ORIGINAL: lamboman43

ORIGINAL: Sunburn

ORIGINAL: lamboman43
So will you guys only act on bug reports in the tech support sub-forum?

There is an established process for submitting and investigating potential issues: tm.asp?m=3585262

The process exists for a reason.

I get that there is a process that should be followed. Yes, he should have done that. Shame on him. The process is more efficient than having tons of bug reports sprinkled around the entire Matrix forums. I completely understand that rationale. But all I'm asking is will the devs ignore a bug report that they have seen (that's the important part) just because it isn't in the right forum? Because that is what I am understanding right now and I want to know if that is true. That's all I'm wondering. I'm not trying to be a dick, I promise. I'm genuinely curious because I'm fairly new here.

Perhaps there should be a warning on future Update Release posts telling people that they shouldn't post bugs in that thread because they probably won't be seen by you and the other devs. I think it is easy to be confused, especially for newcomers, by the idea that devs aren't looking for bug reports on the post that they put the update in. (I know Dysta isn't new. Again, shame on him. Bad Dysta[:-]) But some of the other people on this thread posting bugs as well probably don't understand that. I think a disclaimer would be a win-win for everyone.

Why would you even ask that? We try and pay attention to everything. Usually when things slip through the cracks its usually because its some string somewhere that has nothing to do with it.

We do have a welcome to the forum type post that asks a bunch of things. Please give it a read and let us know if you find in insufficient.

Here's the link

tm.asp?m=3585262

Thanks!

Mike

[lamboman43]

ORIGINAL: mikmyk

ORIGINAL: lamboman43

ORIGINAL: Sunburn



There is an established process for submitting and investigating potential issues: tm.asp?m=3585262

The process exists for a reason.

I get that there is a process that should be followed. Yes, he should have done that. Shame on him. The process is more efficient than having tons of bug reports sprinkled around the entire Matrix forums. I completely understand that rationale. But all I'm asking is will the devs ignore a bug report that they have seen (that's the important part) just because it isn't in the right forum? Because that is what I am understanding right now and I want to know if that is true. That's all I'm wondering. I'm not trying to be a dick, I promise. I'm genuinely curious because I'm fairly new here.

Perhaps there should be a warning on future Update Release posts telling people that they shouldn't post bugs in that thread because they probably won't be seen by you and the other devs. I think it is easy to be confused, especially for newcomers, by the idea that devs aren't looking for bug reports on the post that they put the update in. (I know Dysta isn't new. Again, shame on him. Bad Dysta[:-]) But some of the other people on this thread posting bugs as well probably don't understand that. I think a disclaimer would be a win-win for everyone.

Why would you even ask that? We try and pay attention to everything. Usually when things slip through the cracks its usually because its some string somewhere that has nothing to do with it.

We do have a welcome to the forum type post that asks a bunch of things. Please give it a read and let us know if you find in insufficient.

Here's the link

tm.asp?m=3585262

Thanks!

Mike

When Sunburn told Dysta that he knew what to do to get the problem "actually resolved", I thought that meant it wouldn't actually get resolved unless he did it the right way. Maybe I'm loose a few brain cells but that is what I thought. I'm not trying to offend anybody here.

[Dysta]

I was in a hurry when I update the scenario. I will test run it a dozen more times to make sure if that is still persists, and then I post it to bug report instead of here.

[Mgellis]

Sorry to report I am having some problems. I cannot get the game to start now. Here is the message I get...

[mikmykWS]

Hi Mark

Did you do this

** IMPORTANT NOTE #2 **: A newer version of VC++ must be installed before starting up. To do this, run vc_redist.x86.exe from the "\PreRequisites" folder. Otherwise you will receive Lua-related errors/crashes on startup.

[Mgellis]

ORIGINAL: mikmyk

Hi Mark

Did you do this

** IMPORTANT NOTE #2 **: A newer version of VC++ must be installed before starting up. To do this, run vc_redist.x86.exe from the "\PreRequisites" folder. Otherwise you will receive Lua-related errors/crashes on startup.

That seems to have done the trick. Thanks!

[ZoroastroBR]

The 20 seconds a/c maneuvering before missile impact is kinda hight imo.

Could it be 15s?

If not, could there be an option to set automatic firing ranges for all SAMs/AAMs 10 - 20% less than the standard value (without having to manually edit WRA for each missile and side)?

[DWReese]

I had the exact same thing. I have never seen so many weapons run out of energy.

[mikmykWS]

Guys are aware and working on fixing the bug guys. Its a doozy but the payoff is realistic flight kinematics. Stay tuned.

Mike

[edsw]

ORIGINAL: DWReese

I had the exact same thing. I have never seen so many weapons run out of energy.

I had the exact same thing. I have never seen so many weapons run out of energy.

The simulator is now done enough plausible kinematic model, in fact, on the, let's say the fighters have a maximum range of start-up and launch range The recommended taking into account the purpose of avoidance maneuver, which is priblizitetno 50-60% of the maximum. Thank you for working in this direction!

[Hongjian]

If this is a feature and not a bug, then we should maybe have WRA doctrine workaround. Like, automatically launching the missiles only at 50% range against fighter and other small sized targets (since I also noticed the problem when attacking helicopters at maximum AAM range - those helos simply evade even long range BVRAAMs like nothing by making them run out of energy).
I know that we can already do this manually, but its kinda a pain [:D]

Of course, this feature is actually more realistic, since it degrades the already pretty low PoH of BVRAAMs against maneuvering fighters. Makes you understand that logistics and turnover rates are the most important thing ever in an air-battle.

[Cik]

well, actual RMAX shots have near zero hitrate for a reason.

the sim is probably more realistic now than it was, just the AI needs to be tuned to work within the new reality.

most actual missile misses will be out of energy, if you can't decoy it and it has enough energy to reach you you are probably a dead man; most modern missiles have absurd G abilities so dodging it, even in something considered supermaneuverable is questionable.

[Dimitris]

Command v1.11 Service Release 7 - Release Candidate - Build 906.17

Download: Superseded by Build 906.18

See OP for instructions, warnings and release notes.

Fixes/Changes
#11349 - Multiple messages of damage for the same unit
#11341 - ARMs running out of Fuel <-- PLEASE CONFIRM
#11344 - cBU-59 not firing, version B906.15
FIXED: #11347 - [B906.15] Paveways going on past their expected range

* Improved engagement behavior for fighters/interceptors with "temperamental" missiles (1950s/60s):
a) If their weapons are aspect-limited, they try to position themselves behind the target instead of simply going head-on at it
b) They try to extend if they are within minimum weapon range (of their own preferred weapon)

These improvements help avoid some common "stupid" behaviors like merging head-on while not having a suitable weapon (e.g. no gun and only rear-aspect missiles) or exposing one's fighter to the target bomber's tailguns.

* Big performance gain for scenarios with no-nav zones.