Search the Community

Minor graphical bug, in the UHF Backup controls, there is no spot for the "Load frequency" press button. Command works as intended if a key or button is assigned, only the clickable spot is not present.

Hi, I have a problem with mission 3. Anyway, thanks, the campaign is off to a good start and seems very exciting and interesting (knowing that I can go on to the next part since I've already completed this mission once). Regards

TL;DR: when a mission spawns or clones a unit, memory is allocated. This memory is never deallocated, even on group/unit destroy, explode or removeJunk. Thus over time any mission that creates units will crash either from memory starvation or from hitting the RegMapStorage cap of 4094 groups. This investigation started after we noticed the excellent Pretense mission was dying after a few hours on our hosted server. By profiling the memory usage of the DCS_Server process using Process Lasso logging, we noticed that the VM (private bytes memory) continued to increase regardless of unit destruction, client join/leave or any other factor. The control was performed with a basic ME mission with a single client helo and no AI. VM usage was flat. The logical next step was then to write a script that spawned new units at a constant rate, and destroyed them on a cadence. If VM was deallocated, we would expect to see a sawtooth pattern. If it wasn't, we would expect to see a relatively straight incline up. The mission starts with 2 minutes of no spawning to establish a baseline with all scripts loaded. It is virtually flat. Once spawning starts (1 group of 5 vehicles every 3 seconds), VM rises steadily and does not reduce with destroy() being called on all ground objects every 60 seconds. When the spawn rate was increased to 1 group of 10 units every second, as expected the rate of VM accrual increased and VM was never deallocated. With a mission (not server) restart, no (effective) deallocation was performed as the VM restarts higher than when the mission was restarted. The next step was to also removeJunk around the spawn Zone to clean up as much as is permitted in the scripting environment. The same spawn parameters were used, with an additional step of calling removeJunk on a sphere 2x the size of the spawn zone every 5 minutes. In this test, VM continued the trend of accruing with no reduction due to destroy() or removeJunk(). It continued to accrue VM until the server crashed with the following error: 2024-04-11 03:15:28.743 WARNING EDOBJECTS (Main): RegMapStorage start cycle to find empty space in <viColumn> 2024-04-11 03:15:28.743 ERROR EDOBJECTS (Main): RegMapStorage has no more IDs (4094 max) in <viColumn> 2024-04-11 03:15:28.743 ERROR EDOBJECTS (Main): Failed assert `false` at Projects\edObjects\Source\Registry\RegMapStorage.cpp:124 This effectively caps the life of any mission that creates units on the fly based on the server RAM and the RegMapStorage cap of 4094. At 1 group per second being created, we'd expect to hit this cap at ~4094 seconds, or about 1.1 hours. This is basically exactly what we saw, despite all units in those groups being both destroyed and junk removed. A working theory is that this behaviour was introduced with the Apache FCR in order to allow destroyed vehicles to still be seen by the FCR. That said, others have said anecdotally that this predates the Apache. The effect is that dynamic missions require a regular server (not mission) restart to prevent this VM saturation, on a cadence that depends on the rate at which new units are spawned by the mission, and the total server RAM. Request that ED advise or investigate a solution that allows mission editors to purge the VM allocation of "dead but still there objects" in areas that are no longer relevant to the mission to prolong the life of the mission/server. While this may have other effects e.g. rendering them invisible to FCR, the alternative (a server crash or restart) is surely not better. Log data and charts: https://docs.google.com/spreadsheets/d/1p0tKoeipHJOaChhKnzNKjLD30maU3xKCvJH5o4quBY0/edit?usp=sharing (edit: if anyone wants to help me replace the MOOSE functions with stock to eliminate that potential source of error, please do!) edit2 another data point using trigger.action.explosion rather than destroy(). Same issue. RnR_Memtest_Syria.miz update: tested a different miz with no MOOSE (thanks cfrag), which creates 7 groups per second and destroys the group rather than the individual vehicles. Same VM accrual, and right on cue at ~590 sec (4094 / 7) it starts spamming RegMapStorage full.

As in title: changing vehicles sometimes cause such things (compare clouds in IR image and 'real objects' they clip off on background) : Mission file with all necessary to replicate problem in place: CloudsDrawnOverObjects_AH64.miz Steps to do in that mission to reproduce (set#1:PNVS / set#2:TADS): 1) After mission starts: Choose A-10C Turn its TGP ON and switch its mode to WHOT Choose AH-64 Enable PNVS on pilots IHADSS, observe the bug Ir_Bug_Faster2.mp4 2) After mission starts: Choose F-16 Turn its TGP ON and switch its mode to WHOT Choose AH-64 Switch to CPG seat (pilot's NVS is fine for now) Enable TADS, observe the bug IrBugAH64 2-2.mp4 It seems like clouds overlay stencil calculated with some offset to position of sensors camera.

FDR Mbuccia does not work. Eye tracking does not work Quadviews its a downgrade with worse graphics and performance. Solved: Uninstall MBuccia DFR, then re install it , start game, and go to VR options and check Quadviews option, it gives you an extra 10 to 15fps like always with DFR, and you can adjust your focus and peripheral values to your liking. Look at this picture, this is why DFR is better than the rest, top picture is stereo all the screen is high resolution, then Quadviews, which is better, and lower is Quadviews and Foveated Rendering, even better, no wasted performance on the areas your eyes dont see.

This happens with or with out waypoints set up crazy apache.trk

I'm on mission 10 of Raven One. It starts with a queue of about 10 jets that need to take off before you. I had attempted the mission several times before the Dec 4th update, so I know it was working. After the update, now when I start the mission, there is a message about saluting on screen. Salute before startup, salute after startup. The queue of jets stalls out on the 5th jet, it starts to taxi, then stops well short of its catapult. If I turn off all the super-carrier crew options and restart the mission, the queue works. But when I ask to remove the wheel chocks, it comes back with a message "Unable to comply, air supply not connected" or something similar to that. The wheel chocks never get removed, and the mission is dead in the water. Windows 11 Steam DCS VR mode (Quest 3) Logitech X56 joystick and pedals Raven One campaign, mission 10

There is no Taxi/Ldg lights on the Remasterd F-5E. Nor with the mouse in the Cockpit nor with a Key attributed. Cheers PS: The Taxi/ Ldg light in the F5 was always very weak.

COLT 1 misses the comms tower, this happened both times I've played the mission, I ignored it and carried on the 2nd time (and dropped a spare bomb on the tower myself) but it feels a bit broken as there's no radio comms after being cleared hot. Love this campaign though, great work!

Notice this while on taxi on Sinai. I think it may be a texture layer issue.

The Nosewheel of the static F-5E model is floating. The nosewheel torque link is also disconnected.

The DCS Apache manual provides the following information about the display of wind speed and direction on the TSD page: Wind Status. Displays the wind speed and direction of origin as computed by the aircraft Helicopter Air Data System (HADS). If wind speed is computed as <5 knots, the Wind Status will display “CALM”. If the NR is <50% and wind speed is >45 knots, the Wind Status will display the wind speed in yellow. Also from the DCS Apache manual: NR is the main rotor RPM. I noticed today when flying the Apache in a MP server that the Wind Status was 303/14 while airborne and changed to CALM when I landed even though the server had a ground wind direction / speed of 303 degrees 14 knots. I landed into the wind since the landing area was marked by smoke showing wind direction. Knowing the wind speed and direction is very helpful prior to taking off. I wondered if the Wind Status displaying CALM when the Apache is on the ground, even though there is a ground wind, is a bug?

AI's never drop the external even entering an air combat situation. No track attached because it can be easily reproduced in any mission of the 'Big Show' Campaign. It is not specifically to the campaign nevertheless to the AI. Closer A/C is mine and the rest are AI wingmen in RTB after a huge air combat over France in Mission #5.

I have the following issues 1) On the way out i complete the fence in and the character says i have fenced in but the fence in message in red stays for ages and ages 2) when i RTB there is no debriefing (I get the message saying there is) 3) when i end the mission i just get a hang and have to close the DCS process to recover

Hello, The game has been crashing when attempting to join a multicrew session as CPG. It was working fine yesterday and I could join without any problems, suddenly the game crashed and I havent been able to join again as CPG in multicrew. dcs.log-20240621-135508.zip

Hello there, as the title says, its been like this for a while. It doesn't happen everytime, so in the tracks i kept locking and unlocking the target several times to demonstrate the issue. In several instances, the radar gets stuck in a "ghost" contact, failing to achieve a lock in the correct target, despite being in perfect conditions to do so. Also, there are some instances that the radar takes a very long time to lock, even against cooperative targets (non maneuvering, high closure rate, high altitude, look up situation). This problem happens in other ACM modes too, and is also happening in TWS/RWS. Helmet mode inconsistency 2.trkHelmet mode very long time to lock3.trkHelmet mode inconsistency 3.trk

This one is pretty simple... On Vehicles with Machine guns Vehicle with less than a full belt of machine gun ammunition Press Reload Goes into reload sequence Vehicle doesn't actually reload anything On Tanks Press Reload on ready rack- Goes into reload sequence Doesn't reload the ready rack

AS stated in the title. Using the specific key combination, in vr, nothing happens. So I have to guess, by cycling the ROE of the gunners, what state they are in. Is there a work around? Is it just my problem? Thanks in advance

@BIGNEWY I performed a test vs. the time-to-climb chart with the following parameters: Day = STD ISA, 15C, 2992 inHg, no turbulence, wind etc Aircraft: clean, 38000lbs when the test begins Method: Follow chart TO and climb schedule (Nose to 10 deg at TO, maintain until 350 KIAS then pitch for 350 KIAS until transition to 0.9M, then pitch for 0.9M). Time begins counting when climb speed is reached (approximately 50 sec into the track) The results show a significant deviation above 20000'. 'REF' is the F-15 MIL climb chart, the 'diff to previous' is my way of checking how badly my technique is off My table is as follows: REF alt Ref time DCS time Diff ref diff to previous dcs diff to previous previous deviation 10000 42 39 3 20000 102 102 0 60 63 -3 30000 174 196 -22 72 94 -22 35000 215 245 -30 41 49 -8 40000 260 319 -59 45 74 -29 38000lbs_MIL_40k.trk Tacview-20210314-121515-DCS-F-15-Performance_Trials.zip.acmi

I read through the other big thread on Mission 6 and decided to start a new thread since, at least for me, a lot of the issues there no longer applied. I survived the Tomcat issue on deck, had proper comms all the way through, and passed the mission fine. There were still a few non-breaking issues. It seems like tapes still don't count for final score if it is set to MAN, which is what I did, and I got 90. Also, the instructions for recovery were confusing: the kneeboard said to follow the regular DCS marshal instructions except ignore the push time and adopt Cajun's timing - 1, which in the briefing was listed as 39. However, in the mission, Cajun's push time was 44. Also, the DCS marshal instructed me to 23 DME Angels 8, but Irish also got assigned 23 DME Angels 8. I kind of put 2 and 2 together and figured that no one was assigned 21 DME Angels 6, and it would make sense for me to be there if I'm supposed to push 1 min before Cajun - so I completely ignored DCS marshal and did what made the most sense, but yeah that was confusing. Also, I suppose this is probably just DCS AI being DCS AI, but Cajun flew like a drunk UFO He'd slow down until almost falling off the sky, and then suddenly go full burner, which for AI seems to accelerate him way more than it does me, forcing a long chase. Hanging on his wing was a sweatbath! Just wanna say also that for all the issues, that was an amazing experience. The custom Case III comms are truly an immersion game changer.

Specific conditions: 1. Slot into Dynamic slot that has no waypoints set, choose F-16, ramp start 2. Manually input coordinates for STPT 1 3. TGP slaves to STPT 1 as normal 4. Create markpoints with TGP 5. Cycle markpoints and TGP will snap back to STPT 1 every time, even after CZ 6. Manually enter coords for STPT 2 7. Select STPT 2 and TGP will snap back to STPT 1 every time, even after CZ Fortunately SPI still works for weapons employment, but TMS-aft would keep sending me back to STPT 1 instead of last SPI. In standard MP slots with waypoints already loaded, everything works fine. All I have at the moment is a long MP track file with some button mashing as I was troubleshooting: https://we.tl/t-0AwNLrW6ph

test1 - Target in the open 12 o'clock #2 commanded 'engage ground targets' 2 yaws right briefly then aligns with the target and begins attack run test2 - Target in the open 12 o'clock #3 commanded 'engage ground targets' 3 acknowledges and turns right almost crashing into #4 then flies like this for some time before eventually almost hovering turns towards the target and starts the attack run. This is not situational as it repeats absolutely every time even if I change the scenario slightly e.g. move target or try different formation. And I noticed it in a normal mission that #2 was a lot more effective. #3 will just acknowledge and and turn away... Both are Veteran, Ace was the same. In more complex scenario, this makes #3 pretty useless. Tracks. WM3_doing_strange_stuff.trk WM2_still_bad_but_better_than_3.trk

The dysync with this module is unplayable in VR. It's not my rig, I fly the huey just fine. is there some expectation of fixing the terrible VR experience with this module? If not, can I get a refund on this?

The various small bushes etc on the map seem to be scenery objects instead of grass or forest, this means the grass/clutter slider has no effect on them. Additionally the LOD switch factor slider also seems to have no effect on the LODs used by these bushes.

I am pasting a screenshot where I marked which parts of the cockpit have stopped moving (red) green marked still moving as they should.