WHOGX5
-
Posts
766 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by WHOGX5
-
-
In the DTC teaser images released by ED a couple of years ago there were options to set pretty much every single cockpit switch the way you want it for cold starts. It's been so long since then so who knows if it'll still be a feature or if it has long since been scrapped.
And I'm sceptical regarding the current cold start setup being the worldwide standard. Is it standard procedure during preflight to set every single volume knob to the maximum setting and blow out the eardrums of the pilot?
-
1
-
-
46 minutes ago, ShaunX said:
Thanks for testing.
I guess it makes sence that if you want to release countermeasures you'd also want to try an break lock !
Well, it doesn't make 100% sense as it's currently implemented in DCS. Chaff is most effective near the notch and (IIRC) the ALQ-184 as a +-30° cone fore and aft where it's effective. So when you're in an aspect where you want to drop chaff you wouldn't want to use the jammer and vice versa. I just assume that the SEMI and AUTO modes in the real F-16 are advanced enough to adapt to the aspect of the aircraft to the engaging unit, otherwise it feels like they'd be completely useless, just constantly jamming and dropping countermeasures as long as you're spiked, no matter the situation.
-
2
-
-
2 hours ago, Harker said:
I'm sorry if I'm missing something in this thread, but I don't see any info on why Pos 2 would be preferable to Pos 1, in the context of DCS. Is the SPJ working better in Pos 2? Why wouldn't I choose 60% radar range + SPJ with Pos 1, over 0% radar range and SPJ, (assuming the AMRAAM is not selected, I get that Pos 2 + AMRAAM is effectively the same as Pos 1)? Or just go Pos 1 + RF Quiet if you want to specifically silence your radar while transmitting with your SPJ (as should be the correct mech if you specifically want your radar to be silent).
Again, only in the context of DCS.It's not about wanting to silence your radar but rather it's about diverting power from your radar so you can squeeze more power into the ECM pod. So your options are to do some half decent jamming while being able to use your radar/HTS or jamming with the absolute maximum power output available to you but not being able to use the FCR/HTS at the same time.
-
So I've understood this much like @TEOMOOSE and @GrEaSeLiTeNiN has. What I wonder is if I'm in SEMI or AUTO mode and press CMS up, will I still dispense my manual PRGM 1-4? Becuase at least in the F-16 countermeasures .lua there are three programs in addition to program 1-6 which govern the SEMI and AUTO response to different threats; one is IR SAM, one old radar and one for new radars. This makes me think that we'd actually be able to have 4 different programs on hand at once in SEMI / AUTO; CMS up for PRGM 1-4, CMS Left for PRGM 6, slap switch for PRGM 5 and CMS Down for whichever program is selected by SEMI or AUTO mode.
EDIT: Typo
-
3 hours ago, Machalot said:
Can you explain what this means?
As I understand it he's saying that, in the current DCS implementation, if you turn left with an RWS brick on your FCR, the brick will move right on the FCR page to stay in the same position over the ground, or at the same coordinates, hence it's ground stabilized. However, say that you're really close to a target and you're flying towards it at a high speed, then the brick will remain stationary relative to you distance-wise on the FCR even though you're constantly closing in on it; the RWS bricks real world coordinates will change so that it maintains the same position on the display, hence it is display stabilized.
As should be obvious, ground stabilization is preferred as it gives you the correct location of the last hit irregardless of ownship maneuvering while display stabilized only shows you where the contact was relative to you at the last hit; the more your distance or azimuth to the target changes, the higher the deviation between the actual and indicated position of display stabilized returns.
-
1
-
1
-
-
On 12/18/2021 at 11:30 AM, TEOMOOSE said:
You can "lock on" bug a Data Link contact (only one at the time) on on the fcr, before your own sensor sees it. which gives you a symbology on the hud, fcr, hsd, and on the hmcs.
Just a slight correction: PDLT is set via the HSD (via TMS right on a datalink track if I'm not mistaken). As far as I know it's not possible to set PDLT via the FCR but it was a long time since I read about it.
-
The short answer is no. You can enter the time for each steerpoint by pressing 4 on the ICP, but none of the systems around it or actual calculations have been implemented yet by ED. So the closest you'll get is using the time-to-target countdown in the bottom right of the HUD and adding that, using your brain, to the current time which gives you an ETA that you can then compare with the actual time-on-station that you've set for the steerpoint.
A real pain in der poopenschaft if you ask me.
-
1
-
-
1 hour ago, Frederf said:
EXP DBS1 and DBS2 modes sweep only across the area of interest, limited by the A6/A3/A1 setting. When in DBS2 and A6 setting the antenna will not sweep the entire traverse of 120 degrees because most of the sweep will be outside the area of interest.
It's an older video (probably APG-68(V)1, green scale, solid crosshairs, introductory video for F-16C) but observe how the antenna quickly transits to the right and then slowly scans to the left covering only the patch despite being in "A6". It does not sweep fully side to side.
Ah ok, I wasn't sure about that one. In either case, shouldn't the angular velocity of the radar dish still be constant? Because as it is right now, if I set my radar to either EXP, DBS1 or DBS2 and cycle through A1, A3 and A6, the time required for a full scan will increase and decrease, hence the angular velocity of the radar dish, even though it's covering the same area.
-
3 minutes ago, BIGNEWY said:
Please confirm if this is with cbu-97
thanks
I had the same issue with the 97's. Didn't have any issues with the 87's though.
-
1
-
-
Trackfile. As you can see, everything works as it should in NORM. It's in EXP, DBS1 and DBS2 that issues start to arise.
-
5 minutes ago, BIGNEWY said:
I will run it by the team but without evidence I can not promise any change, we have to be careful not to change things based on assumptions.
thanks
PM sent.
-
2 minutes ago, BIGNEWY said:
please PM me your evidence, our data does not support this.
thank you
Do I really have to start scouring through manuals to prove that such a basic thing as being able to point the radar in any direction within gimbals limits is something that's actually possible in real life. Why on earth would any radar in the world have a +-10° azimuth setting if you can't slew it around? It functions just like the A-A radar does. If you move the cursor, you move the scan volume.
-
2 minutes ago, BIGNEWY said:
take a look at this track replay
Yes, I will concede that you managed to correct it and I no longer stand by this being an irreparable issue. Also, since it said I was in MAN mode, I assumed I was in manual mode. It seems like the MAN and AUTO range labels are reversed, hence why I couldn't change the range manually. However, the issue still stands as it is functioning incorrectly. This is not "correct as-is".
-
As per the title. Trackfile included.
-
3 minutes ago, BIGNEWY said:
When going to EXP or a DSB, you need to set the area with the crosshairs
Yes, I'm aware of that. But if the area you've selected is near the edge of your scan volume, it will irreparably break the A-G Radar. This is not correct.
-
When slewing the cursor around while in A3 and A1 azimuth setting in NORM, the scan volume does not move with the cursor. Trackfile included.
-
6 minutes ago, BIGNEWY said:
Hi
try TMS aft and let us know if it helps
It didn't help. I found some weird things though that might shed a little bit of light. If the cursor is near the edge of the FCR and you go EXP/DBS, you'll get the aforementioned issue. If you do the same with the cursor somewhere away from the edges of the display, you wont. It also seems like it's possible to move the cursor outside of the scan volume limits in EXP/DBS. It doesn't stop at the edge of the screen like it does in NORM.
-
I just went in and out of EXP and DBS back to NORM and somehow my scan volume ended up outside of the MFD. I was also unable to change range. Didn't touch any controls except the EXP/DBS OSB. Trying to change modes or go into snowplow doesn't help. Trackfile attached.
-
6 minutes ago, VFGiPJP said:
Hitting "update" button on DCS GUI Utility yields nothing, yet.
Patch is available for download.
-
2
-
-
-
In the GM radar video posted by Wags (linked below with timestamp), when he enters DBS mode the angular velocity of the radar dish changes depending on the azimuth setting. Or alternatively, the time required to perform a full scan is correct, but it's not proportional to the angular velocity in DBS.
It seems like the radar is moving relative to the zoom level of the FCR, rather than the actual azimuth setting. If you're in DBS A6, the angular velocity of the radar dish should be the same as in DBS A1, but the time it takes for a full scan should take longer as you're scanning a wider area. Therefore, in DBS A6 you should only see your radar image update during the very short time the radar dish passes the area you're looking at, and then you'd have to wait for the radar dish to rotate all the way to the gimbal before coming back and updating the area you're looking at again.
As you can see, when Wags enters DBS with the A6 setting, it takes the same amount of time for a full scan as it does in NORM A6, but instead of moving left to right +-60 degrees, it moves relative to the borders of the zoomed DBS mode, roughly +-10 degrees, yet a full scan takes the same amount of time as +-60. Thus it has a lower angular velocity compared to NORM. Then when Wags enters A3 you see the angular velocity increase, which it shouldn't, while the time required for a full scan decreases, which it should. Finally, as he enters A1 it speeds up even more to roughly the correct angular velocity.
EDIT: Also, I just noticed that the same issue applies when he decreases the range in DBS 2. The edges of the scan is still relative to the display even though the FOV narrows down, rather than being relative to the azimuth setting.
Timestamp at 7:26.
-
2
-
-
7 hours ago, FalcoGer said:
I don't think that's reasonable. You have to see the situation (read: have the game started) to plan a mission. Creating a lua file which is read when you start the game up or having special options that only allow to be changed from the main menu doesn't do it. If you have a static mission anyhow, then you might as well use the mission editor.
This isn't something that takes years of research and subject matter experts crawling through manuals and dealing with potentially classified sources and legal issues. It's simply UX and UI design. The aircraft systems already have been or will be modeled separately. The functionality is already there in the mission editor. What needs to be done is work on integrating that, and that shouldn't take years.
There is also the issue of automatically populating threats that are not available on the map for things like the F16 and probably the AH64 as well. when I get in the KA50 I see those blue rings on the abris and I wonder who put that there. I certainly didn't and the map didn't show anything so in theory no one knows about those units, but every single one is marked. That's not cool. Unknown threats should not be placed automatically but if you have intel about it, you should be able to place it manually. If you do have them on the map then automatic threat point placement may still be inhibited by the aircraft's storage capacity for such threat points and thus priority must be given in some fashion (such as by distance to the flight path).
I don't think we do. We have the JF17 with the countermeasure settings in special options and that's it. DTC includes other things. Waypoints and other points of interest (threats, hazards, checkpoints, fix points, bulls), CMDS settings, presets for comms, possibly airfield database with things like frequencies, runways, etc, datalink settings and ids, iff settings, weapon loadout, laser codes, routes, possibly multiple routes.Some of which is set up through the mission editor, some of which is set up by magic and some of which can not be set up at all.
Things like weapon loadout is automatic. iff doesn't exist. datalink is locked to the group you have in the mission editor, the best we have there is setting a group id in the A10 after the fact and that's not possible with any other aircraft that has any sort of data link. ka50 is limited to 4 aircraft on the same uhf/vhf frequency and doesn't have group ids and datalink is all set up with hard switches (read: no dtc).
Then the viggen and jf17 can have some stuff set up via F10 map points, which is the closest thing we have but it's awkward and intrusive to other people because those points are public and shared and it's very limited and of course UX sucks. No labels, no lines and rather hard to see rings, possibly brown on brownish yellow.
We don't have anything right now that is satisfactory.
You're arguing as if I said that a .lua would be the end all solution. It would be a stopgap measure. Like you said, we have nothing that is satisfactory, but having a .lua would alleviate a lot of the problems we face. And regarding the threat circles, they can be enabled/disabled for individual units in the mission editor so if things are visible that shouldn't be, that's on the mission creator. I can't speak for every airframe as I pretty much solely fly the F-16, but the reason that threat circles can't be added or removed in the F-16 is that they haven't been properly implemented threat yet. Every threat circle should be tied to a steerpoint, but as it is right now, they just magically appear.
4 hours ago, Tippis said:We also have the Viggen DTC, the auto-generated and -populated settings in the F-16 and F-18 (and MIrage, to a lesser extent), the kneeboard-driven interface of the Harrier, the “prepare mission” feature of the A-10 and Ka-50, and a myriad of inconsistent kneeboard and ME settings that, while not all of them are actually handled by a DTC system, should be consolidated into the same kind of UX/UI setup.
Like I said, we already have something. That something is already a heterogeneous mess of bespoke solutions. Adding more to that mess isn't “infinitely better than what we already have” because it is what we already have. And, pretty much by definition, it's a mess — it doesn't become better by becoming more. So the only real actual improvement is to make it a centralised API and UI that everyone hooks into. Asking the individual module makers to implement a solution will not make things better, just more, and will make the eventual move to a working solution far more painful and more unlikely.
Would it be far more painful than waiting for a DTC for an entire decade, ever since the release of the A-10C, before DCS World even existed? Going in to the sub menus every single flight to setup the exact same settings for years on end? Because that's what a lot of us have been doing. It's not like creating a .lua, that changes values in other .luas that already exist, would take thousands of man hours to implement. It would be an incredibly bare bones, temporary solution that'd give third-parties something to work with, and I'd be surprised if it took more than a couple of weeks for all the DTC options to be implemented into something like CombatFlite.
And I don't agree with your opinion that implementing a stopgap like this would decrease the likelihood or increase the difficulty of implementing a proper solution. Lately it has become quite apparent that ED wants to implement something akin to the Joint Mission Planning System. That's great, but it's gonna take a long time to make. A few years ago ED released pictures of an entire DTC menu covering pretty much every setting you could possibly want to set in an aircraft, even switch state when starting cold. That system could've been rolled out ages ago if it weren't for the JMPS. At least that's my analysis of the current situation.
The reason a JMPS system would take such a long time to implement, is that it covers all things related to mission planning and is way beyond a DTC in scope. If they pull it off, the JMPS should cover everything from simply placing steerpoints to providing fuel and drag calculations, climb profiles, calculating weapon delivery profiles, etc; pretty much anything that relates to the mission planning process. All these things would have to be worked out for each air frame in the sim That's why some sort of stopgap measure, like a .lua, would be a great interim solution.
Even in a controlled environment like a DCS community there is so much time that has to be spent and so many hoops that have to be jumped through in preparation for each mission, simply because we're 100% reliant upon the .miz file. Every single thing you want to set, from steerpoints to radio presets to laser codes, has to be set in the mission file itself unless you want to input everything manually and drastically increase the risk of something being input incorrectly. And that doesn't even cover the things you can't set in the mission editor, like countermeasures, MFD setup, etc. So a JMPS would be better than a .lua, but a .lua would be infinitely better than having nothing at all for the foreseeable future.
-
5 hours ago, Captain Orso said:
Hi all you aces. I don't fly the F-16 - yet - but I have a kind of a survey question.
When you enter a waypoint, either through LatLong or MGRS entry, once the LatLong or MGRS has been entered, is the ground level elevation of the waypoint already entered for you, or do you have to reference it from somewhere and enter it manually in addition and subsequent to the LatLong or MGRS coordinates?
Many t(h)anks in advance
You have to enter elevation manually. You can find the elevation using the mission editor, F10 view, CombatFlite, etc.
-
I think the real missed opportunity would be to model a two-seat F-16. Simply making an F-16D Block 50 or even an export variant with a PW engine like the F-16D Block 52+ would take much less effort than making something like an F-16A or early F-16C, yet add a whole slew of new capabilities, especially an F-16D 52+: AN-APG-68(V9), internal ECM, CFT, WSO, LANTIRN, etc.
This would also be the first combat capable "trainer" in DCS. The only other two-seat fighter we have is the F-14, and it's not very well suited for teaching new pilots how to fly or taking people along for incentive rides since you can't really fly the F-14 as a single seater. A two-seat F-16 would allow new pilots to practice everything from takeoff and landing to A-A and SEAD together with someone experienced. Not to mention taking potential DCS customers along for an actual mission where you're not merely watching a youtube video, but you're actually there. You get to experience everything first hand and feel what it's actually like.
-
4
-
CMS Operation
in DCS: F-16C Viper
Posted
To each his own, but that's what I'm planning on doing. The only thing I'm unsure of is that the ECM seems to be implemented in a way so that you can't have radar priority in MAN mode, only ECM priority (radar gets silenced). I've been out of town since the last patch released though so I haven't had the opportunity to try it for myself. The way I have my CMS set up is PRGM 1-4 for regular chaff as well as pre chaff/flare, CMS left for my flare program and slap switch for emergency chaff and flares. However, if I can only use radar priority in SEMI / AUTO, then I'll use SEMI and just set the program to drop zero chaff/flare and drop them manually using PRGM 5-6 instead.
Another reason why using SEMI isn't a good idea is that when you're within, as an example, approximately 25 nm of your target you usually want to turn your ECM off as modern missiles can home on jam and there's no point in blasting your ECM within burn-through range of the enemy radar anyways as that just gives your position away. But turning off your ECM with CMS right will also remove consent for the SEMI mode. So your pretty much stuck between choosing between ECM and chaff or no ECM and no chaff. As it seems there's no in-between in the current implementation.