This isn’t a bug report, just a place to say in order to utilize the Tornado IDS G in BMS 4.36, I am modifying the game files to add features to the cockpit, especially the 3dButtons.dat file. Currently there is no way to adjust the IFF master knob or toggle the landing light by mouse interaction for example. Additionally things like the HSI course and heading knobs lack mouse wheel support which isn’t strictly necessary but makes it more useful.

If anyone has done similar work or has ways to get easier 3d positions or has ways to add animated switches and dials that would be appreciated.

Voice-assist programs surely count pages but don’t actually read the screen. The pages could be decluttered so as to remove the page options without skipping any pages. A page without any options would still be in the rotary but instead be blank/minimum size. If options 1, 5, and 7 were the only available then the page could be only 3 items tall. If lists and boxes can be variable height and contents it might be worthwhile for decluttering purposes.

As for having all options available at all times, it’s interesting from a realism point of view. Certainly you can say anything at any time. It would be necessary for the AI to respond in a reasonable way to “wrong” messages which were previously impossible. DCS for example simply doesn’t respond at all if you are 1mm outside of the pre-takeoff area and that’s extremely frustrating and confusing. I would certainly hope that if all-message-any-time is implemented that at least a simple reply message is used to indicate some kind of feedback.

I don’t particularly mind either way if one can gain “magical information” about the ATC system based on whether option is white/gray. ATC is necessarily simplified because the controller is not a thinking human. This could have other consequences though tactically like A-M-T which is gray/white depending on if player sensor is over valid target or not. I don’t know if any of that gray/white magic information could be considered cheating but certainly removing that information puts a bigger burden on the player to know the system inside and out.

Ah I can think that checking for wingman reply and seeing all gray is a cheating way to know he is shot down. That’s kinda lame and it would be nice not to know that info magically.

@Carbide The POV1DeviceID is the order the device as it appears in the dropdown menu inside the game, e.g. Keyboard, Joystick, Throttle, Pedals. In this case Keyboard = 1, Joystick = 2, Throttle = 3, Pedals = 4, and so on. POV1ID is which POV from that device to use. In that case the 0 is the first POV, 1 is the second POV, 2 is the third POV, and so on.

For the Warthog Joystick as second in the list (after Keyboard) and Warthog Throttle as third in the list to be assigned as POV1 and POV2 respectively you want the following:
0th POV from the 2nd device is assigned to POV1
0th POV from the 3rd device is assigned to POV2

set g_nPOV1DeviceID 2
set g_nPOV1ID 0
set g_nPOV2DeviceID 3
set g_nPOV2ID 0

@gryfinoxx From memory TOS calc is right. If you ignore caret and fly to make the clock right then you’ll arrive on time. By the way it’s not sufficient just to show up on TOS. You want to hit the TOSs at the scheduled groundspeed. If you do both at those together then the caret won’t jump on steer passage.

E.g. if you’re supposed to show up at 0900:00 with 480 GS and you’re on schedule to arrive on time but at 510 GS then you’re behind schedule. Fly faster or slower to “massage” your RGS to scheduled then resume matching predicted TOS. Then you’re both on time and on speed.

@jstnj LMFD: FCR/WPN, RMFD: TGP. Use FCR to initially cue TGP working left to right screen. Then when object in TGP, DMS cycle to WPN working right to left screen.

Towns have a few small buildings which are lockable. You learn which ones pretty quick.

When you get TGP roughly on target, TMS right for area and slew near it. Don’t point track it yet. Then DMS over to WPN SOI and slew to track the missile. Repeat for both stations when practiced enough to do it rapid.

Once 1 or 2 missiles are tracking, then DMS SOI back to TGP and point track the object the missiles are tracking. Click OSB BSGT for each station.

It does mean “precision guided munition” even in the HAD context. It’s “PGM-quality.” It’s possible for position quality to be inferior to PGM5 in which case no label is shown.

The way DCS does it is really nice. If you have a modified file and run an update it will make a copy of your custom file and put it in a backup.001 folder. That’s saved my butt a few times. If practical having the installer check for files which are modified and making backup copies in that way would be a nice feature.

1. With the .key you mentioned it is intended that you use china hat forward/back as the digital control for antenna elevation. That means your antenna elevation is by button presses and you won’t be setting any axis for it.

3. There’s no exact need for the drivers but it’s easy to do and provides a little more natural support. It’s a DX controller which is a standard that should work without any specific software. That’s different than TARGET which is a profiler software which will require effort and is only needed if you want to use it. Install the drivers, skip TARGET unless you want to do Foxy-type programming.

@semlerpdx Yeah absolutely. Although currently what happens when you pick a number option that corresponds with a grayed out option currently?

Direct callbacks (or similar direct API) for every single radio options would be amazing. Then voice-interaction software could skip the whole middle man segment.

@billsirkill The gun only fires when it is selected which only occurs in 3 conditions:
AA master mode, GUN submode
DGFT override mode
AG master mode, STRF submode

Missile override is notably not one of the modes where the gun is selected. Shooting an AIM-120 (the only missile currently in the medium-range category) depends on all sorts of pre-conditions for launch.

HAS is a kind of anti-radar Maverick. You see exactly what’s happening, right now, and attack directly in a first person way. You’re “LOBL” and it’s the most positive targeting possible. It’s only really superior in situations where you dominate the situation and making sure you hit exactly what you want and it’s active.

HAD is a little less immediate and direct. There’s an abstraction where position isn’t exact and it’s more LOAL (although I think they can see an active on the rail LOBL-type). There’s a lot more situational awareness and flexibility. In most situations, especially longer range SAMs the HAD is superior.

I think this might be intended. The calculated pipper is lvl 5 and based on target acceleration. The EEGS funnel is a pure history device so may not have settled to current maneuvering parameters. You should be able to put the pipper on target and as long as parameters are constant the funnel should settle to agree in a time range of 0.5-1.5sec.

Usually these kind of systems take localizer time rate data into account when providing command steering. I believe BMS is simply comparing heading and localizer deviation to course. E.g. when loc deviation is zero then it’s making command heading equal to localizer course. That’s obviously not the best command when crosswind is present. What you’re getting is a balance of factors where you’re getting a constant deviation solution not at zero deviation. You’re downwind which is providing some upwind steering command but not enough to get back to loc center, just enough to settle in a constant downwind loc position. If you were in a position of more deviation steering would act to reduce deviation but if you were more central steering would be to increase deviation.

In this kind of system normally the steering command is proportional to deviation, integrated deviation over time, and possibly derivative of deviation. That’s your classic PID controller where P is the simplistic “if left go right”, I is the integration “we’re still not getting there, go right harder”, and D is the “we’re getting there too fast, go right weaker.” Practically the command steering cue position should not overlay on the FPM unless two conditions are met: localizer deviation is zero and localizer deviation rate is zero.

Honestly it looks like this is coded based on heading and not on track. I can’t imagine how this would happen in a track-based calculation. A function of deviation and deviation rate spits out a correction. If correcting to the right steering cue moves right of FPM. Pilot flies a new track, values change. One thing that usually goes with these systems is a gain factor based on proximity to the localizer or the sensitivity keeps increasing as you get closer which can be bad. Sometimes it’s a timer after joining glideslope or radar altimeter, neither is flawless but they’re better than nothing.

In general that’s correct in that the man range knob affects the GM gain by about 20% of the scale (so-called fine control) and it also changes the zoom of the TGP. What may not be correct is this happening all the time regardless of SOI. I’m pretty sure it’s correct that TGP zoom only occurs on TGP SOI when manipulating the MAN RNG knob. What’s probably also true and not being simulated is GM fine gain only happening when FCR is SOI. I’d have to look it up.

It does mean “precision guided munition” even in the HAD context. It’s “PGM-quality.” It’s possible for position quality to be inferior to PGM5 in which case no label is shown.

Oh that’s a very nice tool. Does it also load the 3d model? Finding the intersection of the mouse cursor LOS with the 3D model would be excellent. You’d basically just click where you wanted a switch and get the coords. That’s better than my guess and check method.

This isn’t a bug report, just a place to say in order to utilize the Tornado IDS G in BMS 4.36, I am modifying the game files to add features to the cockpit, especially the 3dButtons.dat file. Currently there is no way to adjust the IFF master knob or toggle the landing light by mouse interaction for example. Additionally things like the HSI course and heading knobs lack mouse wheel support which isn’t strictly necessary but makes it more useful.

If anyone has done similar work or has ways to get easier 3d positions or has ways to add animated switches and dials that would be appreciated.

@Carbide The POV1DeviceID is the order the device as it appears in the dropdown menu inside the game, e.g. Keyboard, Joystick, Throttle, Pedals. In this case Keyboard = 1, Joystick = 2, Throttle = 3, Pedals = 4, and so on. POV1ID is which POV from that device to use. In that case the 0 is the first POV, 1 is the second POV, 2 is the third POV, and so on.

For the Warthog Joystick as second in the list (after Keyboard) and Warthog Throttle as third in the list to be assigned as POV1 and POV2 respectively you want the following:
0th POV from the 2nd device is assigned to POV1
0th POV from the 3rd device is assigned to POV2

set g_nPOV1DeviceID 2
set g_nPOV1ID 0
set g_nPOV2DeviceID 3
set g_nPOV2ID 0

@regev said in AGM-65G problem : only lock structure and ignore vehicles:

@Raptor said in AGM-65G problem : only lock structure and ignore vehicles:

Have you boresighted the missiles first?

i was in vis mode. how can i do this ?

You boresight against SPI if not using TGP so just get the TD box over the same target as the missile best you can (visual by HUD, with FCR, etc.) and select BSGT.

Centroid track struggles against small angular size targets. You’ll be able to track large objects farther than small objects at the same FOV setting.

I have no idea. Here are my config files (2). When I delete the POV lines from the standard file the POV behavior changes.
https://www.dropbox.com/s/7qtfjk3nqfodo08/Falcon BMS User.zip?dl=0