-MadCat-

Select the aircraft you want the frequencies changed in the mission editor and set them as desired in the bar to the right. Currently there is no way to get those four changed in game. MadCat

Honest question, what is your qualification to be so persistent in saying it's a design flaw and the wcs is acting strange ? No offense but you're the first one to complain about the gun not working properly outside its hinge limits. Adapt to strengths and weaknesses of the weapon system you are piloting and it will do exactly what you want! MadCat

Another question in the direction if to buy or not. Call me old fasioned, but I like to have DVD copies in my shelve. Is it know to anybody if there is a DVD boxed edition coming or not ? Is case not, this is the time to hit the buy button. Thanks in advance! MadCat

In my oppinion, mapping the joystick yourself is the best thing you can do for several reasons: 1. In the process of thinking about what controls to map to what buttons/switches etc, you already learn about the aircraft and its systems. 2. You have a hotas setup tailored perfectly to your needs. 3. Once the profile is ready, the biggest part of learning is already done and you know exactly what all the buttons and switches on your joystick do. 4. It is a fun process (at least for me it is). Yes, this will take time and your first take off may be delayed somewhat. For me this usually takes some days, but I am not the kinda "quick, take off, blow s**t up" guy anyway. So far for all modules I have had the first ground engine and system runs either on the day of purchase or the next day. It is a lot fun for me to "work" my way towards the first take off. And even if you are done with your profile, you will most likey do little tweaks now and then anyway. Have had a look at T.A.R.G.E.T. already ? I know many people say it is better to not use it and modify .lua files instead. I say it is incredibly powerful and does things for me I could not achieve without. As previously said, this is my oppinion and I think putting time into that will pay off big time. MadCat

As the currently modeled plane was equipped with the SCR-552-A command radio, it's only fair to keep it like that. And to be honest, 4 channels are more than enough per mission. Departure airport, destination airport, wingman (flight), and another one as you desire or at mission requirement. Later planes were equipped with the AN/ARC-3 command radio, allowing 8 predefined frequencies. What would be fair though is to be able to let the ground crew, on friendly airfields, change frequencies. That could be implemented much like the current rearming menu. Just my oppinion. MadCat

From the F-51D Pilot Handbook: Another P-51 training manual talks about up to 10 gallons per hour of fuel vapor, depending on conditions. One more word on the 25 remaining gallons. Those are meant as a reserve, so when reaching the destination airfield you should ideally have those 25 gallons, plus the one or other gallon in the wing tanks, left. By that you also keep the ideal CG condition, though I don't know if the DCS Mustang really has a forward CG without those 25 gallons in the fuselage tank. MadCat

Hey Lib ! On the left panel above the frequency dials and indications, place the bottom middle switch in the up-position. That will connect the HSI RMI needle to the R-800L1 radio. Check the manual page 6-100 (pdf: 174), that should work out your problem. But I should mention I didn't try that myself yet, so am just quoting the manual. Greetings MadCat

The thing causing this is likely to be the numerical calculation and computing of contact forces between 2 (mostly) solid objects (ground vs. helicopter frame (reduced to these 2 for sake of simplicity)). In a numerical simulation model it's rather difficult to reach a state of absolute 100% equilibrium, so force A equals precisely force B and all movement (actually acceleration) come to a halt. What I think happens, is that the calculation is fluctuating between very small positive and very small negative values (A - B = +-0,## ) and doesn't come to settle at exactly 0. One could introduce damping of the calculations, but that would introduce delay as well and result in weird "slow motion" crash behavior, more exaggerated the higher the damping factor is chosen. We may have to deal with how it is now.

Yes, please remove it, please please please !!!:helpsmilie: For the life of me, I cannot see any purpose for that, other than giving this "wow, didn't know I had that much alcohol past night, how the heck did I get in here"- effect. At least make it optional so those who don't like it can switch it off in the options or by editing an .lua entry.

On a side note, in case of proper cold start you should have ground power connected long ago anyway. Startup on batteries only is possible but not advised. Other than that as mentioned above, the generators and engine levers not in AUTO will most likely be the thing to look for.

Another finding regarding this problem. When adding these lines: {down = 3009, cockpit_device_id = 4, value_down = 0.0, name = "Cut-Off Valve Left Engine Close", category = "Ins Engines start-up control panel and levers"}, {down = 3009, cockpit_device_id = 4, value_down = 1.0, name = "Cut-Off Valve Left Engine Open", category = "Ins Engines start-up control panel and levers"}, and same for the right valve with "3010". With 4 seperate buttons set for those new commands, I found some interesting things. First off, I can now move BOTH levers at the very same time with the Warthog's top 2 toggle switches, together with using TARGET. Previously always one valve didn't move, as if there was a delay from Warthog->TARGET->game, and only one of the 2 commands got recognized when flipping them simultaniously. Like that a lot !!! But now to the interesting finding: The original purpose of seperate commands for valve open and closed still doesn't work, it moves both ways with the same command. BUT: when I manually get the lever "out of sync" with the mouse, say the lever is in the open position, with the mouse I move it to the close position, all is fine. If I then place the switch on the throttle in the down position and thereby send the command to close the valve, as said, it moves up again in the open position. However the clickable box for the mouse doesn't move with the lever, instead it is set/remains at the closed position. So the clickable box to actuate the lever with the mouse actually does move according to the seperately set commands for open and closed valve positions. The visual model and the actual function of said valves however, does not. Just found it and thought to share this, sorry for the rather long post :music_whistling:. MadCat

Unfortunately I cannot confirm any typo, it already happens when I change just one single character in a 1:1 copy of the original .lua I feel the file either has a special signature that I'm changing when changing any value. Or the program has some place where it cross checks the values with and then disagrees on those. On a side note, all works fine with just the 1:1 copy if I don't change any value. Still worth a try, thanks for the idea ! EDIT: Tried again with Notepad++, this seems to be the first file for me, where normal Notepad couldn't do what ++ can. Problem Solved ! MadCat

Editing the Server.lua unfortunately doesn't work for me. When I edit said values to those of BS1, my cockpit view is bugged. Not only am I then limited to only 2 axis, looking up-down and left-right. But in cockpit view I spawn at like 50m AGL. Switching to external view, the craft stands firmly on the ramp as it should. This happens to ALL crafts, A-10C, P-51, Ka-50, ... , yet I just edited the values for the Ka-50 in the Server.lua Switching back to the original file, all is good again. Do I need to change anything else besides the "limits_6DOF[KA_50]" -line ? ? MadCat

Not entirely true:

This is just how I do it and may be a very personal method: [skipping all the approach to the airdrome itself, going right into final approach] I usually do a plane approach from a good 2+ km off the threshold for the briefed runway with about 700-500m altitude. Airspeed by now usually is 150 > ... > 100 [km/h]. That gives me plenty of time to allign with the runway and adjust the glide path. Yet don't quote me on the exact numbers, lots of VFR going on for me here. I then trim the helicopter slower the closer I get to the threshold and try to keep the glide slope little past the threshold. Until touchdown I keep the helicopter trimmed for slow forward flight, so I touchdown with little back pressure on the stick in case for a vertical touchdown, or just let it settle gently with collective for a slow rolling touchdown. AP-channels for bank yaw and pitch are all on, no altitude hold and no F/D. Works perfectly almost every single landing and gives a real smooth touchdown with well below 1,5g. Sometimes I don't even notice the main wheels touching down, until the nose then starts to drop letting me know main wheels have contact. F/D may be useful for very short approaches on a pad or the like. Try and figure out what works best for you. I don't think there is THE proper technique how to do it in real life. I could very well imagine each pilot doing what works best for him, hence I thought sharing how I do it. Greetings MadCat

ETA is calculated by the distance between 2 waypoints divided by the speed you set for that specific leg. In return, if you just lower the desired speed to waypoint 1, the ETA gets delayed. Don't know if there is a more elegant solution. MadCat

Just to share ideas, I personally use the FLAPS switch on the throttle for the missile modes (SAFE , SINGLE , AUTO). As the flaps in the mustang, controlled with buttons have 6 positions, I find it not too convenient to map it onto a 3-position switch. The flaps up and down went on the china-hat in my configuration. On a side note, yes I'm using TARGET. Apart from the profile switching when entering a different craft, I personally only experienced it to be benefitial using the provided programming capabilities.

Tears of joy for me, if they'd really do the OH-58D to DCS standards. I'm happy enough they do the Huey, but the Kiowa with the mast mounted sight, now that would be such a great addition to the Air-to-Ground battlefield. Pressing thumbs.

Do keep in mind, throttle and "P" are 2 seperate controls and the prop pitch handle influences the engine only indirectly. With the throttle you just set the ammount of MP you want the engine to generate. As the 51 is equipped with a constant speed propeller, the governor will then try to keep the RPM, you previously set with the prop pitch handle "P", where it was set to. I think the governor has an operational range from 1600 to 3000 RPM, but don't quote me on that I may very likely be wrong on the low end. Try it for yourself, set like 2100 RPM with the "P" handle and 35" MP with the throttle, then quickly advance the throttle to 50" MP. You should notice a slight jump in the RPM, followed by it returning to 2100 RPM. That's the governor in action, adjusting prop to a higher (coarser) pitch, in relation to the now higher power output from the engine. As WildBillKelsoe said, set RPM first to 2700, then adjust MP to 45". MadCat

That's a negative. For me all works PERFECTLY fine when in Air-to-Ground Mode, "1-dimensional slewing" is only present when switching to Air-to-Air Mode. I should mention though, that I slew with buttons programmed onto the mini stick. Do that since the first day of BS1, never had ANY issue with it. So, at least for my part, saturation of the slew axis is out of the question. MadCat

HI there! Same behavior here. When in Air-to-Air Mode, one direction seems to be locked always. When moving horizontally, vertical movement is locked and vice versa. I actually think it's supposed to be like that to make locking onto a flying target easier. That mode, I think, is primarily meant for fast moving targets in your 12 oc area, less for simple locking onto (maybe) low (slow) flying helicopters. And I can imagine, yet didn't test it myself yet, by only allowing movement in either horizontal or vertical plane, it makes it less likely to "overshoot" the target all the time. Compensate with the joystick for moving piper onto target the last few degrees. All that said, my understanding of the A-10C still is very very limited, so please correct me if I'm wrong. MadCat

Personally I had hoped for an "A" version and thereby a nice big BMW radial engine. But I will still adopt the "D" and love her just as much :pilotfly:

Hi there! Can't tell if this is correct, but if my mind serves me right, I read quite some time ago, that it's used while descending on en route flying when dumping the collective all the way isn't enough. I personally use it for that and when taxiing on the airfield, where running the free-turbine governer in low mode still provides sufficient power. That way I keep the EGT lower when on ground and save some fuel too (at least I think so :D )

What you need to understand si that "sequence" in DH mean automatic step throughout the waypoints, in DTA mean also the lines that link the waypoints. When you enter a mission, in the PVI-800, you have the 6 waypoints and the sequence 123456 My team mate Chromium found that by set the sequence, for example 121, you can obtain an holding loop, better in DH. Hope to be usefull. This seems to have done the trick :) Just tested it real quick on the runway and after doing so, the PVI-800 really computed DTAs between the waypoints. I will do a throughout flight test once time permits, but it looks promising. It didn't even come to my mind that the PVI-800 needs to be told that the sequence is 1 > 2 > 3 > 4 > 5 > 6, thought it "knows" that by default. Thank you a lot, everyone who contributed to the problem solving process :thumbup: This thread may now be used to maybe solve the other questions stated in between. Thanks for all the help, really appreciate it !!!! MadCat

That's a different story. The PVI-800 works with degrees and decimal minutes, unlike the ABRIS that works with degrees, minutes and seconds by default. You can either take the seconds from LAT/LONG from the ABRIS, devide them by 60, add the result to the displayed minutes and enter that into the PVI-800. Example: 40°38'45'' > 45/60 = 0.75 (rounded 0.8 ) > 38 + 0.8 = 38.8 > enter "0 (for the preceding +) 4 0 3 8 8" into the PVI-800. It only reads 1 digit past the secont ' for decimal minutes. Try to enter a "0" as the second digit past the ' for the decimal minute for latitude. That way you should have to enter 2 "0" before the third "0" would then be visible in the longitude display. Indicating the PVI-800 would accept a second digit without showing for the decimal minutes. In fact the second "0" will already be registered as the leading digit for the longitude coordinate. We learn, PVI-800 does allow itself some tolerances for coordinates. Alternatively to that maths thing, you can just change the way the ABRIS diaplays coordinates, to match the PVI-800. To do so: MENU page > OPTION > SETUP > UNITS > LATITIDE / LONGITUDE Now you only need to round the last 2 digits. To comment on the original question: As said, if you "vaccinate" the PVI-800 with waypoints in the mission editor, it will correctly accept its fate of being reprogrammed and compute all the DTA/DH data as expected. Yet the root of the problem remains, why does it refuse to do so, when you program it from scratch on the ramp. I can't comment on the en route AP atm, as I never really use that. Far too much enjoy flying manually myself :pilotfly: