Search the Community
Showing results for tags 'investigating'.
-
As it wasn't on-topic on the other thread about the TGP slew and HAD, I'll create a thread of my own instead. After the latest patch I've noticed that the TGP sometimes can't stay stationary on one coordinate (i.e even the coordinates in the top left corner of the TGP are slowly changing). I have double-checked that my slew controls are perfectly centered, and even so, I can observe this while the TGP is locked in point-track. From my observations this "drift" always happens in the same direction as the aircraft is moving, so if I am moving straight against the target, the TGP will drift further away on the ground, and if I am traveling towards the left in relation to where my TGP is pointing, the TGP will drift in the same direction. I have even tried saving markpoints with the TGP, flown around a bit and then cycled through the markpoints and making sure I'm doing Cursor Zero on the TGP, and I can observe that the TGP suddenly points way off the markpoints that I had placed. I have noticed this complaint from other players on multiplayer servers, so I'm not the only one experiencing this. Attaching a track-file to this post demonstrating this. F-16C TGP-bug 2.trk -
After doing some tests where I fly in a straight line towards an SA-5, I have come to a few conclusions about ECM performance in regards to the DCS AN/ALQ-184. I have attached 5 different track files from the 5 tests. I did every test twice, and the results were identical indicating that ECM in DCS is very likely to be deterministic, so I've only attached one set of tracks. During the tests I was flying at approximately FL250 at a speed of about M0.8. Test 1 - No ECM, Result: Stable lock at 75 nautical miles. Test 2 - ECM in Mode 1, Result: Stable lock at 72 nautical miles. Test 3 - ECM in Mode 2, Result: Stable lock at 72 nautical miles. Test 4 - ECM in Mode 3, Result: Stable lock at 31 nautical miles. Test 5 - ECM in Mode 3, but I only turn it on after being locked by the SA-5 and turn it off again after a lock has been broken, Result: Stable lock at 72 nautical miles. As you can see, there are a few take aways from these tests. Firstly, as most of you probably know, the difference between Mode 1 and Mode 2 is that Mode 2 will silence your radar in order to increase ECM performance, but according to these tests, it makes no difference whatsoever performance wise. Therefore there is no reason to ever use Mode 2, as it is objectively worse than Mode 1. On a similar note, in Test 5 where the Mode 3 barrage jam is manually activated in order to emulate Mode 2, you can see that it has the exact same performance as both Mode 1 and Mode 2. Lastly, there is no real reason to use Mode 1 or Mode 2 at all, as they only shorten the max range for an SA-5 to acquire a stable l ock by ~4% in exchange of decreasing the performance of, or even inhibiting, your radar. The only really effective jamming tactic is Mode 3 barrage jamming before being locked up by the enemy emitter. As soon as you've been locked, you may as well turn off your ECM to prevent home-on-jam shots as your ECM will not be able to break the lock again until you've reached a distance of within ~4% of max lock range, at which point you're pretty much out of harms way anyways. I obviously don't have any real life data on AN/ALQ-184 effectiveness against an SA-5, and since ED does not specify which variant of the Spoon Rest track radar they've simulated for the DCS SA-5 it's hard to even make an uneducated guess, but based on this test my personal opinion is that the effectiveness of barrage jamming seems to at least be within the confines of reason, whilst Mode 1 and Mode 2 break lock techniques are completely ineffective. The effectiveness of Mode 1 and Mode 2 should be increased with Mode 2 being closer in performance to Mode 3, whilst Mode 1 should have a slight decrease in performance compared to Mode 2 as a result of not silencing the radar. My guess is also that Mode 1 would have a much bigger decrease in performance against emitters with a similar frequency to the F-16CM-50s AN/APG-68V(5) radar (around 10-26 GHz according to public sources), but remain near equally effective against emitters using other radar bands as Mode 2. SA-5_TEST_Mode_2.trk SA-5_TEST_Mode_3.trk SA-5_TEST_Mode_3_Break_Lock.trk SA-5_TEST_No_ECM.trk SA-5_TEST_Mode_1.trk- 5 replies
-
- 11
-
-
-
Hey, Today, I played with the F16 Viper on a multiplayer server with Skynet. I used the HTS/HAD to locate some targets. My first target was an SA-11, so I selected it on the HAD page. I launched a HARM missile, and the SA-11 went offline. Shortly after, the SA-11 shut down and disappeared from the HAD, along with the cursor. I pressed TMS down, and the cursor reappeared from the old SA-11 position, but I couldn't select anything anymore. Additionally, the TGP slewed to a position somewhere far away (to the coast, I think somewhere near my spawn location). On the TGP, I pressed TMS Down/CZ, and after a few seconds, it slewed back to the original location. This kept happening for the rest of the flight, and I tried to deal with it. I've attached a track; it's a little long but should be okay. I think the way the SA-11 was shut down caused the problem. I believe the HAD didn't like it when the SA-11 disappeared while I still had it selected, and the SPI was constantly resetting to a random position. I hope you can help. This isn't the first time I've run into this problem, and I've tried to explain it as best as I can, but my English skills aren't perfect. Thanks! EDIT: My track has 64 KB but it says I cant upload because 50MB is the limit? I have a drive link, but I understand that you may not be able to open it. Can I send it other ways? -
I thought I'd make a new thread to carry on from the discussion at the end of this thread. As mentioned previously, I spent most of the day playing around with the USS_Nimitz_RunwaysAndRoutes.lua file, and produced the flowing test example. 19 aircraft launches using cats 2,3 & 4 only. 16 Custom spawn positions, all with custom taxi paths so as to not interfere with each other and the many static aircraft present. So far I've only tested with the F/A-18. Tomcat will take some extra work as it has some crash issues. Also, there's nothing stopping all the remaining static objects everywhere except the bow to be changed to spawn points. You could literally create a 30-35 aircraft launch sequence. I also managed to create a recovery test scenario. In the video below, I have 20 hornets recovering, and parking firstly on the bow, then between the forward elevators, and finally on the "street". This was made as a proof of concept, rather than as a polished, finished product, so some taxi routes and parking positions could be tweaked to work a little better. Also one of my "street" parking positions is skipped, hence the last aircraft disappears on landing. Again, I haven't tested the Tomcat yet either. Now, in a perfect world, it would be possible to create a number of different USS_Nimitz_RunwaysAndRoutes.lua files, for use with with different scenarios (launching on CAT 1 vs CAT 2 etc..), and the appropriate file called as needed with a trigger. Combined with something like the MOOSE AirBoss script and RedKite's dynamic static aircraft & objects, a truly dynamic carrier deck is possible, that would represent cyclic ops better than anything thus far. Unfortunately it seems this particular file is only read once on starting DCS, so at this time any changes made apply to the entire session. Regardless, it's nice to have some development in this area, even if it is rather cumbersome & time consuming.- 30 replies
-
- 17
-
-
-
For some reason, after completing the A/G tasking and you are told to hit the tanker before RTB, seems like the script stops working. I'd get told to switch to the tanker freq, then absolutely nothing. I rejoin and do normal tanking, but no triggers or radio calls. The wingman doesn't tank. I had to skip the mission to advance because I flew the long mission three times and experienced the same issue.
-
When landing, the Mosquito's tires sink into the ground.
-
![[DE] T-Bone](https://forum.dcs.world/uploads/monthly_2024_02/T-bone2.thumb.png.9e1f8431e06ba9da65a19fab50bbc7bf.png)
Possible state bug when switching the radar ELEV between AUTO and MANUEL: - In AUTO mode, targets are detected and displayed. - After switching to MAN and changing the ELEV, FCR no longer finds any targets - Reset to AUTO -> Ping again -> No results - Change again to MANUEL -> ELEV remains the same as before -> Targets are recognized again. fcr_manual_range.trk -
investigating Retarded bombs hitting short at low altitudes
jubuttib posted a topic in Bugs and Problems
After a failed strike mission I made a quick test mission to see why our bombs (tested both SnakeEyes and ballutes) weren't hitting their targets, and saw that they were landing well short. At low altitudes, where I want to be when making these strikes, the last bomb dropped hit roughly over the targeted spot, when the targeted spot is supposed to be the center of the stick. At higher altitudes it was closer, but even at 500-600 feet the center of the stick was well before the intended aiming point. The reason for why the impact point changes seems to be related to the CCIP pipper not actually being "on the ground", but somewhat above it, aiming at a spot in the air. So when you come in low, the point targeted ends up being much closer to you. As you fly over the target, you can see that the marker that's supposed to stay on where you dropped doesn't stay on the target you were aiming at, instead it's clearly closer. This happens both with and without active lasing using TGP, as well, there's no effect on accuracy. The targeting point was set near the BRT in the center of the circle. Included are some images, videos and tracks from my testing. Tracks.zip
-
There is a bug in the HOJ logic: Under some conditions, the HOJ lock will turn into an IRST lock, which makes it impossible to launch R-27 in HOJ and also means that the target tracking will break when the target exceeds the gimbal limits of the IRST. Following steps to reproduce, target needs to have high IR signature (e.g. Su-27, F-15C) 1. Non-jamming target is locked at long range. 2. Target turns on ECM, lock transitions to HOJ 3. Target turns on Afterburner before burnthrough range 4. If target is within parameters for IRST detection, the lock will switch from radar HOJ into an IR lock. Radar cannot be enforced by turning IRST off. It will just turn to memory mode and switch back to IRST. Exceeding the gimbal limits from IRST causes loss of lock. Even tough at less than 15° elevation the target would still be within the gimbal limits of the radar. Launching an R-27ER in HOJ is impossible, because for that the radar HOJ mode would be required, but the lock is stuck in IRST. Still the jamstrobe will be shown on the HDD. Only within burnthrough range can the lock turned back into a radar lock from this unwanted IRST lock. What should happen instead at step 4: Lock should simply stay radar HOJ unless manually transfered to IRST by the pilot. The following trackfile showcases the issue. Lock turns into IRST lock when HOJ target gets within IRST parameters, I cannot enforce a radar HOJ lock and when I exceed vertical EO gimbal limit by putting the target below my nose I lose lock. bug_test-20230105-212204_ecm_bug.trk -
Hello there, not sure if this could be considered a bug, but the Aim-9x behavior in the F/A-18 is questionable. I'm providing 3 tracks to help explain what the issues are. Aim9x no radar lock.trk In this first track, i acquire the target with the Aim-9x without the help of the radar, only slaved to the HMD. I put the aiming circle at the target, and press the cage/uncage button and the missile seeker is now locked into the target. Nothing wrong so far. The problem is, the moment that i take the HMD fov off the target, the Aim-9x loses the lock on the target and is slaved into my helmet again. I didn't press anything, i just moved the HMD Fov off the target. I belive that the missile should stay locked into the target, and only be slaved back to my helmet if i pressed cage/uncage button again. The way it is working now is very inconvenient. Aim9x with radar acm lock.trk In this second track, i acquire the target with an ACM mode and with the Aim-9x selected. As soon as i get a radar lock, the Aim-9x is slaved to the target the radar is tracking, no problem. Now, if you press the cage/uncage button, sometimes the missile will get slaved to the hud (but not to the helmet), and sometimes it won't. Also, when it gets slaved to the hud, if you press cage/uncage again to slave it back to the radar, sometimes the missile will fail to track the target being followed by the radar, as you can see in the trackfile. Aim9x with radar bvr lock.trk In this last track, i acquire the target with the B-Scope and the 9X selected. For some reason, it is impossible to uncage the missile into the target while looking at it with the Helmet. The missile sees the target, you get the tone, but pressing cage/uncage does not achieve a seeker lock, neither slaves it to the designated L+S. The only way to slave the missile to the radar lock, is looking directly at the hud (if the HMD is on). If you take the hmd fov off the hud, the missile will be slaved into the helmet, and unable to achieve a seeker lock. Also, by the end of the track, you will see that the missile slaved to the L+S doesn't get a seeker lock. Just hear the tone, you get that tone that indicates that the missile sees something, but isn't in the threshold to get a lock (it makes that bap-bap-bap-bap-bap sound), despite being in perfect parameters to achieve a lock. Sometimes you get a more high pitched tone, indicating that you can achieve a seeker lock, but pressing cage/uncage does nothing. Sorry if some of the descriptions were confusing, just watch the tracks to be clearer.
-
The cockpit baked dynamic reflections look good however some materials are reflecting that probably shouldn't be; specifically the door behind the flight engineer's station there's a piece of cloth(?) in the door texture that's reflecting the rest of the cockpit. It's probably easier to just remove that bit of texture rather than model a new layer just for that cloth tbh.
-
Hello i made some changes into FCR Text in order to be realistic and for players to view clearer the cursor bulls details. Right now the cursor bulls is on the last blue line so it is difficult sometimes to view the numbers there. I change some parts of the code and i make it more realistic as it is in Block 50. As you can see from the image below a move all the left side of FCR distance in miles , blue lines more left in order the cursor bulls to be between the last blue line as per real , now we can read perfectly the cursor bulls. In addition i move up and closer the M symbol and the SCAN/LOS text in order not to conflict with bulls eye ring. the code below is only for M and SCAN/LOS text For miles number and blue lines i have not find the values yet but i provide ans edited FCD symbols that should be changed for RL. kind regards Code: MFD_FCR_IFF.lua ********************************************************************************************* -- IFF addPlaceholder("IFF_ContactsKeeper", nil, nil, {{"MFD_updateMultipleSymbolsBuffer", DYNAMIC_DATA.IFF_CONTACTS}}) local IFF_Show = addPlaceholder("MFD_IFF_Show", nil, nil, {{"MFD_IFF_Show"}}) local IFF_Mode = addStrokeText("IFF_Mode", "", STROKE_FNT_DFLT_10_14, "LeftCenter", {-235, -130}, IFF_Show.name, {{"MFD_IFF_Modes"}}, {"OFF", "M1", "M2", "M3", "M4", "M+"}) addSizeClipMask(IFF_Mode, 2, 20, {{"FCR_ModeMenu", FCR_MODE_MENU_STATE.MAIN}}, {-4, 0}) -- Select label local posY = -150 addStrokeText("IFF_IntgFunc", "", STROKE_FNT_DFLT_8_12, "LeftCenter", {-235, posY}, IFF_Show.name, {{"MFD_IFF_IntgFunc"}}, {"", "SCAN", "LOS"}) **********************************************************************************************
-
My CPG and I noticed that when we both jump into an Apache and cold start the aircraft there is some weird synchronization errors with placed fire zones. When either of us creates either an NF or PF zone where the label of the zone and the dashed line of the zone initially appear normal, but when the other crew member opens the TSD and looks at the zones they suddenly are in different places from where they were originally placed. We also found that once that zone is sent over the datalink the zone is still borked for other aircraft on the net. The attached image shows what this looks like from my CPG's perspective. Please see the attached track for the testing we did on the ground with both myself and my CPG creating these zones. When another person on the net sends a zone it appears correctly on our TSD. With further testing on a different track we discovered that when I fully cold start the Apache as the pilot and my CPG enters afterwards this bug does not appear. All of the zones appear to be functioning correctly when created and/or sent over the net in a single crew state. PG_Var_bumbled_Stitchedzdy-20240418-234251.trk
-
My opening statement: As it currently stands the pitch control and stick force model employed in the DCS: Mosquito model needs review for FFB users, particularly those with Microsoft Sidewinder Force Feedback 2. They currently face an unhappy compromise; a) either they adopt a linear (1:1) control curves which renders their stick so sensitive to pitch input that it's nearly impossible to fly with any realistic precision for formation or gunnery, or, b) with even a moderate curve (say 20 to 25, which works nicely on, for example, the P-51) we are subjected to a "trim trap"; this is where we are obliged to trim artificially (i.e. beyond the aircraft operating manual values) so nose heavy to actually reach trimmed flight that it puts us unrealistically close to a virtual threshold that ramps up the virtual stick force. This causes a sudden nose down tendency - tucking - with slight airspeed increases, which, given the very low level cruising and attack profiles often employed by real-life Mosquito crews, can be the cause of loss of controlled flight into terrain; the operator is either obliged to hastily add some nose up trim or apply large elevator control displacement to correct this tendency. If the virtual pilot has succeeded in avoided collecting the ground, sea, tree or structure that the Mossie had suddenly decided was to be their perfect burial plot, they now find themselves porpoising heavily, their airspeed having now dropped in the climb to below that virtual threshold that ramps up the virtual stick force. So now they're trimmed too tail heavy and are fighting to keep the aircraft's nose down. Having generally ballooned during this process, they descend to their correct cruise altitude, pick up a bit of speed on the way down and... pass that virtual threshold that ramps up the virtual stick force again, recommencing the entire ordeal. Trying to fly formation or engage ground targets under these flight characteristics is again, rendered unrealistically difficult. In either case, flying the Mosquito is not a lot of fun, and it makes me wary of using it, and therefore it seems like a waste of money in some regards. It then colours my keenness of purchasing further modules in the future in case a similar issue arises. Let me be clear; I am not criticizing Yo-yo's work on the flight model; there are characteristics and restrictions that affected the real aeroplane here that must be transmitted to the player; my argument is that FFB users - and in particular Microsoft Sidewinder Force Feedback 2 users - are being artificially handicapped based on their gaming hardware due to a mismatch between physical and virtual ergonomics and a trim/stick force model that does not seem to account for the displaced datum inherent to FFB joystick operation. I would like to propose discussion with ED on how we could help them figure out a way adjusting the DCS: Mosquitos trim/stick force model that would not render the aircraft so uncharacteristically unpleasant to fly for FFB users, but still reflect authentic flight characteristics for all users. Question to Yo-yo; 1. Why as an FFB user is the inherent ability of an FFB stick to provide sufficient stick force to reflect those felt in the real aircraft not being leveraged? Why are FFB users subjected to the same artifice implemented to provide a spring tensioned joystick user with some controllability penalty when reaching the required threshold, when the FFB motors could be driven to provide the requisite force to restrict speed and amplitude of stick displacement? If you are an FFB user who has these issues please like or thank this post. If you are an FFB user who has NOT had these issues please provide further dialogue so that we might pin-down where and why some of us are having these issues. If you do not use FFB and are about to tell me to go buy a non-FFB product, please save your breath; there is a reason I hang on to a 20 year-old stick; having flown real aircraft I find the varying stick forces and increased AoA buffet that some aircraft give you a necessary part of my simming experience and you are not going to persuade me otherwise. If you are going to suggest I spend $1000+ dollars on a new FFB device, then again, save your breath. That is not an affordable option for me.- 62 replies
-
- 13
-
-
-
Since last big update I notice when firing Apaches gun it kill my fps in VR. If you have TADS in FLIR mode it doesn't hit hard fps but in TV mode it kills completely. Was it some change in the gun smoke/explosions? Before I could shoot gun in few meters away and it hit for few fps less. Now from 72fps to 20-30. When smoke completely disappear fps goes back. Quest 3 test.trk
-
I tried to reach optimal altitude in F-16, as displayed in ICP ( see screenshot), and i wasn't able to. Repro steps: Loadout any DI >100 (see screenshot) Take off, Full military Climb 365 CAS UP TO 0.82 M I try to keep 0.82 M as long I could while climbing I reach maximum altitude (Celling) before the indicated optimal altitude. Compare current altitude with opt altitude in ICP. I suspect it might depend on increased induced drag from last version. Best regards, NED
-
Hi guys, Try dropping a GBU-24 from high altitude, high speed at max range. Bomb never catches sight of the laser (on from launch) and never makes it to target. Regards
-
As in the title of the topic, F18, in certain conditions, can't pull up enough after 22th February 2024 update. In the attached short video, the plane crashes even if i was pulling as hard as possible with paddle, but AoA remains low. In the attachment there are also the track and tacview, the crash happens at about 7 minutes and 48 seconds Is it normal or F18 should be able to not crash? Thank you The_Air_Combat_Dojo_v1.625_RW_Close_Guns_Server_NT-20240415-012819.trk F18 crash.mkv Tacview-20240415-012826-DCS-Client-The_Air_Combat_Dojo_v1.625_RW_Close_Guns_Server_NT.zip.acmi
-
To reproduce the bug: -Join any MP server with DL donors available. -Turn on L16 -Takeoff so a donor sensor (surv or/and F/F donor) can see you. -Observe that ownship is displayed as a seperate track cocentrically with your ownship location on the SA page and on other DL enabled pages such as the radar page. The datalink should automatically filter out your own DL track and not display it to yourself. This issue only affects multiplayer. (the SA page is displaying myself to me) No track, as this is easier replicated with steps above.
-
When using the TADS to lase and store a target, and then slave back to that stored target, the TADS will no longer point at the initial location. In the following video, notice how the TADS indicated LOS on the TSD correlates with the location of the target (T04) when it is stored, but when slaved to T04 the TADS indicated LOS on the TSD shifts noticeably away from the point. This is also seen in the TDU itself where the LOS shifts several hundred meters to the right and closer. I do not have a track at this time, because I've so far only experienced it during 3 hour sorties. I shall be attempting to reproduce in the coming days and will update here. -
OpenBeta 2.7.1.71390 I am on a short final (Al Minhad RWY 27) after a mission. From the overhead break, turning short final. I am on a stabilised approach. When crossing the runway threshold, suddenly the nose of my aircraft pitches up, without me changing any inputs. I have repeatedly ran into this bug. It does not happen every time and is hard to reproduce. Today it happened at the end of a 2 hour mission, so I cannot add a track replay. Instead I am providing a video recording and my trimmed tacview of the bug. It does not necessarily happen after OHBs, but also on straight-in approaches. From what I could observe, it tends to happen after long missions. It happened to me in Caucasus and PG, on at least three different airfields with different weather conditions. It happend to at least four A-10C pilots in our wing. I talked to a former member of the 476th, and he said that this bug was happening a few years back, then disappeared after it apparently got fixed. Now it seems to be back again, roughly at the time that 2.7 was published. A-10C sudden pitch up on final.zip.acmi Please apologize the language in the video. -
The glass is missing from some instruments. The canopy has no reflections.
-
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.
- 6 replies
-
- 2
-
-
- performance
- bug?
- (and 1 more)
-
Spotting dots are very large in VR. With my Valve Index, at certain ranges, both the dot and model are rendered. In this situation, the dot can obscure the aircraft, such that I can't see the aircraft model and its heading and attitude. I'd like to see some kind of slider to reduce the dot size. Dots disappear seemingly at random based upon where I'm looking and whether I'm using no zoom, VR zoom, or VR spyglass zoom. Aircraft at ~2nm (3.5km) only have the model rendered, no dot. With no zoom, aircraft can be extremely difficult to see at this range*. The abrupt change from a huge dot to a tiny model (or vice versa) is extremely jarring. Maybe add a slider to adjust the minimum dot range? *I'm a pilot IRL and I can easily spot tiny aircraft like the C172 at 2nm
- 123 replies
-
- 11
-
-
-
- investigating
- spotting
- (and 1 more)
-
Hi there! I just got a bug where after repairing and rearming on MP my loadout completely bugged. For some reason on the WPN page there is the old loadout / before repairing & rearming/ displayed. It wouldn't let me fire my missiles. Even tried firing rockets as the WPN page shows but nothing happened because i don't have them loaded into the AC. https://imgur.com/a/PyLQdBf Thanks!
