Jump to content

NickFlightX

Members
  • Content Count

    92
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

14 Neutral

1 Follower

About NickFlightX

  • Birthday 04/09/1998

Profile Information

  • Gender
    Male
  • Location
    San Jose, CA

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    VATSIM
  • Virtual Airlines
    Yes

Recent Profile Visitors

2,387 profile views
  1. Hey all, Over the past few days, I have gotten 3 crashes with P3D, 2 of the crashes were terrain.dll crashes using P3D v5.2 HF1 and the third was a graphics card error after I had updated the drivers to see if that would solve my terrain.dll crashes. The first 2 crashes happened after a view change to the external model followed by my going to translate the camera with ChasePlane. The third was already in the external camera view and then when I went to translate the camera sideways, the sim crashed. Each crash was in a different location in the world. One in Dubai, one in Australia, and one in Cuba. The only constants between the crashes were high altitude, ChasePlane and Immersion, ActiveSky, Orbx Global and OpenLC's, TOGA Envtex and Envshade, on VATSIM with Volanta and Navigraph Charts also connected to the sim. I also did some time preview to get screenshots. I had installed a scenery right before the first crash happened so I did delete that and another crash happened after that. Before 5.2 HF1, I never had any issues like this or ever had a terrain.dll crash that I know of. After one of the crashes, I redid the flight and did not go to the external camera at all in the flight and no crash happened. Any ideas would be greatly appreciated.
  2. Hey guys, Just came across this thread and thought I would leave my comment, even if it is a year late. I mainly wanted to comment about the stream. You have to know that streaming is not an easy thing. Its very hard to keep an audience entertained over a long period of time. What you saw in that first stream was my attempt to keep the audience entertained and engaged with the stream. I personally accept all the criticism I have gotten about how I acted on the stream. Looking back, yes it wasn't the best way, but I was someone new to streaming in general. The other thing I want to say is that when I was streaming, I was excited! Like I have never been more excited when it comes to simulations than to show off a product like the 787. Just like how the community gets hyped up and excited for a product to be released, I was just as excited as well for everyone to get their hands on it and fly the 787. And getting to show it early is something that is very exciting. I think thats also a part of why I acted the way I did. Even my friend who was another tester was also very excited during that stream and showing off the product. I also want to mention when you go on twitch, there is a certain vibe to some of the streams. Some are serious streams, but most are not very serious. I get that some people want a serious stream, but at the same time, thats not the most entertaining for a good amount of people and honestly quite boring to do most of the time. While I admit my stream was a little too silly for a beta stream, I still think to have a fun and entertaining stream, there is still a need to some silliness. Now, comparing me to AFP95 in mu opinion is not an accurate comparison. My stream was not an AFP95 video. I have nothing again him, in fact I know him personally and he is a great guy. But his videos succeed for a reason, being silly. I tried to be fun with that stream. I never had an audience like that and I was learning how to deal with an audience like that. I am still working very closely with QW, making videos for them as well as beta testing. I am very professional when it comes to beta testing and even work for QW doing support. Just like AFP95, dont let that one stream make your full judgment on me, that stream is not how I act all the time. If you guys have questions, please ask.
  3. Yes, I did submit a ticket with this information and have gotten a reply. I mainly posted it on here so people, for now, can avoid using this approach if in case they were going into SAN. I also added the part that you guys are welcome to contact me in case one of the devs on the forum had a question who didn't have access to the ticket system. That sorta thing. Hope it can be fixed!
  4. This is a bug that myself and a few others were testing out for 4 hours to find out what the problem was. It started with one of us trying to do a flight into KSAN and his plane bricked after departure about 2000ft in the air. (Brick means the gauges were refreshing at about 1FPS and the plane was uncontrollable, very little to no feedback from manual flight control inputs. When there was flight control input, it was also refreshing about once every second or so, was uncontrollable.) So we started testing. The original route was KSLC to KSAN as a UPS flight. So we first testing turning off the SLC scenery, that did not help. We then tried switching liveries, did not help, we tried in the pax variant, didnt help. We finally decided to try out going from SLC to a different airport, we tried MSP. The aircraft did not brick. We then tried a route from DEN to SAN and it did brick. So then we tried out JFK - SAN and it did as well brick. So then the idea came to one of us to try selecting a different approach into SAN as what do you know, it did not brick. So after going through all the approaches into SAN, we came to the conclusion that the LOC for RWY27 at SAN was causing the plane to brick right after departure. We also tested having a different approach selecting at first at SAN and then switching it to the LOC27. The second we hit the execute button, the airplane bricked. So after 4 hours of testing, we found the 747-8, pax or freight variant, will brick right after takeoff when LOC27 is selected at SAN, does not seem to matter what airport you depart from. We also confirmed it on multiple systems, which had different hardware, different set ups, different addons, etc. We also testing the 747-400 and we found it was not affected by this bug. We had heard also this happened to someone going into EDDF, so we tested that airport as well and tried out all the different approaches, but we did not get the aircraft to brick. It could be something different than an approach at EDDF for this to happen. So please be careful when flying the -8 as this bug is out there. If anyone from the PMDG team has more question, please feel free to contact me.
  5. I also got a CTD last night with ntdll.dll. And I can see from project fly that I didn't fly over any airport when the crash happened. My guess is it crashed when the auto step climb happened. Was also about 6 hours of being loaded into the plane.
  6. KSFO - ZBAA GNNRR2 AMAKR DCT LINUZ DCT NATTE DCT ZANNG DCT 49N140W 53N150W 56N160W DCT SPY DCT OFORD R341 NATES DCT KOKES B242 NK B327 BANIT B804 GIRAN T577 ABOMA B913 TERBO N222 LALET B936 KILMI B723 ODEKA T634 MAGIT R213 JMU G212 DABMA W74 SABEM G332 GITUM GIT02A 130,000lbs of fuel, about 75% payload via the FMC. Departed RWY28L Initial altitude of FL340 with a CI of 80. Had a rare crash for me on an overnighter in the -8. I was about 5 hours into the flight when I believe it was time for a step climb, and I had set the auto step climb up to work as I slept. But it looks like that may have caused the crash. Here's the crash report for PMDG. Faulting application name: Prepar3D.exe, version: 4.3.29.25520, time stamp: 0x5b2c3263 Faulting module name: ntdll.dll, version: 10.0.17134.254, time stamp: 0xa5a334d4 Exception code: 0xc0000374 Fault offset: 0x00000000000f4d3b Faulting process id: 0x1848 Faulting application start time: 0x01d453064f315074 Faulting application path: E:\P3D v4\Prepar3D.exe Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll Report Id: 66be6cbb-13a2-40d8-98f4-4ff0da34224a Faulting package full name: Faulting package-relative application ID:
  7. I think it would be cool to see some of the BBJ liveries made for the 8i like VQ-BSK, A7-HBJ, V8-BKH, A7-HHE, CN-MBH, or 9K-GAA. Also if this bug wasnt reported, for the thumbnail for the Delta livery, its actually the -400 in the thumbnail and not the -8
  8. Good call! Unplugged my PS4 controller, and that fixed it. Not sure why it started doing this now... Have always had it plugged in before.
  9. My P3D is having a weird glitch. As you can see, the windows input looks fine and smooth, but for some reason, in P3D its very glitchy, jumpy, etc. Any ideas?
  10. Ive been able to have the NGX intercept and capture and follow the ILS without tuning the freq for that runway. Just select the runway ILS in the FMC, and then when your ready to do it, hit APP and the diamonds will appear and the plane will capture and follow the ILS.
  11. Keep in mind, they say 10 years, they have been working on a lot of other projects. 777, 747, DC6, NG3. They probably havent been working on it non stop.
  12. My guess is maybe 787. If they have been working on it since 2008, then that means its not a 777x or 737MAX (MAX is probably the NG3). 2008 was before the first flight, but they could have done the model back then. Model could have been done back then. Considering how complex the 787 is, wouldnt surprise me if it took them this long.
  13. I think i might have uncovered why the fuel prog thing is happening. I am flying now and I noticed my fuel cutoff switches below the throttles are off, but the engines are still running. Note how it says fuel flow 0 as well as the first post. https://imgur.com/a/wLW2O I put the fuel switches back to on, and the fuel flow went to normal. Will update after landing if anything else happens.
×
×
  • Create New...