RE: Command v1.11 Service Release 7 - Release Candidate (Full Version)

All Forums >> [New Releases from Matrix Games] >> Command: Modern Operations series



Message

tjhkkr -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 4:43:54 PM)

Thank you VERY MUCH!



Hongjian -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 4:49:54 PM)

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 5:25:54 PM)

quote:

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 6:25:52 PM)


quote:

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 6:28:33 PM)

quote:

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: http://www.matrixgames.com/forums/tm.asp?m=3585262

The process exists for a reason.



Sardaukar -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 6:56:49 PM)

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 7:10:47 PM)


quote:

ORIGINAL: Sunburn

quote:

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: http://www.matrixgames.com/forums/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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 7:16:53 PM)

quote:

ORIGINAL: lamboman43


quote:

ORIGINAL: Sunburn

quote:

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: http://www.matrixgames.com/forums/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

http://www.matrixgames.com/forums/tm.asp?m=3585262

Thanks!

Mike



lamboman43 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/12/2017 7:23:58 PM)

quote:

ORIGINAL: mikmyk

quote:

ORIGINAL: lamboman43


quote:

ORIGINAL: Sunburn

quote:

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: http://www.matrixgames.com/forums/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

http://www.matrixgames.com/forums/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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/13/2017 12:04:11 AM)

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/13/2017 12:15:02 AM)

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



[image]local://upfiles/26210/E7F6FEF9D09B41D5BD1F9C274AC52E5A.jpg[/image]



mikmykWS -> RE: Command v1.11 Service Release 7 - Release Candidate (2/13/2017 12:22:18 AM)

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/13/2017 12:55:46 AM)


quote:

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 -> RE: Command v1.11 Service Release 7 - Release Candidate [CURRENT: B906.15] (2/13/2017 9:39:15 PM)

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 2:11:00 AM)

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



mikmykWS -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 2:13:10 AM)

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

Mike



edsw -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 7:23:03 AM)

quote:

ORIGINAL: DWReese

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

quote:

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 3:19:58 PM)

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 4:38:14 PM)

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 -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 5:14:02 PM)

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.




Dimitris -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 5:26:47 PM)

quote:

ORIGINAL: 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.


A relatively simple adjustment would be to increase the "slack" on pre-fire DLZ calculations, so that every entity becomes more careful/conservative with its long-range shots.

However, this would make it more difficult to model actors that, for any number of reasons (typically associated with insufficient training or combat experience), really do fire at the extreme edge of the envelope - and rarely hit even easy targets.



Eggstor -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 6:02:33 PM)


quote:

ORIGINAL: Sunburn

quote:

ORIGINAL: 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.


A relatively simple adjustment would be to increase the "slack" on pre-fire DLZ calculations, so that every entity becomes more careful/conservative with its long-range shots.

However, this would make it more difficult to model actors that, for any number of reasons (typically associated with insufficient training or combat experience), really do fire at the extreme edge of the envelope - and rarely hit even easy targets.

Perhaps the increase in "slack" could be tied to unit proficiency then?



Dimitris -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 6:19:23 PM)

quote:


Perhaps the increase in "slack" could be tied to unit proficiency then?


This could work, but leads to two other issues:

1) "Ace" and "Rookie" pilot face up in the air. Rookie pilot fires first because his DLZ slack is less. The shot will almost certainly miss, but the mere evasion manouver (lose speed, lose altitude, lose SA for a while unless off-board supported) puts the Ace at a disadvantage.

2) This in turn would entice players to micromanage in order to compensate for the built-in deficiencies of their assets ("I know that this rookie pilot will fire at max range because he's a fish, so instead I'll restrict him through WRA [or manual inputs] to avoid this handicap". This (a) runs counter to Command's mantra "the player should not be encouraged to win through micromanagement" (yes, we're not perfect in that but at least we consciously try) and (b) it's not how things go in RL ops: In the cockpit, the rookie will forget all the WRA rules the squadron briefing tried to instill into him and will go fangs-out.

Gain something, lose something...



Cik -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 6:22:38 PM)

well, there are legitimate reasons to fire Rmax/Ropt, generally to play keep away, prevent targets from closing, to scare or intimidate, or to attack unaware, very slow targets (cargo planes with no RWR, very old fighters, what have you) you could probably tie shooting range to some mix of experience and target type. generally there's no use shooting at agile, fast fighters at anything past Rpi, and you don't really gain a good PK until you reach Rtr / NEZ

anyway, what i'm trying to say is that there may be legitimate reasons an expert pilot would take a shot he knew would have a near 100% chance of being trashed. to force the enemy to defend, losing energy (altitude also, maybe) to exploit his numerical missile advantage, to affect their mental state, increase the chaos, break up their formation, etc








Dimitris -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 6:24:24 PM)

You just described the rationale for the WRAs [:)]



Raptorx7_slith -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 6:27:47 PM)

Cockpit visibility + Aircraft with only rear-aspect missiles and no cannon leads to interesting situations. The dog fight seems a bit more unpredictable with aircraft losing a contact as it goes past them which is pretty cool. I've noticed that the change in behavior for getting a rear aspect shot is mostly evident in 2 v 2 engagements which are of course the most common.



Cik -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 6:33:16 PM)

yeah, i've blasted a lot of 21s in RC# that didn't even defend themselves. which seems WAD :^) considering the structure of the canopy. generally it's less of a disadvantage the more planes you have in the air, which seems as it should be. (granted there's an upper bound on how many threat calls you can jam into a radio but that's outside scope anyway)

standoff for the GBUs seems pretty neat too.



DWReese -> RE: Command v1.11 Service Release 7 - Release Candidate (2/14/2017 9:59:02 PM)

Resolved



DWReese -> RE: Command v1.11 Service Release 7 - Release Candidate (2/15/2017 3:46:05 AM)

This is not a bug concerning 17, I just want to know if you believe that this behavior is accurate.

Attack planes are entering an area flying at 36000 ft.
Only a few SAMs can reach that high.
The SAMs that can start shooting.
The planes dive. I assume that they can evade better, and can pick up speed. This appears to be what they should do.
But, in diving, the planes have now descended into even more trouble. Now, all of those SAMs and AAA that couldn't hit them, now have a chance to fore at them because they are so low.
Do you think that this is the way that it should be?
I'm not saying that it isn't how it should work, but it seems odd to me that you would jump out of the frying pan, and into the fire to escape.

If it is, then that's okay.

Doug



Dimitris -> RE: Command v1.11 Service Release 7 - Release Candidate (2/15/2017 2:52:21 PM)

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

Download: Superseded by Build 906.19

See OP for instructions, warnings and release notes.

Fixes/Changes
#10319 - Fuel burn rates for aircraft
#10312 - Yak-3, Il-4 fuel/range issues
#11335 - CWDB: AIM-9C Not Working
FIXED: ASMs may glide perpetually if their target is destroyed

* Added more slack on pre-fire DLZ calculations. This makes fires more conservative in their long-range shots.

* Includes the DB3000 v461 and CWDB v460 databases.



Page: <<   < prev  1 2 [3] 4   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
2.843994