MartinCo

Hi ED, For a long time we've been having issues with "bad waypoints" causing server crashes, whilst this has always been intermittent and with many tens of units being moved at a given time over the course of a PvP campaign it can be hard to find out which unit was moved from where to where that may have caused the crash. 2023-07-02 22:41:59.407 INFO EDCORE (8764): OS-Version: 10.0.20348 () 0x110-0x3 2023-07-02 22:41:59.416 INFO EDCORE (8764): 0x000000000006cb67 (edterrain4): buildMaxEdgeLengthUVSet + 0x1607 2023-07-02 22:41:59.430 INFO EDCORE (8764): 0x0000000000229e1f (edterrain4): landscape5::lsa5pureFile::Mesh::tinyCopy + 0x118F 2023-07-02 22:41:59.438 INFO EDCORE (8764): 0x0000000000230181 (edterrain4): landscape5::navGraph5File::findPath + 0x961 2023-07-02 22:41:59.462 INFO EDCORE (8764): 0x00000000002605a1 (edterrain4): navGraphPath2::save + 0x4471 -- 2023-07-02 22:45:09.218 INFO EDCORE (14644): OS-Version: 10.0.20348 () 0x110-0x3 2023-07-02 22:45:09.227 INFO EDCORE (14644): 0x000000000006cb67 (edterrain4): buildMaxEdgeLengthUVSet + 0x1607 2023-07-02 22:45:09.235 INFO EDCORE (14644): 0x0000000000229e1f (edterrain4): landscape5::lsa5pureFile::Mesh::tinyCopy + 0x118F 2023-07-02 22:45:09.244 INFO EDCORE (14644): 0x0000000000230181 (edterrain4): landscape5::navGraph5File::findPath + 0x961 2023-07-02 22:45:09.267 INFO EDCORE (14644): 0x00000000002605a1 (edterrain4): navGraphPath2::save + 0x4471 -- 2023-07-09 22:44:40.522 INFO EDCORE (15060): OS-Version: 10.0.20348 () 0x110-0x3 2023-07-09 22:44:40.530 INFO EDCORE (15060): 0x000000000006cb67 (edterrain4): buildMaxEdgeLengthUVSet + 0x1607 2023-07-09 22:44:40.539 INFO EDCORE (15060): 0x00000000002301bc (edterrain4): landscape5::navGraph5File::findPath + 0x99C 2023-07-09 22:44:40.549 INFO EDCORE (15060): 0x000000000026055e (edterrain4): navGraphPath2::save + 0x442E 2023-07-09 22:44:40.560 INFO EDCORE (15060): 0x000000000025ec62 (edterrain4): navGraphPath2::save + 0x2B32 -- 2023-07-17 02:35:36.722 INFO EDCORE (11376): OS-Version: 10.0.20348 () 0x110-0x3 2023-07-17 02:35:36.730 INFO EDCORE (11376): 0x000000000006cb67 (edterrain4): buildMaxEdgeLengthUVSet + 0x1607 2023-07-17 02:35:36.739 INFO EDCORE (11376): 0x00000000002301bc (edterrain4): landscape5::navGraph5File::findPath + 0x99C 2023-07-17 02:35:36.747 INFO EDCORE (11376): 0x000000000026055e (edterrain4): navGraphPath2::save + 0x442E 2023-07-17 02:35:36.756 INFO EDCORE (11376): 0x000000000025ec62 (edterrain4): navGraphPath2::save + 0x2B32 -- 2023-07-20 19:08:45.377 INFO EDCORE (6160): OS-Version: 10.0.20348 () 0x110-0x3 2023-07-20 19:08:45.388 INFO EDCORE (6160): 0x000000000006cb67 (edterrain4): buildMaxEdgeLengthUVSet + 0x1607 2023-07-20 19:08:45.398 INFO EDCORE (6160): 0x00000000002301bc (edterrain4): landscape5::navGraph5File::findPath + 0x99C 2023-07-20 19:08:45.407 INFO EDCORE (6160): 0x000000000025e8a1 (edterrain4): navGraphPath2::save + 0x2771 2023-07-20 19:08:45.418 INFO EDCORE (6160): 0x000000000025f032 (edterrain4): navGraphPath2::save + 0x2F02 However after the most recent one, we were fortunate the user knew exactly which unit and where it was moved to - enabling me to get an almost 100% reproducible setup in the ME - Open Beta 2.8.6.41363 - No Mods For a first hand, just jump into taccom, select the Leclerc and set a way point to +41666 +4712 and you should experience a game crash, if it succeeds in calculating a route, set the way point again in a similar area and it should fail to calculate and crash. This isn't unique to Syria, or Bassel (though we have had 3 crashes with units around basal in particular, so seems to be more prone to occur around here) Please find attached track replay. dcs.log-20230720-200509.zip

Hi ED, I took a look around and didn't see if this was reported yet. Steps: * Load into combined arms vehicle with FLIR * Use WHOT/BHOT within vehicle * Slot into an F16/18 or other FLIR equipped pod * FLIR image now rather blurry incorrect / not looking where you are with only TV mode being as expected. Please see track file attached Regards, Martin CA_FLIR_ISSUE.trk

Sorry for the delay, I only just saw this, Please find attached a self contained setup. * F10 menu just to print the results of getAmmo showing 38 x M151 * WPN page shows 32 M151, and 6 M257 illumination * Upon firing, pop up message shows that i'm firing M257 Illumination * F10 getAmmo now reports 32 M151. Thank you! getAmmo.trk

Thank you so much, what a super fast turnaround

@Flappiesorry for the ping (but you're mostly active on scripting items), probably should have created this in the ME forum - wasn't sure which is the best place for scripting issue visibility

Thank you!

Hi ED, When using trigger.action.setMarkupTypeLine the change of line style only works the first time, and not subsequent attempts Both setMarkupColor, setMarkupColorFill seem to be working correctly and continue to work after a failed setMarkupTypeLine Please see attached track replay with simple F10 menu to present the issue Thanks, Martin line_style_bug.trk

Hi ED, When using F10 view option Fog of War, the map shows enemy ground units, missiles, rockets, etc. in addition to enemy air units. In an PvP MP scenarios in particular this can feel quite gamey in numerous ways: - Drive ground unit fast through town, marking on map where units were spotted before they have any chance of engaging and clean up - Use SU25-T Fantasmagoria (in particular) to show precise locations of many EN SAM systems on F10 and follow up with PP JDAMs without risk - knowing when a specific type of missile is inbound, near-real time position updates allowing precise calls for calls for flare / chaff to be made - Providing exact clock-position in dogfights with near perfect SA It would be great to have two features to help mitigate this behavior 1) An additional Fog of War setting that would only show air units and no missiles, etc. 2) If there could be a configurable F10 refresh interval to further remove the near-realtime perfect picture. Thanks, Martin

Hey ED, Whilst this is somewhat Apache specific for the moment, I decided general as it's an API issue With the introduction of the Apache and mixed Launcher loadouts the getAmmo does not return the correct ammo quantity. Reproduction: Loaded: M261 - 19 x Hydra 70, Pod Zones: C - M274; D/E - M151 Unit:getAmmo() reports 19 x M151 - This should return 12 M274 and 7 M151 After firing 1 x M151 and 2 x M274, the EVENT_SHOT shows the correct missile launched, and as you can see in my WPN page we now have 10 M274 and 6 M151, while getAmmo() reports 16 M151 Hopefully this image has all the information required without a track as the track wouldn't show anything other than the loadout Thanks, Martin

Thank you for the super fast turnaround

Hi ED, Since 2.8 OB, it appears a possible bug has appeared with external cargo. When you "Cancel choosing cargo", or from time to time when detaching a crate you have slung and placed down - the system seems to think the crate is still attached, and you become unable to do any more sling loading operations until you respawn as "Cancel choosing cargo" becomes inoperative. Please find the attached track file that shows a reliable way of reproducing the problem. Edit: to add deleting the crate you were last attached to also does not clear this state Thanks, MartinCo cargo_cancel_a.trk

No bug the last time this was posted - it's only a quick search away before posting: https://forums.eagle.ru/showthread.php?t=256398

I did a few more tests for each of the load outs just for fun, and the issue appears to be limited to any time that R10 and R20 are both loaded with chaff with LAU-138s attached, and the chaff counter counts the quantity it expected to eject, not the actual quantity (so above 20C, we will always run run when the counter reads 11, so simple workaround is - if taking a larger loadout, make sure the counter reads 11 less than you expect to have) Also forgot to mention OB: 2.5.5.38756 LAU-138, ALE-39 with 50 flares / 10 chaff (R10, L10) - 50 ejections [table=head]COUNT|LAU-138 Ejected(total)|ALE-39 Ejected (total) 10||YES (10) 40|YES(40)| [/table] LAU-138, ALE-39 with 40 flares / 20 chaff (R10, L20) - 60 ejections [table=head]COUNT|LAU-138 Ejected(total)|ALE-39 Ejected (total) 20||YES (20) 40|YES(40)| [/table] LAU-138, ALE-39 with 30 flares / 30 chaff (R10, R20) - 59 ejections [table=head]COUNT|LAU-138 Ejected(total)|ALE-39 Ejected (total) 9|YES (9)| 1|YES (10)|YES(1) 19||YES(20) 10|YES (20)|YES(30) 20|YES (40)| [/table] LAU-138, ALE-39 with 20 flares / 40 chaff (R10, R20, L10) - 69 ejections [table=head]COUNT|LAU-138 Ejected(total)|ALE-39 Ejected (total) 10||YES (10) 9|YES(9)| 1|YES(10)|YES(11) 19||YES(30) 10|YES(20)|YES(40) 20|YES(40) [/table] LAU-138, ALE-39 with 10 flares / 50 chaff (R10, R20, L20) - 79 ejections [table=head]COUNT|LAU-138 Ejected(total)|ALE-39 Ejected (total) 20||YES(20) 9|YES(9)| 1|YES(10)|YES(21) 19||YES(40) 10|YES(20)|YES(50) 20|YES(40) [/table] LAU-138, ALE-39 with 0 flares / 60 chaff (R10, R20, L10, L20) - 89 ejections [table=head]COUNT|LAU-138 Ejected(total)|ALE-39 Ejected (total) 30||YES (30) 9|YES(9)| 1|YES(10)|YES(31) 19||YES(50) 10|YES(20)|YES(60) 20|YES(40)| [/table] Without LAU-138s, and a 30F/30C loadout (to ensure R10 + R20 Chaff) the issue was not present, nor present with a 20F/40C (R10 F, R20 C) just for completeness

Thank you both it's really not a serious gameplay impacting issue and has a very simple workaround so no urgency on this side Keep up the fantastic work Thanks MartinCo

Hi Heatblur, With a full load out of chaff (LAU-138 + ALE-39), with a chaff program of single chaff, I would expect 100 ejections - however I seem to be getting a strange (but consistent) sequence [table=head]COUNT|LAU-138 Ejected(total)|ALE-39 Ejected (total) 30||YES (30) 9|YES(9)| 1|YES(10)|YES(31) 19||YES(50) 10|YES(20)|YES(60) 20|YES(40)| [/table] This leads to correct attribution of the 100 ejections, but only over 89 commanded chaff program events Interestingly, If I set R10 to Flare to "disable" the LAUs, then I do indeed get, as expected 60 ejections from the ALE-39 Following this, I set R10 back to Chaff, I then get 40 ejections from the LAUs, for the expected total of 100 individual ejections. Does this constitute a sequencing issue (as I would not expect a single dispense program to trigger multiple canisters on a single event (R10 + Another)) Repro Steps: ME: - AN/ALE-39 Loadout: 60 Flares / 0 chaff - Fill LAU-138 with Chaff: checked Launch Mission: - Ground Crew -> Select AN/ALE-39 Loadout: Request 0 Flares / 60 Chaff - Rearm (without changing chaff/flares counts) - Jump to RIO - Set all ALE-39 stations to Chaff - Set chaff program for single chaff - Jump to Pilot / Takeoff - Jump to RIO - Hit Chaff Program and count (Just in case, I have "AN/ALE-39 Left Data Dispenser Switch Down - Chaff Program" as my bind) Thanks, MartinCo

Love this mission. Just a small bug so far on v04-01 In HandleGrooveTimeScore, if you enter the grove at a very low amount of time (< 6 seconds) it will have no score and result in a script error as there is no catchall. Thanks, Martin

My particular crash has been resolved with 2.5.4.26368 (and confirmed by re-attempting it a few times) DCS UH-1H - Assertion and crash when UH-1H main rotor is damaged are fixed.

I've just downloaded DCS Stable 2.5.3.24984 and it doesn't occur there.

Reproducible pretty much 100% of the time Cause a crash such that the body is intact (but does not blow up - so collective up, lift off, hard cyclic right and collective down such that you roll onto your side) and the game crashes, If the rotor failure causes the rotors to hit the body seems to also trigger it. Landing hard such that it blows up seems not to cause an issue for me - DCS Beta 2.5.4.25729 - Reset profile - No reshade etc. - No 3rd party addons Crash dump / trk / logs / dxdiag etc. attached dcs.log-20190109-203431.zip