Jump to content

cbpowell

Commercial Member
  • Content Count

    15
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

14 Neutral

Profile Information

  • Gender
    Male

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Recent Profile Visitors

519 profile views
  1. Hi, everyone. My name's Chris Powell. A few of you may know me from the lengthy investigation we had into the "CTD on landing". I'm the lead developer on the DC-6 FSX/P3D project. V5-NCG was indeed our survey aircraft, and as you would imagine informs many aspects of our delivered simulation. But we elected to go with the POH values for the 8-tank configuration; it's worth noting that V5-NCG has the higher capacities but does not have the later CB-17 engines. Be that as it may, I understand now from reading this thread that there are some legitimate reasons for desiring longer legs on the plane., I think we can accommodate. If you're willing to accept the caveat that this will not be an either-or option, we can update the plane and Fuel Manager to use the 5512 gallon, 8-tank setup that V5-NCG has. Note as well: we'll retain the CB-16 engines that NCG has. Give us time to make the change and put it through testing. This alteration is not too complicated, but it does touch a good swath of stuff: UI, VC, config, code, related systems. Regards, Chris
  2. You're welcome. We want you to enjoy the plane as much as we enjoy it. There is a lot of soul in this aircraft, we think, that modern liners lack. The fuel loading issue is known and being pursued. We found that it only seems to kick in when the engines aren't running, and I still think the evidence points to an underlying glitch in the simulator itself: That said, sim glitch or no sim glitch, we're exploring workarounds to make the fuel loading behave properly. Regards, Chris
  3. I honestly don't think this is our fault; I really think this is a sim glitch. Here, let me present some additional evidence. Below is a dump of some relevant internal sim A: vars after triggering the glitch. (To get here, I've opened our fuel manager screen and banged on it for a few minutes like a madman, finally settling on a full fuel load.) (A:TOTAL WEIGHT,Pounds) = 68732.0000003 (A:FUEL TANK LEFT TIP QUANTITY,gallons) = 2160.000000 (A:FUEL TANK LEFT MAIN QUANTITY,gallons) = 3048.000000 (A:FUEL TANK RIGHT MAIN QUANTITY,gallons) = 3048.000000 (A:FUEL TANK RIGHT TIP QUANTITY,gallons) = 2160.000000 (A:FUEL TANK LEFT AUX QUANTITY,gallons) = 2586.000000 (A:FUEL TANK CENTER QUANTITY,gallons) = 2172.000000 (A:FUEL TANK CENTER2 QUANTITY,gallons) = 2172.000000 (A:FUEL TANK RIGHT AUX QUANTITY,gallons) = 2586.000000 (A:PAYLOAD STATION WEIGHT:8,pounds) = 556.000000 (A:FUEL TOTAL QUANTITY WEIGHT,pounds) = 19932.000000 Note that all eight tanks are full and the A:FUEL TOTAL QUANTITY WEIGHT variable correctly confirms that we're at a full 19,932 lbs. (We only control the individual tanks.) A:FUEL TOTAL QUANTITY WEIGHT and the top variable, A:TOTAL WEIGHT, are under sim control and are read-only; the sim is in charge of summing all cargo / pax / fuel weights and arriving at a total. 68,732 lbs is incorrect, it should be 20K lbs heavier due to fuel. Regards, Chris
  4. I've spent some time investigating the fuel weight issue and I've discovered something interesting. When I first load the plane, changing values in our Fuel And Load Manager screen does have the correct effect on A:TOTAL WEIGHT. This variable, A:TOTAL WEIGHT, is a read-only variable that the sim uses as a summation of all weights (cargo, airframe, fuel, etc.). And reflecting this, the struts sag and extend as I change fuel loading. Good so far. However, at some point of fiddling with it (many clicks), the sim simply stops updating A:TOTAL WEIGHT correctly. So the plane has the fuel, the engines are running, but the weight is not adding in...and the visual sag stops working. I gotta tell you, I think this is a sim bug and not us. We're setting the tank weights correctly, but the sim is glitching. Reloading the aircraft seems to get everything squared away. As to the effect on ground model : the one piece I removed was our custom deceleration logic, which means we've fallen back to the sim's ground friction / rolling resistance instead of our own. "Breakfree" was modified a wee bit, but turns off when leaving the idle-taxi range anyhow. What I mean is, aerial performance is unaffected by these alterations. Regards, Chris
  5. That's a reasonable question, thanks for asking. The priority now is to ensure a stable, rewarding experience for all. After getting that corrected, I'll dabble more with the ground model. I'll probably ask the same generous CTD volunteers if they're able to contribute a little time to ensure my alterations haven't re-broken the thing. Regards, Chris
  6. I won't say no to any offers for testing. I appreciate your time and energy in this matter; thank you for your help. Regards, Chris
  7. I'm delighted to hear some good news from Dick, Rick, Roberto, Adam and Mike about test 4. I'm feeling cautiously optimistic. Let's wait for a little more feedback to come in, hopefully which will confirm what we all hope. Just to summarize, we learned that the "ground model" was the culprit. The ground model in this plane overrides Z-velocity to achieve two effects: A different "ground friction / deceleration" model. A better "break-free" to allow taxi at lower RPMs. Test 4 does the following: The deceleration model is inoperative / removed. We rely solely on sim friction. Break-free is operative, but we limit its effect to every 1/8th of a second. I do not comprehend why this code was breaking in P3Dv4. After all, it works perfectly well in FSX and v3. And I scrutinized the heck out of it, looking for a coding error. My best guess is that applying Z-velocity changes too rapidly causes v4 to implode; the dual decel and breakfree calcs were, for some reason, overwhelming v4 in some manner. * That, too, is why I limited breakfree calcs to a fairly coarse resolution of 1/8th of a second. It's a bit of a hedge. I'm willing to bring that back down, once we feel confident in our newfound stability. Regards, Chris * I note that I've still been unable to ever reproduce this locally. There must still be some other ingredient that I don't know yet. Whether that ingredient is a 3rd party add-on, a sound configuration, a specific sim preference, or a weight & fuel config is yet to be established.
  8. I've just sent out a second test build to the kind volunteers. (My sincere thanks for your help in this regard.) Test 01 ensured we were building with the current 21686 P3D SDK. No difference. Test 02 disables the custom ground model (friction and momentum). I'm eager to hear back. Regards, Chris
  9. I've just sent the first test build to the folks who kindly responded to my request for testers. If you'd like "in" on the process, I'm glad to hear from you - just email me directly at cbpowell@precisionmanuals.com. I've asked all the testers to kindly keep the discussion going here on Avsim instead of email, to keep the efforts transparent and informative to all. Regards, Chris
  10. In an effort to get to the root of the DC-6 CTD issue, I'd like affected folks to work directly with me on a series of test builds to see if we can cure the crash. If you're a community member who's noted repeated, reproducible CTD issues with the plane, you're a logical participant in this testing. If you're interested, agreeable and patient, please email me directly at cbpowell@precisionmanuals.com and I'll supply you with a drop-in replacement DC-6 dll to try. No new features or unrelated fixes will be incorporated, of course. This will focus strictly on the crashing behavior. Regards, Chris
  11. Hi, Parker. DC-6 project manager here. Would it be inappropriate to ask for an update? Not at all - see my earlier posts in this thread: I get your frustration, I really do. I think you'll find, after careful perusal of the thread, that there is no concrete information behind the cause of this issue. Three fellows will offer what seems like a tantalizing hint or clue -- couatl, sound, scenery X, addon Y -- only to have a fourth person say "nope, that doesn't apply to me." We have yet to identify a single common thing shared among the subset of pilots who are experiencing the issue. That makes for some very frustrating debugging, especially when yours truly cannot reproduce the crash even once. We're going to try the 'hail mary' described in my second post, and if that is fruitless then it's going to be time for a comprehensive survey of gear, addons, preferences and drivers. Regards, Chris
  12. Hello, all. Just a status update. I've been following this topic with interest. (I'm subscribed to it, and I'm notified about every reply. I read each thoroughly.) So far here's what we know: It's related to sounds. It's not related to sounds. It's based on using the AFE. The AFE has nothing to do with it. It's related to the latest update. It's unrelated to the latest update. It involves addon ____. I don't have addon ____ and I still get it. Overclocking, hyperthreading, etc. <grin> There's definitely some black humor to be found here, and let's face it, if you can't read all 11 pages of this thread and not laugh a little, you'll truly go mad. In all seriousness, I have only one concrete idea so far. My idea is a bit of a "hail mary" and frankly, internally we don't even all agree that it matters. But I built the P3Dv4 DLLs with the P3D SDK that was current at the time (21434, I think). But P3Dv4 (sim and SDK) is currently 21686. Maybe -- just maybe -- there is some veeeeerrrrry subtle SDK difference that can cause a CTD when very particular preconditions are met. (Note that we don't actually know the preconditions yet -- to date I have still been unable to crash the sim even once, and I've really tried.) I'm going to look into making this update and seeing if it makes any difference at all. More soon. Regards, Chris
  13. I have Saitek rudders, Saitek quadrants (two), and Saitek yoke. I've never been able to reproduce a single CTD. I'll note, however, that I do not use the Saitek web drivers. I just employ the native functionality built into Win10. Regards, Chris
  14. Hi, everyone. My name's Chris Powell. I'm the lead developer on the DC-6 FSX/P3D project. "Dismay." There's no better word to describe my feelings on this matter. I and the rest of the team take great pride in our work, and to have our plane CTD in this manner is thoroughly distressing. All of our DC-6 efforts these past days have been focused on tracking down the cause of this problem. The worst thing is, we cannot reproduce the crash at all in-house. I have a saved scenario with the plane on final, and I have done landing after landing trying to replicate the crash. I've tried different permutations of hardware and mouse. I've taxied slowly around KGON (a reported problem airport) for ages attempting to witness the crash. I've landed with AFE on, I've landed with AFE off. Never once have I CTD'd. For me and the rest of the team, the plane is rock solid. That's frustrating, because I can't fix what I can't reproduce. This of course is scant relief to you who are being routinely disappointed by the crash. So far the only commonality we can identify is it seems to be confined to Prepar3D v4. Beyond this I venture into raw speculation. Here are some of our nascent ideas: Could it be a particular add-on or cocktail of add-ons that somehow affect our plane? Could it be an issue with certain sound cards (USB sound, maybe?) that causes a crash when a particular series of sounds are played in quick succession? Could it be something in our ground-model? Could it be related to add-on scenery, mesh resolution, or other graphics options? Could it require a specific set of DC-6 options to be enabled? Furthermore, what's damned peculiar is this: even for those who do witness the CTD, it doesn't happen dependably. Whatever it is, it must require very specific preconditions to manifest. And when you think about all the options, add-ons, and sim preferences that are potentially involved in this crash...ouch. For a developer, this is a nightmare scenario, I assure you. I have nothing concrete to tell you at this point, other than we are listening and we are working hard to pin this down. I wanted you to hear it directly form me so that you know your disappointment is heard, registered, and being acted on. I have one request at this point: make sure you're updated to 8418 via the OC. At least let's all get on the most current version and remove one variable from the mix. Regards, Chris
  15. Oliver, thank you for the kind words. We're delighted that you're enjoying the plane. I appreciate the information about the cut-paste errors that crept in. We'll get those corrected. And yes, the hypoxia is indeed something to be concerned about -- better read up on the pressurization system! :-) Regards, Chris
×
×
  • Create New...