crbascott

If you want to operate KLAX realistically right now, runway 7R/25L is closed temporarily (along with two taxiways on the south side) for runway renovations. https://simpleflying.com/lax-runway-overhaul/ Below is the closure info from the current D-ATIS : RWY 2 5 LEFT 7 RIGHT CLSD. TWY H CLSD BTN TWY, G AND TWY J TWY G CLSD BTN TWY H AND TWY A TWY A8 CLSD BTN RWY 25L AND TWY A TWY H8 CLSD BTN RWY 25L AND TWY H, TAXIWAY HOTEL 5 CLOSED.

Good deal - we need some happiness - the last couple of years have sucked! 🤮

If you want to see the hours bad enough you can try looking in the registry.

The new version is supposed to take things to the next level and It should be done “right”. If the new version is going to be called a tower sim it should simulate the true actions/responsibilities/etc of a tower controller. If it is going to emulate a tower/approach scenario (what we have now theoretically), then I agree we should have all the tools necessary to perform the required actions/responsibilities. But again, whatever we get hopefully it won’t be treated as a compromise or workaround. And, most importantly, it won’t be like T!3DP where there was next version wishlist talk even before it was released.

To be honest, the things you are asking for (speed up/slow down/altitude changes) are not typically done by Tower controllers in the US for the size of airports we see in the game. I’m not sure what part of Texas you’re in, but the changes on your wishlist are done by Final Approach controllers at KDFW. By the time the plane is handed off to the Tower controller (usually 7-10nm out) speed and altitude have already been handled. The Final Approach controller has already cleared them for the Visual/ILS approach and issued a final speed requirement for separation. As Vic said, these features are available with Tracon!2012. However, as you can tell by the title, it is old and shows it’s age worse than T!3DP. Having a new Tracon version that interfaced with the new version of Tower would be the ultimate wish, but I’m not holding my breath for that one.

Are you actively doing anything else? 😀 Sure has been quiet in this other thread (over 8 months since the last image shared).

Yep, most likely a difference between Europe and US controlled airports. In the US and at the airports of the size in the game, separation is normally handled by final approach controllers (using commands similar to what you describe above) and not by the tower controllers. The only sure way to do this is to create a custom schedule that spaces out arrivals. @EliGrim's schedule builder tool can be used for that or you can learn to create custom schedules yourself.

To directly answer your question - no. @EliGrimcannot create new commands or phrases that the game doesn't already recognize. Although needed when we are handed off a plane 20 miles out, airspeed commands are not normally used by tower controllers and as such the developers did not include them. Hopefully, the next version will address this by either adding airspeed commands to our arsenal or making the tower's area of responsibility a little more realistic.

In my opinion, the game engine is very weak in handling multiple arrival runways - especially non-parallel runways. So, any attempt to duplicate a real life operational setup using multiple arrival runways would more than likely not perform very well.

Very interesting, but will the current game engine do it justice?

Since the game engine hasn’t been updated in almost 3 years, maybe Luca thought the thread might still be applicable.

The answer is the same as it’s always been. Whenever the plane shows up in the RT schedule for a new airport.

For this game engine, I think it would be better to focus on smaller airports. Two that come to mind are: KRAP - Rapid City Regional KSUX - Sioux Gateway Airport. 😀

Looks like only half of your repost might be applicable, Based on the log, he is using an integrated graphics card with 4 monitors: Version: Direct3D 11.0 [level 11.1] Renderer: Intel(R) Iris(R) Plus Graphics (ID=0x8a52) Vendor: Intel VRAM: 4165 MB

No, he’s running the non-Steam version (v1.2.78.1044ns SP3.3c). Those fallback handler error messages you see are always there. Although, you may not see them in your version. 😉

As you suggested, I will wait for your announcement to see if it is it even possible to get access to a simulator like in the video. We all know you were in "marketing mode" in that reply. But, nevertheless, me and my wallet are waiting ... one way or the other.

If what we see in the video is the ultimate measuring stick, consider me intrigued.

With turning off WiFi being the solution for some people, is FeelThere looking into the possibility that the new FeelThere website/server might be the culprit for some of these crashes?

I thought SBD was silent but deadly!?! 🤣

I was just about to reply, but you beat me to it. In my first post in this thread I mentioned that excluding terminal entries caused problems in my testing. Keep in mind there may be a caveat leaving T3 and T4 blank. At one point in the life of T!3DP, leaving a terminal entry blank meant any airline could park there. I'm not sure if this is still the case, but if you want to make sure this doesn't happen you can add XXX (or some other code that is not valid) to the terminal entry and that terminal won't get used. Note: For reference, there is an "invisible" Terminal 6 at KJFK. You can't see it in game, but it exists internally in the airport xml code. As a result, a terminal entry is required for the airport to load successfully. In this case, the dummy code WZZ is used by RT.

The issue is the kewr_airplanes.txt file. In this file, you will see the following entry for the 73H: B73H-73H-BOEING 737-800 (WINGLETS) -NARROW BODY JET The entry in kjfk_airplanes.txt, is as follows: B738-73H-BOEING 737-800 (WINGLETS) -NARROW BODY JET. When playing KEWR and using the KEWR file, 73H gets converted to B73H. There is a RT model for the B73H, but there are no liveries for the B73H in any of the RC packs. Hence, your problem. When playing KJFK and using the KJFK file, 73H gets converted to B738. There is a RT model for the B738, and there are plenty of liveries for the B738. Hence, everything is fine. It looks like the 73H change was introduced with FAOR and has been propagated to all the airports released after it. KIAD actually has the 73H in the RT schedule. I'm surprised the white plane issue wasn't discovered pre-release by the beta testers and post-release by customers. Basically, this again highlights a flaw of having airport specific airplane files in Real Traffic, a lack of cohesiveness between RT and RC, and quality control opportunities. The simple solution, until @nyergesdesign decides how to rectify the situation, is to replace the 73H entry in the KEWR file with the one in the KJFK file.

Getting stuck at 99% either means you still have a issue with your schedule files and/or there are no flights for the start time you selected. As we’ve said, a log file should tell us what is going on.

Thanks for confirming.

I know - I've created a schedule or two and my time. Local airlines don't need to be in the GA file, but that's where they belong - especially if they don't have an IATA code. If you are concluding all this based on @james143611's results, I think his issues are ultimately related to the format issues @hexzed pointed out. Bottom line - the game just needs a departure, it doesn't matter if it is in the schedule file or GA file. I confirmed this with a test that had a GA file with one departure at 09:52 and a schedule file with just four flights - all arrivals (10:21, 10:26, 10:48, 10:53). With a 10:00 session start, all flights appeared as scheduled with no issues (and I didn't even get any penalty points).

@james143611I do not have LHR so I cannot test your schedule and accompanying files. However, if you could you post your log file (...\Tower!3D Pro\tower3d_Data\output_log.txt) after a session it might tell us what the issue is. Also, I'd suggest going back to your original files - schedule, GA, terminal, etc. before starting your session. My initial suspicion is you are running into the oft-mentioned and discussed gate availability issue. Especially, since you have excluded several terminal entries that were included in the RT terminal file. However, this alone could be your issue. I tested excluding a terminal entry at KSFO and it caused the loading to freeze at 63%. Maybe at EGLL it doesn't freeze but it causes havoc with the schedule. Again, a log file will more than likely point to the issue. I don't understand what you are getting at here. With this logic, why would you ever use/have a GA file? Additionally, the GA flight is the one flight that showed up as expected. Why focus on it?