Updated Honolulu scenery announced for P3D v4 , v5 (&MSFS)

[virtuali 4,419]

On 5/29/2020 at 3:56 AM, OzWhitey said:

Actually looks pretty ugly to me.

First pic has some terrible landclass roads right near the airport and the water masking near the runway looks very non-realistic.

Second picture shows some pretty good taxiway textures but otherwise unimpressive - how about some grass or something in your promo shot?

Someone needs to do a decent photoreal rendition of Hawaii a la TrueEarth.  

Failing that, FSDT really should do something about the terrain, masking and objects around the airport, just like we see from a lot of other top-tier developers these days.

 

It’s called WORK IN PROGRESS for a reason, it’s not done. Do you really think it would be released without a proper water mask, wrong roads and without 3d grass ?

 

[OzWhitey 3,353]

5 hours ago, virtuali said:

 

It’s called WORK IN PROGRESS for a reason, it’s not done. Do you really think it would be released without a proper water mask, wrong roads and without 3d grass ?

 

Hey Virtuali, I am just reacting to the comments here and the linked post on FS Elite by giving my opinion.

The link says: "Simultech has shared on their Facebook page two previews of their upcoming Honolulu International Airport (PHNL) under Prepar3D V5. The first screenshot shows an overview of the airport, showcasing the blending with the surrounding terrain as well as a nice transparent seabed."

As it is claimed that this is "showcasing the blending with the surrounding terrain" and the water around the airport is also mentioned as a feature, I have specifically commented on these, and I'm not impressed by either.

Seeing we're talking, here's another piece of feedback from a perennially prolific purchaser of prepar3d products - it's time to move on from Coautl. Modern addons for Prepar3d should be in accordance to best practice, which is using the .xml add-on method. I don't want a bloated P3D v5 install, but if I want to use an FSDT airport for an occasional flight I am stuck with couatl running in the background every time I run the sim.

Does it matter? Well, I weakened and installed GSX2 last week, and my sim is less stable now than it was. I can't prove that there's a causal link, but my experience has been similar in the past, and conceptually I don't want any addons that introduce unnecessary complexities into a sim that isn't perfect in terms of stability in the first place. 

I don't think I'm the only one who would be much more likely to buy an FSDT product like the new PHNL if you did what Flightbeam did and ditch couatl for a stand-alone addon manager that doesn't interfere with the running of the core sim.

Cheers!

 

 

 

[Twenty6 692]

16 minutes ago, OzWhitey said:

I don't think I'm the only one who would be much more likely to buy an FSDT product like the new PHNL if you did what Flightbeam did and ditch couatl for a stand-alone addon manager that doesn't interfere with the running of the core sim.

I've got to agree. It's the reason I've bought other developers over FSDT. KORD and KLAS as example.

[warbirds 555]

So the current Hawaiian Islands set is not compatible with V5?

[pgde 571]

5 minutes ago, warbirds said:

So the current Hawaiian Islands set is not compatible with V5?

Works fine although looks a bit dated since they pre-date v5.

[pgde 571]

48 minutes ago, OzWhitey said:

Seeing we're talking, here's another piece of feedback from a perennially prolific purchaser of prepar3d products - it's time to move on from Coautl. Modern addons for Prepar3d should be in accordance to best practice, which is using the .xml add-on method.

FSDT airports all use the xml add-on method as prescribed by LM. Are you confused?

Edited May 30, 2020 by pgde

[virtuali 4,419]

2 hours ago, OzWhitey said:

As it is claimed that this is "showcasing the blending with the surrounding terrain" and the water around the airport is also mentioned as a feature, I have specifically commented on these, and I'm not impressed by either.

You commented about:

- landclass roads

- missing 3d grass

- a bug in the watermask exclusion

My reply was just related to these comments. It should be obvious these are very marginal things that is totally useless to show as complete in that kind of preview. Again, would you really think we would release a scenery of PHNL that kills Ford Island ? Or, considering we always had 3d grass in our sceneries for years, do you really think that, for some reason, PHNL won't have it ?

 

Quote

Seeing we're talking, here's another piece of feedback from a perennially prolific purchaser of prepar3d products - it's time to move on from Coautl. Modern addons for Prepar3d should be in accordance to best practice, which is using the .xml add-on method.

We were the first developer to ever use the P3D BEST PRACTICE of the add-on.xml method, since we are using it since June 2017, the same day P3D 4.0 was released.

Back then, we were accused to be the weirdos because everybody else used the old scenery.cfg method. Now, after 3 years, everybody use it because, of course, it was the right choice.

 

Quote

Does it matter? Well, I weakened and installed GSX2 last week, and my sim is less stable now than it was. I can't prove that there's a causal link

You can't, because that's simply not possible.

I'm fairly sure you also have installer OTHER add-ons that are causing this, since several of them are very well known to cause instabilities and their are openly presented as BETA, and the whole simulator is not very stable right now, because of the issues with DX12 memory handling.

And that's precisely the reason why, the only potentially dangerous thing we have in our software module, that is the "Render to Texture" feature which in P3D 4.5 used DirectX11, is completely disabled in the P3D V5 version of the Addon Manager. 

- An external .EXE CANNOT CRASH THE SIM. Couatl is an external .exe so, it CANNOT crash the sim.

- Every add-on that is a .DLL CAN crash the sim. Either as a module, or as an airplane .GAU. How many of these you have installed ? How can be so sure none of them is the one causing "instabilities" ?

- Yes, we have a .DLL too, the Addon Manager, and the ONLY "dangerous" thing it used to do ( DirectX ), is just not there in the P3D V5, because we are waiting for the next Hotfix, to be sure nobody could accuse GSX to crash the sim.

 

Quote

, and conceptually I don't want any addons that introduce unnecessary complexities into a sim that isn't perfect in terms of stability in the first place. 

Then, if you were coherent, you should:

- Stop using any of the many airports from Flightbeam, Flighttampa, Aereosoft, DD, and so many others that use SODE, because SODE it's made by a .DLL module and an .EXE module that "introduce unnecessary complexities into a sim that isn't perfect in terms of stability"

- Stop using ActiveSky, because it requires a .DLL module and its related .EXE.

- Stop using UT LIve, because it has its own .EXE module too.

- Don't use use anything that use FSUIPC, which is a .DLL module.

- Don't use any airplane that use TFDI TrueGlass or RealLight,

- Don't use Navigraph, because it loads a .DLL in the sim too.

- Don't use FsLabs, because they have 3 different .DLL which are loaded in the sim at each start, even if you use another airplane.

So no, everybody uses what is required and, in case of P3D V5, precisely for the reason of stability and not wanting to be wrongly accused of crashing a sim that is not very stable, we removed the one and only really complex feature from our software that COULD possibly crash the sim, because it's something that we can still live without, for the time being.

Edited May 30, 2020 by virtuali

[OzWhitey 3,353]

3 minutes ago, virtuali said:

You commented about:

- landclass roads

- missing 3d grass

- a bug in the watermask exclusion

My reply was just related to these comments. It should be obvious these are very marginal things that is totally useless to show as complete in that kind of preview. Again, would you really think we would release a scenery of PHNL that kills Ford Island ? Or, considering we always had 3d grass in our sceneries for years, do you really think that, for some reason, PHNL won't have it ?

You don't need to get so defensive, V, I'm commenting in a public forum responding to 1. other people's comments and 2. the statements in the article that was linked. People were saying how good it looked in the two pictures linked, and the article was specifically praising the blend with surrounding scenery and the water. I disagree with all of those points - both screenshots are a bit "meh", the airport and surrounding scenery don't look great together and the water also falls into the "no so good" category (you say that it has a bug, so you agree with me!).. 

As for couatl not causing crashes - as I said, I don't know if it's responsible, just that my sim has been less stable corresponding to the time that I installed it. Having said that, a very quick google will turn up pages and pages of people talking about couatl-related crashes, so it's entirely plausible to me and with P3D v5 I really like the idea of keeping my sim as clean as possible.

I'm hardly your biggest critic around the web. I just checked, and I currently own 14 of your products. Having said that, I'd be much more likely to buy more in the future if you moved away from the couatl/addon manager-in-the-sim. It should not have escaped your notice just how happy a lot of simmers were when Flightbeam changed their install method. Certainly something I would consider if I was in your position, at least as an option for customers.

I've enjoyed my FSDT airports in the past, and hope that PHNL works out well for you. It's certainly a beautiful area of the world.

Cheers!

 

[virtuali 4,419]

2 hours ago, Twenty6 said:

I've got to agree. It's the reason I've bought other developers over FSDT. KORD and KLAS as example.

An example of what, exactly ?

- KLAS is a very old scenery, I would imagine something better would come out, after almost 10 years.

- KORD is, instead, the perfect example of a scenery that is not very dependent from the Addon Manager or Couatl.

It's 90% done with pure and standard .BGL because, when we said we used those for things the simulator can't do otherwise and to bypass several FSX limitations, it wasn't an excuse, it was true and, the "example" is precisely KORD V2

KORD V2 use 100% standard .BGL files because, being our first scenery that works ONLY with P3D4 and was designed for it, we didn't had to do in our code what wasn't possible in FSX.

Of course, KORD V2 requires GSX L2 for jetways but, it would be really silly to thing we made all that work to have such a complete jetway library, and NOT use it in our sceneries, and of course KORD comes with a perfect GSX profile with custom pushback at all gates, etc.

[micstatic 4,316]

Virtuali.  Are your plans still to wait and see what may or may not happen with MSFS for your JFK update?  I would think that's a very important airport you don't want to lose to another developer if one decides to swoop in. 

[virtuali 4,419]

Just now, OzWhitey said:

You don't need to get so defensive, V, I'm commenting in a public forum responding to 1. other people's comments and 2. the statements in the article that was linked. People were saying how good it looked in the two pictures linked, and the article was specifically praising the blend with surrounding scenery and the water. I disagree with all of those points - both screenshots are a bit "meh", the airport and surrounding scenery don't look great together and the water also falls into the "no so good" category (you say that it has a bug, so you agree with me!).. 

And you shouldn't say I'm "defensive", when I'm just commenting as you. See, freedom speech goes in both ways, if you feel free to share your opinion, I'm also free to tell you why I think you are wrong.

I think you are wrong, because commenting on those things is really useless at this stage of the presentation.

 

Just now, OzWhitey said:

As for couatl not causing crashes - as I said, I don't know if it's responsible, just that my sim has been less stable corresponding to the time that I installed it.

Fact an .EXE cannot crash another .EXE is not something open to debate. The reason why some users mistakenly think Couatl "made" the sim crash, it's related to their inability to understand how the Event Viewer works.

They see an Event that said Couatl.exe has crashed, and they saw the sim that crashed so, I understand its logical one might be MISLEAD thinking Couatl was the cause, but it's not.

Events in the Event Viewer has a timestamp and, when the sim crashes, you'll always have an additional Event related to Prepar3d.exe. And before saying who was the culprit, one should always check the timestamps because, what's really happening is:

- The simulator crashed for another reason.

- When the simulator crashes abruptly, it might be exactly in the middle of a Simconnect communication with another add-on, like Couatl, and it won't be able to send a proper "QUIT" command to it, so that other add-on will now it's time to quit, clean up all its own memory ( which is SEPARATE from the sim memory ), release all resources and quit cleanly.

Without being able to do this ( because no "Quit" command ever arrived from the crashed sim ), Couatl will likely crash, because it couldn't possibly anticipate the simulator own abrupt exit.

So, in this situation, you'll see a Couatl.exe crash in the Event Viewer but, if you check better the event time stamps, you'll see the Prepar3d.exe crash happened before so, what really happened, it was the simulator that crashed for another reason, and it MADE Couatl crash, not the other way around.

 

Quote

Having said that, a very quick google will turn up pages and pages of people talking about couatl-related crashes, so it's entirely plausible to me and with P3D v5 I really like the idea of keeping my sim as clean as possible.

A very quick google will turn up pages and pages of people talking about not faked Moon landings and Flat Earth either.

 

Just now, OzWhitey said:

It should not have escaped your notice just how happy a lot of simmers were when Flightbeam changed their install method. Certainly something I would consider if I was in your position, at least as an option for customers.

Flightbeam didn't use our software for basically anything else that anti-piracy. Which is 1% of what it does so, obviously, users are always happy when something that didn't had ANY other use than DRM, goes away.

We use Addon Manager/Couatl for so many other things that are just not possible otherwise. Do you even know WHAT Couatl is ?

Couatl it's just an interpreter for the Python language and, the whole GSX and GSX L2 are just Python programs.

And, since they run externally to the sim, there are the following advantadges:

- They are totally safe, because ( as I've said ), an external .EXE CANNOT CRASH THE SIM

- They don't slow down the sim either because, they run into their own entirely separate thread. So, for example, even if GSX had to do a lengthy calculation, for example to calculate a path for a vehicle, it will NOT slow down the simulator because, Couatl being an external .EXE, it will be assigned a spare core on a multi-core system and running in a background thread, it cannot slow down the sim, just because it's "thinking".

Instead, an add-on that is made with a .DLL ( I'm sure you have many of them installed ), in addition to being able to crash the sim, can also slow it down, especially when calling any of the Gauges SDK functions, that are not thread-safe or any of the PDK functions.

[virtuali 4,419]

35 minutes ago, micstatic said:

Virtuali.  Are your plans still to wait and see what may or may not happen with MSFS for your JFK update?  I would think that's a very important airport you don't want to lose to another developer if one decides to swoop in. 

Everything we are doing right now is almost entirely driven by what will happen with MSFS, what kind of add-ons will work best there, how many people will continue to buy things for P3D, how P3D ( and X-Plane too ) will evolve in the future, those are the only concerns we have.

Edited May 30, 2020 by virtuali

[OzWhitey 3,353]

1 hour ago, virtuali said:

And you shouldn't say I'm "defensive", when I'm just commenting as you. See, freedom speech goes in both ways, if you feel free to share your opinion, I'm also free to tell you why I think you are wrong.

I think you are wrong, because commenting on those things is really useless at this stage of the presentation.

 

Fact an .EXE cannot crash another .EXE is not something open to debate. The reason why some users mistakenly think Couatl "made" the sim crash, it's related to their inability to understand how the Event Viewer works.

They see an Event that said Couatl.exe has crashed, and they saw the sim that crashed so, I understand its logical one might be MISLEAD thinking Couatl was the cause, but it's not.

Events in the Event Viewer has a timestamp and, when the sim crashes, you'll always have an additional Event related to Prepar3d.exe. And before saying who was the culprit, one should always check the timestamps because, what's really happening is:

- The simulator crashed for another reason.

- When the simulator crashes abruptly, it might be exactly in the middle of a Simconnect communication with another add-on, like Couatl, and it won't be able to send a proper "QUIT" command to it, so that other add-on will now it's time to quit, clean up all its own memory ( which is SEPARATE from the sim memory ), release all resources and quit cleanly.

Without being able to do this ( because no "Quit" command ever arrived from the crashed sim ), Couatl will likely crash, because it couldn't possibly anticipate the simulator own abrupt exit.

So, in this situation, you'll see a Couatl.exe crash in the Event Viewer but, if you check better the event time stamps, you'll see the Prepar3d.exe crash happened before so, what really happened, it was the simulator that crashed for another reason, and it MADE Couatl crash, not the other way around.

 

A very quick google will turn up pages and pages of people talking about not faked Moon landings and Flat Earth either.

 

Flightbeam didn't use our software for basically anything else that anti-piracy. Which is 1% of what it does so, obviously, users are always happy when something that didn't had ANY other use than DRM, goes away.

We use Addon Manager/Couatl for so many other things that are just not possible otherwise. Do you even know WHAT Couatl is ?

Couatl it's just an interpreter for the Python language and, the whole GSX and GSX L2 are just Python programs.

And, since they run externally to the sim, there are the following advantadges:

- They are totally safe, because ( as I've said ), an external .EXE CANNOT CRASH THE SIM

- They don't slow down the sim either because, they run into their own entirely separate thread. So, for example, even if GSX had to do a lengthy calculation, for example to calculate a path for a vehicle, it will NOT slow down the simulator because, Couatl being an external .EXE, it will be assigned a spare core on a multi-core system and running in a background thread, it cannot slow down the sim, just because it's "thinking".

Instead, an add-on that is made with a .DLL ( I'm sure you have many of them installed ), in addition to being able to crash the sim, can also slow it down, especially when calling any of the Gauges SDK functions, that are not thread-safe or any of the PDK functions.

Hey, all I was saying in my original comment was that in the two screen shots 1. the surrounding landscape was poor 2. the ocean looked bad and 3. there should ideally be grass. You have subsequently agreed with me on all three points, so I'm not sure what we are arguing about.

As for Addon manager/Couatl - you've noted that it does lots of different things, and that your latest release moves closer to using standard .bgl files more and using other hacks less. Whilst I know that your long-standing (and somewhat controversial) position is that couatl does not and can not cause crashes, if you're performing hacks to get around the simulator limitations I still consider that a possibility.

Back to flying for me now.

 

Cheers!

 

 

 

 

[virtuali 4,419]

40 minutes ago, OzWhitey said:

 Whilst I know that your long-standing (and somewhat controversial) position is that couatl does not and can not cause crashes

That's not a position, or a personal opinion. An external .EXE cannot cause another .EXE to crash, this is a fact, not open to debate.

There's only a certain categories of .EXEs that can cause a crash in another .EXE, and are:

- Services loaded by Windows on the "Services" tab of the Control Panel. Most common ones are antivirus, firewall, vpn, anti-spyware, and many others.

- Programs that "Attach" to another .EXE as Debuggers. They can be either real debuggers, or things that hack into the OS to intercept another application messages, for example programs that define "global" hotkeys that can work regardless of the application ( like a screenshot hotkey ), hud performance displays, shader hacks like EnvShade, cheaters, etc.

Couatl doesn't belong to any of the above.It's a standard user-mode executable that doesn't attach or intercept anything at the OS level, it doesn't even need or ask for admin permissions to run.

 

Quote

If you're performing hacks to get around the simulator limitations I still consider that a possibility.

That's precisely the reason why you should stop considering that a possibility, because Couatl doesn't "hack" anything.

It's 100% standard Simconnect client that only makes 100% documented SDK calls and only through Simconnect, which is the only communication channel it has with the sim. Which is its only option, as a stand-alone .EXE.

In old times, and in FSX, we used "hacks", that is direct in-memory access, with the Addon Manager ( again, Couatl cannot access the sim memory, that's why it cannot crash it ), because the FSX SDK is way more limited than P3Ds.

But since at least P3D V3, there isn't a single line of code in the Addon Manager that does any direct access in memory, not writing, and not even in read-only mode.

There's a very easy way to know which one of your add-ons is doing hacks, and is: "Is that add-on dependent on the precise build of the simulator ? Do I have to wait for a new version each time there's a new Hotfix out ?". If the answer if yes, and a certain add-on .dll ( it can only be a .dll, of course ) doesn't work with a new Hotfix until a new version is made to support that precise build, you can be sure it's because that add-on DOES require in-memory access, so it's doing something potentially dangerous. 

We haven't been dependent on the precise build of the sim since several years by now, and that's also a fact, and a clear indication we don't do any hacks. And even if we wanted to, we couldn't from Couatl anyway.

The Addon Manager, as a .DLL, could hack into the sim, if we wanted to, but we don't, and even the thing we decided to momentarily turn-off in V5 right now, that is DirectX Render-to-Texture, is still NOT an "hack", it's an officially supported method of the P3D V4 PDK but, being the module a .DLL, with the ability to execute DX code on the video card together with the sim, it's something that must be made with extra care and tested even more, that's why we haven't touched DX12 yet, considering the sim itself is still not 100% stable because DX12. I'm sure it will be, eventually.

We take the stability of user's systems very seriously, that's why we decided to postpone the DX12 update until we can say for sure it's safe to use. 

Edited May 30, 2020 by virtuali