mattag08

I'm trying design missions for a multiplayer group of 20+ players and in doing so I would like to be able to include some more realistic procedures regarding rules of engagement and the declaration of radar contacts. The idea would be to increase the difficulty of air-to-air engagements by forcing pilots to properly IFF and/or VID targets in certain cases. Is there any way in the ME or through scripting that I can create hostile aircraft that will pretend to be not hostile until within shooting range and then "go active" and lock and launch on the enemy fighters? I'm aware of some of the ROE functions and radar functions, but it seems difficult to truly make DCS consider a hostile aircraft "not enemy" until it attacks. Does anyone have any experience with trying to create ambiguous bogey contacts for friendly fighters to investigate? Were you able to create a contact that would only engage after certain conditions were met? What were the results and what techniques did you use?

Would you be willing to share your templates with the community? That seems really useful.

Yes, because you don't want them to blind you. Your night vision relies on having the lowest possible intensity of light coming into your eye. You would be blind at night if you constantly had the external lights visible to the eye. Usually some spill is very slightly visible against certain aircraft surfaces, but that's in civilian aircraft that have a very different airframe setup and light placement when compared to military jet fighters. On the aircraft I've flown (IRL) there is usually a small glare shield specifically to prevent the light from blinding the pilot if the pilot would otherwise have a direct line of sight to the light.

I understand the point of the implementation here, since you wouldn't want to fumble with the menus in WVR, but I would imagine this would also screw up people who use Voice Attack, although they seem to be in the significant minority. Personally, I don't care either way. It's not hard to know how to overcome the limitations of either method with a little practice.

I do the same. The altitude loss is on the order of about 50-100' depending on airspeed.

>(e.g 300 lbs of unusable fuel) Yeah I said that right here. Gotta read my friend. As I said, the F-14 RIO claims that there is an error in the gauge. Dunno what the manuals say.

This is not what's occurring. For reference, I am a real life commercial pilot with extensive experience and training. I've flown hundreds of hours in the F-14 in DCS at this point. I can fly the aircraft and hold an altitude. When I engage the autopilot I am perfectly level with a zero'd VSI and altitude holding steady. However, your pitch angle will always be greater than zero (some small amount above the horizon) at normal cruise speeds. The current autopilot behavior is to always zero out the pitch (commands an immediate nose down) even if you are in level flight and then climb back up to altitude after the resulting altitude loss. This is counter to every autopilot I've ever used (including older autopilots that were designed and manufactured in the same time frame as the F-14).

Can someone from HB comment on this please?

It would be nice if the F10 map could function as a bullseye reference (spider) card. Currently players must make and print their own card or have a second monitor, which excludes VR users from being able to use a spider card. All that is needed is to add another icon next to the two current grids (MGRS and Lat/Long) that is shaped like a spider web. When activated it would show concentric rings of range outward from the bullseye (preferably based on map zoom level, but as close to 10 NM as possible) and bearing lines every 10°. An image is attached to show the typical layout and information depicted. This function would allow aircraft that don't have a digital display capable of indicating bullseye to still quickly (and realistically) use bullseye format AIC and friendly fighter information during multiplayer, with very minimal development effort.

I searched before posting, but I couldn't find anywhere where someone from Heatblur actually replied to a thread about this: When engaging altitude hold with the NWS button, the autopilot immediately commands a rapid pitch down to 0° pitch and then steadily raises the nose to return the aircraft to the appropriate altitude. This occurs regardless of the original vertical speed rate of the aircraft. Even if you are perfectly level at 0 fpm vertically, the aircraft will command a pitch down and then slowly climb back to exactly the same altitude you were at when you engaged the ALT hold with NWS. This behavior runs counter to every autopilot I've ever encountered in my real world professional career in at least 7 types of light and commercial aircraft. Not saying that alone makes it inaccurate, I just find it hard to believe that autopilot laws and servo commands/gains are so differently programmed in the F-14. An altitude hold autopilot mode generally does not primarily reference the pitch attitude for servo commands, but the altitude delta, pitch rates, and vertical speed. This is fed to the pitch trim which is adjusted to drive the elevator into the correct position. I know the F-14 does not have trim or elevators, but a similar concept of adjusting the trim position of the horizontal stabilizers to compensate for altitude/VS deviations would apply. The F-14B's manual states in the autopilot/altitude hold section: "Altitude hold should not be engaged during any maneuvers requiring large, rapid, pitch trim changes because of limited servo authority and slow automatic trim rate." In the attached image, you will notice that Pitch Channel B controls the autopilot/ACL functions. Pitch Channel A does not reference Altitude Error or Altitude Rate, while Pitch Channel B does, which I believe supports my theory that altitude hold references those parameters as opposed to pitch attitude. These pieces of flight manual information seem to imply behavior much more similar to what I've experienced in my real life flying. If the current implementation is an accurate representation of how the ALT hold actually functions then that's acceptable, but absent any documentation on the autopilot programming it is difficult to believe this is correct behavior and I cannot find any public documentation that indicates that it is correct. As a pilot, the behavior seems unnatural and potentially dangerous. If someone from HB could weigh in and explain if this is a bug, work-in-progress, or accurate behavior as indicated by SMEs/manuals, I (and some of my F-14 squadron mates) would be very appreciative.

The fuel gauge has an error of up to 300 lbs. Heatblur seems to have been told by SMEs this means the engines quit at 300 lbs (e.g 300 lbs of unusable fuel). I saw a tomcat RIO state this is not correct, rather when you hit 300 lbs the jet could be empty or it could have 600 lbs remaining. Either way the implementation in DCS right now is that at 300 lbs on the gauge you are empty.

X band also works. In some cases Y seems to break, but X almost always works.

Is there somewhere we can read about the new missile API and what it will do? I don't remember any announcement on it from ED.

I see so you're seeing the bandit notch you even in pulse (sorta). I can see how ED would not have innately provided for that situation, so it makes sense. I hope it gets corrected soon.

I didn't think about sidelobes, but that makes sense. For 2, I get launch warnings from aircraft that are 100+ NM away. Pick whatever number you want, eventually there should be a cut off where the RWR can't distinguish it from background noise. For 3, I wasn't clear, but I'm talking about missiles, launches, and spikes. All things you would know have dropped off quickly. I do agree with your point about nails. One of the big offenders is the missile radar indication will continue for 15+ seconds after the missile has passed you by and is no longer pointed at you at all (180° behind the missile).

Does that work in DCS right now? I've never seen a 7 track that way, but I also may not understand the procedure.

Works on my machine. I've seen numerous complaints about the 7M over the past few months, but everything seems normal on my end. The only time the missile is trashed is when I lose lock or the bandit kinematically defeats it. Just a rough guess is I probably have similar success to the stats posted above--60 to 70% hits with ~60% kills. The AIM-7 has utterly garbage parameters. You have to be very close versus a manuevering target. Related, does anyone know whether the real missile can reacquire the target if a lock is lost and then relocked?

It was listed as items to be worked on, not fixed. Still not implemented.

What about beta? That's probably the most frustrating part of the asymmetry at the moment.

I'm curious if Mover or someone with some experience could comment on how the FLCS handles changes in stores. In F4, the flight model assumed that the FLCS automatically adjusted to maintain 1G, 0 roll rate, and zero Beta with asymmetric stores. It would also adjust to maintain this condition as stores were expended. In effect, the trim acted to command a continuous pitch, roll, or yaw rate if the pilot wished to deviate from the normal trimmed condition for some (unknown) reason. In DCS, stores configurations, asymmetry, and employing weapons cause the jet to be out of the trimmed state. From what I understand the jet should be automatically countering this with no pilot input. Is the current behavior accurate and if not is that something that will be fixed?

100% RPM is based on the design engine limitations. Because turbine engines spin at ~25,000 RPM it's pointless to show the actual engine speed, so the gauge depicts a percentage. The engine will still spin more slowly than this 100% rated RPM at high altitude for the same reasons that all engines produce less power at altitude.

I have an issue with my throttle that I have not seen in DCS prior to some random past update that I'm not able to identify. DCS will randomly not register input from my throttle for seconds at a time. Sometimes it is only for milliseconds, other times the time span is seconds long. The most obvious indications is when I attempt to slew the F/A-18C radar cursor. The TDC box will not move at all for multiple seconds and then suddenly slew across the screen rapidly. Other times it will register the initial button press, but not recognize that I've released the button and continue moving well past what I wanted. The F-16 now has the same issue. Other controls that don't require a press and hold are affected, but the effect is that the input is simply ignored and I have to press the button multiple times for DCS to finally recognize it. This is only an issue with my throttle (a Virpal T-50) and not my joystick (a Virpal WarBRD base with TM Warthog grip) or my VKB rudder pedals. When I test my throttle with Virpal's software everything appears to be working fine. I've also looked at Windows USB Game Controllers and it shows nothing is wrong. I also used a website that reports the USB polling in real time and it also shows nothing is wrong. All inputs are received and indicated in all three software programs without issue. Only DCS seems to be having this issue of not properly receiving the inputs. I noticed in the forums there used to be an input bug that was solved by deleting your saved profiles. I'm curious if there is an issue with USB bindings from the same controller with different controller IDs. In the case of Virpal, when you update the USB device firmware with a new profile it generates a new USB device ID that DCS recognizes as a completely different controller. I've done this about 3-4 times as I've tweaked my throttle's setup to my liking. I'm curious if that has had any adverse effect in DCS or if there is some obscure bug I have triggered because of it. Any help or anyone who has had this issue that can comment it would be greatly appreciated. It's extremely frustrating to fly most aircraft in DCS right now because of these input issues. Imagine trying to fly an airplane where the airplane ignores every 3rd input you give it!

The E-M graphs we have access to have the structural limit at 6.5Gs. The aircraft is capable of much more than that and as a consequence its ITR is actually much higher than reported. STR should be about correct since Ps=0 is well below the structural limit in the rate band.

The stores matter. Try it again with a clean jet. The roll rate is snappy.

Same. I think my confusion is how we got here in the first place. Did someone at ED really think the lighting was satisfactory as is? If not, why is the place holder so wildly different from what is easily observable with a quick trip to a local airport or a youtube video?