Search the Community
Showing results for tags 'investigating'.
-
What it currently looks like in a vehicle. No amount of tweaking can make this look like anything decent or even remotely resembling a modern-day MBT's thermal imaging package. And what's up with our binoculars now? There was a very brief period where we had decent thermals for vehicles but that time has long passed. We've been stuck with this for ages! It's awful and un-usable!
-
Yes. I can confirm, that at least around a year ago, and at least when dropping in CCIP (I'm quite certain it was the same for AUTO though, since it would make sense), if you dropped 5 bombs with a interval of say 500', it would put bomb number 3 on the aimpoint. Doing the exact same thing today, will put bomb number 1 on the aimpoint. I don't know what's correct. In my world both make sense and are just about equally functional. As long as you know what to expect. Not sure if this change was intended or not.
-
Hello folks, I noticed a mistake regarding the cockpit textures of the F-16C. In the zip folder "F-16C-CPT-TEXTURES.zip" there are these three main files for the seat: f16c_cpt_seat_NRM.dds f16c_cpt_seat.dds f16c_cpt_seat_RoughMet.dds Unfortunately, the normal map "f16c_cpt_seat_NRM.dds" is not loaded. It is also not possible to manually assign the normal map to the livery file. I suspect that the model was not exported correctly. Can someone please take a look at the problem? Many thanks in advance. Cheers Homelander
-
Subject. I do not have any real data, but these oscillations look and feel weird when doing a basic crank maneuver. Oscillations are less violent when you are slower. Added: on 0.9M it feels nice and smooth. I think the current FCS implementation can't keep up on 1.4+. Have added second track with full stick deflection. F-18-oscillations.trk F-18-oscillations2.trk
-
I'm using the following in my ATIS script local weather = env.mission.weather local cloudCover = api.TUC.GetCloudCoverAsString(false) local cloudBase = api.TUC.MetresToFeet(weather.clouds.base) local thickness = api.TUC.MetresToFeet(weather.clouds.thickness) local visibility = weather.visibility.distance local fogThickness = api.TUC.MetresToFeet(weather.fog.thickness) local fogVisibility = weather.fog.visibility local dustDensity = api.TUC.MetresToFeet(weather.dust_density) Everything looks okay except that the THICKNESS which I'm led to believe from the documentation on hoggitworld is for the lowest cloudbase, ALWAYS reports the same amount of 656ft, regardless of the weather preset used and how thick the cloudbase is to fly through. Am I using this correctly or is this a bug? Cross posted in the Weather System bug list just in case it's not a scripting error.
-
Loadout 4xGBU12, Litening. Steps to reproduce: -Set DTOS mode -Designate a point with TMS up (i did it via HMCS) -DMS down for TGP SOI. -TMS right (area track) to ground stabilize -ICP 7(Mark) -TMS UP x2 to create mark. -press 0(M-SEL) to select that mark as active STPT -dobber RTN to exit Mark mode. -NWS to switch to CCRP -TMS down to CZ Here the TGP will CZ to the previous waypoint and not to the active one. Workaround: Make SOI a different sensor (FCR, HSD) change waypoint then CZ should behave correctly again.
-
Tried mission 8 now, and encountered a couple of problems. 1) Almost as soon as I reached the target area, my wingman reported bingo fuel, RTB, soon followed by ejecting. 2) Warrior gave me the target rundown, and was told to press spacebar to get attack briefing. But upon doing so warrior didn't say anything more. I attacked the targets on my own, and upon all air defenses destroyed he finally talked again (confirming all targets destroyed and contact JTAC for bunkers). The bunker attach was unsuccessful, since I used two GBUs for the SA-9 and grouse earlier, and of the remaining two, one missed, and one had an "aborted" status and would not release. And since my wingman already ejected I had no usable high explosives remaining to complete the mission.
-
Per title, 'TRIM' no longer appears on the ADV line while the T/O TRIM button is held and the stabs reach 12° NU. TRIM_ADV_not_present.trk
-
Hello. Hornet, when creating in the ME 14 WP or more, at least what i have done and naming the waypoints at the end like, POP UP, Runway, SA-6. (The last two are targets) All the waypoints will get those 2-3 names at random. I have created a new miz from scratch, just did it. Only single hornet and SA-6, nothing else. null null Waypoint Bug.trk bug.miz
-
investigating Radar can still lock targets while off
Maverick806 posted a topic in Bugs and Problems
The F-16Cs radar can acquire targets when NO RAD is displayed on the HUD and HMCS The simplest way to test is: Enter Dogfight Override Mode Press TMS FWD to enter BORE mode Press and Hold TMS FWD - Note HUD and HMCS both say NO RAD. Hold the HMCS Cross over a target within range for a couple seconds. The radar will lock the target while you're still holding TMS FWD. This causes issues if you're trying to lock a specific target out of a group and the radar just grabs the first one it passes over This even works if your F-16 is on the ground (although the radar stops tracking immediately) F16_NO_RAD_Ground.trk F16_NO_RAD_MultiTarget.trk F16_NO_RAD_SingleTarget.trk -
I'm having a problem with this mission. All the triggers seem to be working from taxi, takeoff, and departure but I can't seem to figure out why none of my wingman are taking off to help me? I flew all the way to sally and didn't see one jet take off or ask for taxi. Including my wingman who said he was ready to taxi. Is this a bug with one of the vehicles blocking an aircraft? The briefing has them as starting up their jets, just not taxing, so this would explain it. Any input or advice would be greatly appreciated.
-
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.
-
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.
- 58 replies
-
- 13
-
Hey, Apologies if this has been reported already, but I did a search and didn't find this one: Following screenshot is taken from the Fighter Intercept Instant Action mission. The AI wingman seems to fire AMRAAMs from station 1 and 9 even when stations 3 and 7 still have some loaded. Should this not be the other way around (because of flutter), such as with player-controlled F-16s? Thanks!
-
Hello All. I believe I have found a error in the scheduling for the FCS. As you will see in the track I provided, performing the loop when I achieve less than or equal to 270kts, I immediately loss a G. Then on the backside of the loop after hitting around 360kts, the jet added the G back. At first I thought this was just due to the alpha ramping up and down but I was incorrect. I decided to do a horizontal turn to confirm my theory and yes, after 270 knots decelerating I noticed a drop in G and alpha. You can see this in the track. I have shown my controls indicator to show that I am not moving the stick at all during this test. Now what leads me to think it is a scheduling error is that if I speed up over 270kts but do not exceed 360kts, it does not have this weird behavior. My guess is that there is a hard edge in the schedule which is causing a rapid transition. I could be wrong about it being a scheduling error, but it's a starting place to investigate. Cheer's, Panic Hornet FCS Schedule Bug.trk
-
Our current Auto Flap Up FCS implementation is using sideslip feedback to control the rudder, which I consider as a bug, because the feedback is erroneously applied to the rudder rather than to the aileron and differential stabilators. The sideslip and sideslip rate feedback should be fed to the aileron and diff-stab above 20 deg AOA, as in FCC OFP v10.7 IRL. For now, I'm seeing rudders move with sideslip changes even if AOA < 20°. Test procedure: 1. Set an extremely turbulent weather. 2. Flaps to auto. 3. Press F4 to get a closer look at the rudder 4. Check if the rudder is moving with turbulence/sideslip changes. Use active pause so that there's no lateral acceleration and yaw rate interference to the rudder. Test with AOA below or above 20 degrees. References: 1. Park, David J., "Development of F/A-18 Spin Departure Demonstration Procedure with Departure Resistant Flight Control Computer Version 10.7. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2312 2. Mitchell, Eric John, "F/A-18A-D Flight Control Computer OFP Versions 10.6.1 and 10.7 Developmental Flight Testing: Out-of-Controlled Flight Test Program Yields Reduced Falling Leaf Departure Susceptibility and Enhanced Aircraft Maneuverability. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2372 3. Simulation Model of a Twin-Tail, High Performance Airplane, NASA TM 107601, including a set of FCC OFP v10.1 block diagrams (https://ntrs.nasa.gov/api/citations/19920024293/downloads/19920024293.pdf) 4. NATOPS manual which is not quoted here but contains relevant info. According to the Directional Auto Flap Up CAS block diagram from reference 3, there's no sideslip or sideslip rate feedback in v10.1 as there was no sideslip measurements available to the aircraft. The feedbacks were only included in v10.6.1 (a test version of 10.7) and v10.7, together with the sideslip estimator. From reference 2 describing the sideslip estimator: From reference 1 describing the sideslip and sideslip rate feedback: Also from reference 1: Hronet rudder moves with sideslip.trk
-
reported S-300 Missile Flight Path Issues
Shadow KT posted a topic in Ground AI Bugs (Non-Combined Arms)
When defending against HARMs (I suspect the result will be the same against other weapons as well), the SA-10 consistently flies its missiles substantially higher than their target. Meaning the SA-10 missiles arc high, when engaging incoming AGM-88Cs (difference between missiles and target altitude increases with range). The delta can be in the tens of thousands of feet. I've attached two tracks (with stationary and mobile radars), as well as an example Tacview file. SA-10 Miss High #1.trk SA-10 Miss High #2.trk Tacview-20231118-173404-DCS-VX NTTR .zip.acmi- 20 replies
-
- investigating
- s300
-
(and 1 more)
Tagged with:
-
With the latest upgrade, the SA10 / S300 battery in the Quickstart vs RUS SAMs Nevada mission doesn't appear to correctly engage the HARMS. It tries (summary screen shows 4 were launched at the HARM), but the missiles launch vertically and don't appear to track anything or fly toward the incoming HARM. Thus an S300 is now an easy target to take out. Would be great if this could be looked at? SA10_vs_HARM_fail.trk
- 20 replies
-
- investigating
- s300
-
(and 1 more)
Tagged with:
-
So the S300 detection/tracking range is still very low...at my example it detects a F16 at ~30k ft, Mach 1,7 only at 22km and engages at 18km an that over bone flat terrain..the patriot SAM for comparison detects and engages the F16 at 52 km regardles of skill level....something seems still wrong here with the S300 Performance. S300 detection attack at 18,4km.acmi S300 low tracking distance.trk patriot SAM.trk
- 3 replies
-
- surface to air
- s300
-
(and 2 more)
Tagged with:
-
-
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
- 114 replies
-
- 11
-
- investigating
- spotting
-
(and 1 more)
Tagged with:
-
I ran into this issue working on another mission, then made this simple mission as a test to verify the problem, and the problem persisted. I asked a buddy to check it out and it was happening for him, as well. The mission has 10 aircraft in it, each with their own DL IDs. When you load into any slot and go to the MBR DIR to add other members to a preset group, you should see 2 pages of members; 8 on the first page, and 2 on the second page. Instead, you only see one page available, showing you 8 members. The last 2 members would be on page 2, but there is no option to flip to page 2. If you add an 11th aircraft to the mission and try again, you get the option for the 2nd page, and it contains 3 members, as it should. The same problem repeats itself if there are 17-18 aircraft in the mission which should overflow to 1 or 2 members on a 3rd page, but the page is not available. Mission is attached for testing. Data Link MBR DIR Test.miz
-
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.
-