4.0 Bug reports

[mpow66m]

7 hours ago, Splash said:

 Reported here: 

 

ahhh,thnx.what could possibly cause this?

[Ssnake]

8 hours ago, Bond_Villian said:

If the AI takes the liberty of assuming 'return fire only' for a scout route (without being explicitly told to do so/ "change being ordered"), it seems counterintuitive and a bit inconsistent for it to not assume 'fire at will' for an attack route, dont you think?

 

I think the fire control order only gets auto-applied on the very first route leg that is applied. If that happend to be a scout route you happen to be on "return fire only". Now, there are also legitimate cases of assault routes without weapons free. Assault is one of the few movement tactics where the units will REALLY try to reach the end point of their route. Engage, March, Scout ... they all can result in units NOT reaching the next waypoint if they happen to run into enemy presence. Only on an assault route a unit will attempt to keep moving rather than stopping to seek a hull-down position, or returning to the previous waypoint.

But if you haven't been detected so far, opening fire may still be a bad idea if you're just trying to dash into the next concealed position.

 

So, changing fire control orders is a tactical decision. Tactical decisions are left to the human player / mission designer.

[mpow66m]

Found this too.

 

 

 

 

Edited September 4, 2016 by mpow66m

[Bond_Villian]

On 05/09/2016 at 0:06 AM, Ssnake said:

I think the fire control order only gets auto-applied on the very first route leg that is applied.

 

I just tested, and this is not the case. Units adopt 'return fire only ' when they begin a 'scout' route regardless of whether its the first of subsequent leg of a route chain. I dont mean to bang on about this, and i dont know if this is a new behaviour as of >4.00, but as i said earlier, and given that the 'scout' order is the ONLY order that will ALWAYS change the fire control behaviour; if the AI takes the liberty of assuming 'return fire only' for a scout route (without being explicitly told to do so/ "change being ordered"), it seems counter-intuitive and a bit inconsistent for it to not assume 'fire at will' for an attack route.

 Perhaps the 'solution' is to make all routes default to 'no change', OR to have the 'most probable'  fire control set automatically for each route type, just as an assault route will automatically change to line formation to focus firepower to the front, or a march order will automatically change to line formation in order to use roads better. (Yes, there can be exceptions to desired behaviours on routes- but why have preset options if you need to tinker with them every time)

 I hope thats clear, and if its a 'feature not a bug' , then ill just have to get in the habit of reminding units thats its OK to shoot first when attacking

Cheers

Edited September 7, 2016 by Bond_Villian

[Volcano]

1 hour ago, Bond_Villian said:

 

I just tested, and this is not the case. Units adopt 'return fire only ' when they begin a 'scout' route regardless of whether its the first of subsequent leg of a route chain. I dont mean to bang on about this, and i dont know if this is a new behaviour as of >4.00, but as i said earlier, and given that the 'scout' order is the ONLY order that will ALWAYS change the fire control behaviour; if the AI takes the liberty of assuming 'return fire only' for a scout route (without being explicitly told to do so/ "change being ordered"), it seems counter-intuitive and a bit inconsistent for it to not assume 'fire at will' for an attack route.

 Perhaps the 'solution' is to make all routes default to 'no change', OR to have the 'most probable'  fire control set automatically for each route type, just as an assault route will automatically change to line formation to focus firepower to the front, or a march order will automatically change to line formation in order to use roads better. (Yes, there can be exceptions to desired behaviours on routes- but why have preset options if you need to tinker with them every time)

 I hope thats clear, and if its a 'feature not a bug' , then ill just have to get in the habit of reminding units thats its OK to shoot first when attacking

Cheers

 

Yes, we are looking into that.

[enigma6584]

On 8/15/2016 at 2:15 PM, Volcano said:

 

That IS a proper scan. IRL if the gunner is given a scan direction then the gunner is expected to scan violently back in forth to aggressively look for a contact.  The slow, meandering scan is not correct for that. Essentially the directed scan is the gunner at "heightened awareness".

 

That said, whether you hear the turret brake sound constantly probably depends on the vehicle. Just curious, which vehicle were you in at the time?

 

 

 

I think you should take a look at this Volcano.  I've had some time to play with this more now and my AI gunners are swinging like you mention, calling out the targets they see but not stopping and aiming at those targets.  They just continuously swing past the target.

[Ssnake]

There's always a chance that they might not detect it, independent of how obvious it may appear to you. Sometimes computer-controlled crew are better at spotting a threat, sometimes they are worse. But it's hard to say what the issue is without a test scenario that shows what you think is wrong. Submitting reference scenarios that expose a bug are your best chance of getting things fixed quickly.

[msconfig]

Hi I'm having a issue with the 004 patch where in say MBT like Abrams, Leo, M60, if I'm the TC, the gunner never identifies targets, works fine in 4.0. Thanks

[Bond_Villian]

SB pro pe 4.004 crashed without an error message during MP game (17/09/16 TGIF), and crashed with 'stopped responding' error when i rejoined game in progress.

CrashDumps.rar

[Flanker15]

2 little ones I've noticed.

When the Challenger 2 AI TC  orders HEAT (hesh) to be loaded instead smoke is loaded.

Seemingly randomly convoys of trucks will follow their rout in reverse gear (old scenarios only I think but hard to test).

[Ssnake]

Can you upload the offending scenarios somewhere, with a description where/when to find the routes that make the trucks go in reverse?

[Volcano]

On 9/18/2016 at 1:03 AM, Flanker15 said:

Seemingly randomly convoys of trucks will follow their rout in reverse gear (old scenarios only I think but hard to test).

 

Sounds like the scenario has Retreat orders by accident on those routes. I have been know to do this in haste since MARCH and RETREAT are next to each other in the list (that said, I did not make that scenario).

[Volcano]

On 9/17/2016 at 0:32 AM, Bond_Villian said:

SB pro pe 4.004 crashed without an error message during MP game (17/09/16 TGIF), and crashed with 'stopped responding' error when i rejoined game in progress.

CrashDumps.rar

 

 

Thanks for the DMP files. We will investigate!

[Flanker15]

On 20 September 2016 at 5:50 AM, Volcano said:

 

Sounds like the scenario has Retreat orders by accident on those routes. I have been know to do this in haste since MARCH and RETREAT are next to each other in the list (that said, I did not make that scenario).

 

Yes this seems to be the answer thankyou.

[ChrisWerb]

Apologies if these have already been reported.

 

Latest patched version of V4. On the shooting range at the start of the game.

 

1. M2A2 Bradley - in day sight no reticle in low magnificaiton. In high magnification both gun and Tow reticles appear superimposed with the TOW reticle slightly low and left of centre - this might be how the real vehicle does it, but I don't remember this from the videos.
2. M2A2 Bradley - elevation and traverse are hypersensitive and run away easily so the turret literally spins. This does not happen on Marder, BMP-2 or CV-9035DK.

 

Edited September 29, 2016 by ChrisWerb

[Ssnake]

1) Yes, that's intentional

2) No idea what's going on, maybe someone else can help.

[Eihort]

Interesting issue that happens with M1A1, M1A2, and, so far, Leo2A5.

 

Merrily doing my thing during the instant action scenarios. In TIS, zoomed in, white hot. Every now and then, I'll pull the trigger on my joystick to fire the main gun (button 1, as mapped in controls), and suddenly it's Normal Gunner's Sight, with whatever zoom it was on, and when I switch back to TIS, it's now Black Hot, and the gun didn't fire. If I do nothing at all, and I pull the trigger again, and it just reverses back to what it was, toggling uselessly. It's not until I hit another button to toggle zoom, TIS, or TIS White Hot (all mapped on joystick), that JoyButton1 will fire the gun like it's mapped to do.

 

First I thought it was a case of double-mapped controls, but Fire, TIS, and Zoom aren't. Any ideas what's causing this?

 

As I have my PC setup for DCS, I -do- have a gregarious amount of peripherals hooked up. I went into control panel and disabled those I'm not using (the PC tower is buried in the desk. No way I can get in there and disconnect physically) and the issue still occurs.

 

EDIT: JOYSTICK HARDWARE FAILURE. NOT GAME RELATED. EXPLANATION IN LATER POST.

Edited October 29, 2016 by Eihort

[DarkAngel]

30 minutes ago, Eihort said:

Interesting issue that happens with M1A1, M1A2, and, so far, Leo2A5.

 

Merrily doing my thing during the instant action scenarios. In TIS, zoomed in, white hot. Every now and then, I'll pull the trigger on my joystick to fire the main gun (button 1, as mapped in controls), and suddenly it's Normal Gunner's Sight, with whatever zoom it was on, and when I switch back to TIS, it's now Black Hot, and the gun didn't fire. If I do nothing at all, and I pull the trigger again, and it just reverses back to what it was, toggling uselessly. It's not until I hit another button to toggle zoom, TIS, or TIS White Hot (all mapped on joystick), that JoyButton1 will fire the gun like it's mapped to do.

 

First I thought it was a case of double-mapped controls, but Fire, TIS, and Zoom aren't. Any ideas what's causing this?

 

As I have my PC setup for DCS, I -do- have a gregarious amount of peripherals hooked up. I went into control panel and disabled those I'm not using (the PC tower is buried in the desk. No way I can get in there and disconnect physically) and the issue still occurs.

Do you have a Hotas warthog?. I had this problem at one point when the second trigger detent got configured for something else?.

 

[Eihort]

I do, and it's not mapped to anything for that explicit reason.

[DarkAngel]

You may want to double check. it could be mapped to something on specific vehicles.

[Eihort]

Am I just missing it? Controls export attached.

 

It seems to occur more and more the longer I play. I don't have this problem in any other games using my Warthog.

CurrentControls.htm

[DarkAngel]

Yeah can't see any references to button 6. Though I seem to remember it as a different number in SB. I had a similar problem in TGIF where I went to fire my main gun and could only get coax. The other thing to check is do you have the target software running which may have a key macro set up in it?.

 

[Bond_Villian]

Mouse and Keyboard FTW!

[Eihort]

Not using TARGET. (No real need to with all the buttons really.)

[Eihort]

Okay, finally had it happen in another game. I have a short somewhere in the stick I gotta fix. Was finally able to replicate it in the properties for the joystick and sure enough, EVERY button lights up when stick is full forward left and I press one. *grumble*

Now back to your regularly scheduled program.

 

EDIT: Okay, so in the Warthog flight stick (not throttle), the small connector in the base that connects to the removable flight stick proper.... the yellow wire on it finally broke the solder connection and was free floating. As the wires are relatively motionless, works fine as long as it stays in contact. The problem was, with nearly full front left stick deflection, the yellow wire would move just enough contact the others, and when I pressed any button, they'd ALL fire. I never noticed it in other flight sims because I never really move the stick that far and press a button. However in SB, when tracking a fast moving target...

 

attached picture is the component in question. A quick solder and reassembly job. Certified Electronic Tech. Do not try this at home. I am not responsible if you damage yours trying the same fix.

 

http://puu.sh/rZ2DA/34b6546db3.jpg

Edited October 29, 2016 by Eihort
Explaining cause of behavior and why it wasn't apparent in other games for future reference