Commercial Member
  • Content count

  • Joined

  • Last visited

  • Days Won


Luke last won the day on August 24 2016

Luke had the most liked content!

Community Reputation

99 Good

About Luke

  • Rank

Flight Sim Profile

  • Commercial Member
  • Online Flight Organization Membership
    I belong to both VATSIM & IVAO
  • Virtual Airlines

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    Sweat Mountain, GA

Recent Profile Visitors

2,000 profile views
  1. What driver or component is throwing the blue screen? Cheers!
  2. That's a danger with distractions of any sort, whether it's a cellphone, a magazine or merely talking to a friend. Human brains (at least the intelligent ones) are wired to seek out novelty and the challenge with technology is its a constant source of new information. That's not necessarily a bad thing, just different, and we need to determine new ways of dealing with it. Considering that we have (mostly) figured out moving machines on the roads despite those who wanted them to go at 5mph preceded by human waving a red flag, I'm optimistic. And we certainly don't need laws to tell people to watch where they're going, but I suspect you already agree. :) This is just my personal opinion, but the thought of working on an assembly line for 30 years doing the same thing over and over again for days isn't a job - it sounds like torture. Society's problem today isn't that these jobs have been "taken away" from people - it's that we haven't determined new things for them to do now that they are (thankfully) no longer doing them. What's happened in your lifetime is nothing more than a continuous historic trend. At one point, over 90% of the nation's (probably the world's) population was engaged in agriculture. If you were to suggest to an educated man in 1750 that we could go to a world where less than 3% was in this field, he'd predict some combination of starvation, massive unemployment, and social unrest. And while we've had some of the latter two, when we came out the other side we had a revolution in quality of life. Nowadays, we look back at the Grange Movement and earlier notions of yeoman farmers as a quaint anachronism. One of the people on my team comes from a long line of Midwestern farmers - his father, three uncles, grandfather and great-grandfather all farmed the same patch of Minnesota soil. He's a software architect. None of his siblings have any desire to farm, and so when the brothers get too old I imagine the land will be sold, providing something of a retirement and maybe most of a modest college education for each of the grandchildren. Farming is a really hard and lousy way to make a living. So is working on a traditional 1950s assembly line. The good news is that manufacturing value-add to the US economy has been steadily growing over the past 40 years. The jobs have been shrinking, but the ones that remain are high-skilled, high-value and generally a lot more interesting. That's true across the board. Building a road 75 years ago would be a small army of men with picks and shovels and maybe a bulldozer. Now it's highly mechanized, more productive - and a lot safer. I disagree. The second example (Northwest flight 188) is pretty unrelated to technology - they could have just as easily been staring out of the window, arguing with each other or simply asleep - which is my suspicion, by the way. I think they realized they screwed up and agreed on a story that had the greatest chance of preserving their careers (which it didn't, by the way). I don't see Asiana as a simple "they relied too much on automation". The automation is what got them from Korea to San Francisco in the first place, in a far more efficient and safe fashion than if they manually flew it all the way there. The problem, as I've discussed before, is more complex - it's an issue in the interaction between man and machine. You've got a crew that has had many hours of routine, boring work having to suddenly deal with an abnormal situation in the last critical seconds of flight. The mind cannot easily switch gears in such a rapid fashion, as we've seen there and in AF447. But it's not the technology's fault; we just haven't determined the right way to ensure that when an abnormal situation is encountered, the dumb bag of meat behind the yoke has had some warning and is up to speed. I would also argue that in both Asiana and AF447, there's a strong training and CRM component that needs to be looked at and addressed. Just as we've taken huge steps in aviation automation in the past 30 years, we've also had huge advances in crew procedures and interactions and the realization that the "command" model of old is dangerously flawed - the PNF, no matter what rank, should constantly challenge and interact with the PF and PIC. I'm not certain Asian airlines have completely internalized that yet., If you look through the whole history of aviation incidents from the start of the jet era, there's entire classes of fatal events that are by and large unheard of today. Overall, it's a much safer experience. We're still going to have issues, because the human/airplane relationship has changed. The nature of disagreements with my wife has changed over the 25 years we have known each other. As our lives change, our relationship will change and our challenges will too. Overall it is still getting better (fingers crossed). Let me play armchair therapist for a moment. It's pretty obvious that you value the process as much (or more) than the result, and there's absolutely nothing wrong with that. If I want to do a pork shoulder or a brisket, there's value in getting a charcoal smoker, lighting the coals in a chimney and then tending them over a morning and an afternoon until the meat is ready. I can relax on my deck, read a book or a magazine and watch the hawks and vultures circle in the thermals. It's fun to keep watching the temperature, keeping things fed at just the right time and when (if?) the meat turns out great I know that it was my hard work that made it possible. If it doesn't, I can spend time pondering and planning what to do next. But there's other times when I just want a properly done piece of meat and I don't have an entire day to devote to it. Gas grill, timer, walk away. Technology FTW! :) You also have the advantage that being retired, you have a lot of time. It may also be a challenge filling it, so there's little opportunity cost to engaging in a less efficient mechanism. For most of us, we don't have that luxury/drawback, and so we use automation to reduce the time lost to things we don't want to do, in favor of things we do. I'm not suggesting this to convince you, by the way, just to explain why people think the way they do. From an aviation perspective, I don't care much about the process, only the results - I want to get to my destination safely, efficiently and comfortably (in that order). While some pilots still want to fly 727s doing VOR/NDB navigation or do DC-6 jaunts across the ocean with a sextant, I'm happy that this occurs in the sim and not with me on board. Enjoy your journey. Cheers! Luke
  3. That's not correct. Windows will only allocate space in the page file if the memory is being used by a process, and then forced out by memory pressure (and then only if the memory is used for data; EXEs and DLLs are never written to the page file). The fact that a process may have a 2-4GB address space doesn't mean the memory has been allocated, and if it hasn't been allocated it hasn't been paged out. I'm running 68 processes right now. 12 are 32-bit, and the other are 64-bit (which get a 7TB virtual address space). I've got just under 400TB of virtual address space, but since 99.99% of it hasn't been allocated my pagefile usage is zero (and I still have 24GB of my 32GB free). To the original poster, I'd start tracking down what is eating up the disk space. I'd be surprised if it was the page file. Cheers! Luke
  4. I admire your optimism. Security is at best an afterthought in a lot of internet-facing infrastructure; for things designed years before it's not even on the radar. Cheers!
  5. I'm just using the Windows 7 resource monitor, which you can get to from Task Manager. That should give you some clues as to what process is doing the I/O, and to what files. Cheers!
  6. That's plausible. But unless you're approaching the limits of SATA I don't see what NVMe is going to give you besides a few extra airline miles or reward points on your credit card. Do you know what the rate is? (For comparison, I'm at cruise at FL360 in P3D 4.1 and I'm reading around 32K/sec from my SSD. It's nothing. My 500GB 840 EVO can easily do 10,000x as much. Cheers!
  7. You can get the numbers yourself - have task manager and NV Inspector running and you can see that at least one core on the CPU (sometimes more) is pegged at around 100%. Even a 1070 can get pegged when you're above a solid overcast. By comparison, FSX and P3D rarely do much disk I/O; they load the textures into RAM and then don't bother with the disk again. I believe Win10 Task Manager can show you the disk traffic. Cheers! Luke
  8. I agree - and the continual challenge over the past few years has been determining a way to measure that. We started with vertical speed at touchdown, then we got distance from target landing zone on the runway. Some airlines are starting to include descent rate and stabilized approach although that's harder to measure accurately. Having the "best" landing as the one with the lowest fpm at touchdown is just wrong. The VA I belong to actually has a target speed that gets combined with a target distance from threshold. It's not perfect but it's getting there. Cheers!
  9. and are two that I know of. Cheers!
  10. It's not P3D's job to write to the DLL.XML; it's the responsibility of the add-on installers to do so properly. (This is why P3D has moved to the add-on.xml model; the risk of a misbheaving installer or uninstaller messing up the whole system is apparently too great.) The error messages aren't surprising. P3D is calling KERNELBASE.DLL with bad data and the kernel is faulting - my guess is that it's likely to do with scenery or some other component not loaded via the DLL.XML. Cheers!
  11. No, there shouldn't be. Where there should be differences in the analysis of what makes a "good" landing, there's only one authoritative source for touchdown speed - it's vertical speed until the aircraft is on the ground. In the MSFS/P3D world and you're using FSUIPC, that's offset 030C which is the vertical speed of the aircraft that is updated so long as the aircraft is airborne. It's refreshed every frame, hence my comments above. What one probably shouldn't be doing is polling the sim yourself, since that's likely to be slower than the sim's frame rate and therefore not likely to produce an accurate result. (If you're using SimConnect natively to talk to FSX/P3D, you should be subscribed to an event every frame, not 6Hz or the other options.) Cheers!
  12. Generally speaking, it's the vertical speed at the exact point of touchdown - that means the first frame where the aircraft is reported as on the ground. Its fidelity varies with frame rate. Not all virtual airlines focus solely on landing rate; others include the runway distance from the threshold which when combined with airspeed and landing rate provides a clearer picture of the overall landing. Cheers!
  13. You realize that windy just aggregates different computer models, right? That's all GFS, ECMWF and NAM are. The European suite tends to be more accurate, mostly because in the US we haven't spent enough time and money on automating the forecasts, not too much. Cheers!
  14. Okay, here I have to step in a bit. For background, in a previous job I worked for a well-known US cable channel who regularly sends their employees into landfalling hurricanes for some good old-fashioned disaster porn. Once I was on a business trip and knew I was screwed when my co-worker was two rows ahead of me on the last plane into BOS before the storm hit. :) For disclosure, I am not and have never been a met - my background was large-scale distribution of the data that the mets produced - but I was aware of the issues they faced. I agree with you in the edge cases - areas where there are specific micro-climates due to natural formations (the SF Bay area was a big one for us) as well as cases where things are right around freezing and being off by a degree or two can make the difference between two inches of snow or a bit of sleet or ice (or just rain). In those cases, having an experienced met who understands where the models don't match up to the specific locale can be useful a few days of the year. Where technology shines is in two areas - first, scale. Yes, you get sheets of observer data. The engines can get those several times an hour, crunch and replot the data. Where they get really interesting is that they can do interpolation and make estimates of the weather conditions away from an obs station - every 15 minutes I can get an obs value and forecast for any arbitrary point on the earth. Is it always going to be as accurate as a human? In most cases, yes. In a lot of other cases much better if there isn't data for that specific place - the human will have a big challenge. (As an aside, go here and take a look at the temperature, wind gust and wind speed layers. Those are updated every 20 minutes. How many humans would it take to do that?) Second, it gets smarter over time. When you're recording all that historic data, you can compare it against the forecasts and see the misses. If there's a consistent miss, it can be identified and the reasons for it analyzed, then added to the model to make it better. Each year the NHC forecast errors for hurricanes get smaller and smaller as we understand the systems and the atmosphere better. Same thing with other forecasting - the reality is that we're moving towards automated forecasting for the same reason that we move towards automated aviation - the stupid bags of meat are the weakest portion of the system. (Look here, by the way - The fully automated forecasts appear to be the most accurate.) Does that mean that the automation makes errors the human wouldn't? Absolutely. But I'll trade 100 automation-created errors over 500 or 1,000 human-caused errors any day. The best metaphor I'd use in the automation vs. human forecasting discussion is a marathon. We've got a human runner against a Porsche 911 and we've given the runner a 23 mile head start. He seems so far ahead, but he's going to lose. Cheers! Luke
  15. Keep in mind that the .NET framework version and the Common Language Runtime versions are different: The newest version of the CLR is 4.0, so your error report makes sense. Cheers!