Another XP12 preview drops

[mjrhealth 833]

57 minutes ago, Greazer said:

Something about the sunset, it does not look natural or real to me. Just my 2 cents.

I have seeing many unreal real sunsets, I guess the 2 cents may be due to inflation.

[tonywob 4,770]

1 hour ago, Greazer said:

X Plane 12 is shaping up to be a niche sim for night time flying. The screenshots so far have indicated so. Maybe it can specialize in this segment and stay afloat. Perhaps a good sim to help with IFR training and be the one for jets and fly by wire.

I'd disagree (regarding X-Plane 11). With the right addons you can make it look very good, and 12 will only improve that. I don't particularly enjoy flying VFR over the UK and Europe in MFS because it tends to exaggerate the placement of trees making some places hard to recognise. The UK in particular, despite the decent autogen, is overshadowed by trees everywhere, and there seems to be no way to trim them (Please, if someone knows, then let me know)

Regarding night time and sunsets, I've not seen realistic looking sunsets in any sim TBH. A lot of the effects we see are either exaggerated or added for effect (e.g. You are seeing it as if looking through a camera not your own eyes)

That being said, I'm not too fussy. I like flying during the day so I can actually see the ground and what's out there. As for night time environment and approaches, MFS has the edge for me here,.

[Pastaiolo 1,688]

1 hour ago, Greazer said:

Something about the sunset, it does not look natural or real to me. Just my 2 cents.

The sky can look like that but not every time. That's not the issue tho, what i think you find not natural is the fact that all the surfaces on the ground are not reflecting all the light that is still in the sky.

Regarding photoreal sceneries and such, i think i remember from old times that even if a scenery used the same orthophoto, the addon on P3D used much less storage space because the files were packed and compressed while in XP the size would be quite bigger. Is this something i remember right, and if it is, woudn't it be nice to have a similar feature in XP too?

[jcomm 5,995]

On 1/31/2022 at 10:38 AM, mSparks said:

MSFS.

Meanwhile, I get bored on a weekend (not enough time for many people to start MSFS once) and completely to replace the logic behind every control surface on a 747

And after years of all that still you wonder why XP is just better at everything?

Wow!  What was the ground ( 10m ) wind intensity ?

[Bjoern 1,158]

3 hours ago, Janov said:

Maybe also a sunset sim...😅

 

Now put the sun just above the horizon, add a shader that provides the optical illusion of it being thrice its size near the horizon and a bit of refraction and I'mma put on a leather jacket, hop into my '84 Corvette, put on some synthwave and fight crime in those L.A. nights that just never seem to end.

 

1 hour ago, Pastaiolo said:

The sky can look like that but not every time. That's not the issue tho, what i think you find not natural is the fact that all the surfaces on the ground are not reflecting all the light that is still in the sky.

Regarding photoreal sceneries and such, i think i remember from old times that even if a scenery used the same orthophoto, the addon on P3D used much less storage space because the files were packed and compressed while in XP the size would be quite bigger. Is this something i remember right, and if it is, woudn't it be nice to have a similar feature in XP too?

If my memory does not fail me, FSX/P3D uses binarization for its scenery files. This may require less storage space, but in turn increases load times as something has to un-binarize them.

[tonywob 4,770]

1 hour ago, Bjoern said:

If my memory does not fail me, FSX/P3D uses binarization for its scenery files. This may require less storage space, but in turn increases load times as something has to un-binarize them.

Yep, it's possible to compress the imagery inside the BGL files by quite large amounts (at a loss of quality), meaning aerial imagery takes up much less space than it does in X-Plane that uses a fixed size DDS.

[mSparks 2,094]

5 hours ago, jcomm said:

Wow!  What was the ground ( 10m ) wind intensity ?

Maximum XP will spit out (about 125kts iirc)

Aka testing XP planes in a virtual wind tunnel.

I'm pushing for it to be a bonafide feature in XP12, but worst case can just put them on a pedestal to get them out of ground effect, then it would be a few hundred.

[Biology 1,347]

On 2/1/2022 at 4:19 PM, Bjoern said:

If my memory does not fail me, FSX/P3D uses binarization for its scenery files. This may require less storage space, but in turn increases load times as something has to un-binarize them.

Yes that is true, BGLs used by FSX & P3D are compressed.

[Biology 1,347]

On 1/31/2022 at 1:38 PM, mSparks said:

It's both.

Default systems are detailed enough and easily enough to use that even if you know nothing about aviation one person can put together a decent enough GA plane from scratch in 6 to 12 months. 

If you are talking about default systems, of course, X-Plane is still unmatched in that regard. My point was that most developers do not use default systems as they are simply not detailed enough for more complex aircraft.

[mSparks 2,094]

2 hours ago, BiologicalNanobot said:

that most developers do not use default systems

I still say both.

Have you tried to develop against Simconnect?

https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/SimConnect_SDK.htm

That's the easy way to develop custom systems for the MS sims, from FSX to MSFS. And its absolute total garbage.

Even the new "not quite native" MSFS WASM isn't much better - if not worse.

Absolutely no one takes one look at say

https://github.com/flybywiresim/a32nx/blob/master/src/fadec/src/EngineControl.h

compiled into WASM that then takes 10 minutes to start

and says "yep that is a great alternative to"

https://github.com/mSparks43/747-400/blob/master/plugins/xtlua/scripts/B747.42.xt.EEC/B747.42.xt.EEC.lua

And that's before you even get into debugging it - which is 95% of the work.

Good luck competing with building complex aircraft systems when a single character mistake will lock up your entire machine with no information why; when the other guy gets "attempt to compare a number with nil on line XXX of file XXX" printed to the console but otherwise things continue as normal, which you can then fix while the sim is running.

Edited February 2, 2022 by mSparks

[RXP 2,338]

@mSparks I believe the example you're giving might not be entirely illustrative, or at least, I can read both source code equally easily (a little bit more easier for me in C++ though). The main issue with Simconnect in my opinion is elsewhere though.

The interface is well thought out, but it is cumbersome to use, and there is no latency guarantees. You might be requesting a data that you'll get maybe 10 frames later, or even more. Worse, if there are sufficiently enough other consumers/producers, they can halt processing to a certain extent. And probably the worst of it if I read this correctly, is that it is hard-coded to handle no more than 64 pipes. Just create 64 forked processes all requesting their SimConnect handle and you deprive any other add-on from even connecting if this is really coded like this.

The other main difference between both SDK here is clearly organizational: on one hand you have clearly sorted and grouped datarefs using a URI like schemas to reference them easily. I mean "sim/cockpit2/gauges/indicators/roll_AHARS_deg_pilot" leaves no ambiguities and is easy to find whereas try to find the equivalent here: https://docs.flightsimulator.com/html/index.htm#t=Programming_Tools%2FSimVars%2FSimulation_Variables.htm%23h

Which leads to another important point: XPL SDK offers thousands of fine grained datarefs you can also often override, whereas the other SDK is offering only a limited set of simvars which you can't always relate to which systems they are connected to.

Which leads to one last point at least: XPL SDK offers at least 2 levels of datarefs, most low level raw data, and another group higher level. The former group gives you access to the raw data you can derive any computation from or any display for, the latter is meant for direct consumption as a gauge data source var for display only. Whereas the other SDK is mostly only providing pre-digested simvars solely meant historically for gauge direct consumption for display only.

So in essence, XPL SDK models complex aircraft systems which you can configure to interconnect and which you can probe for operation and display, and experience shows these systems are generally behaving like their real world counterparts. Whereas the FS SDK models systems which are supposed to be similarly implemented but which you can't probe because they are only exposing the visible values you're supposed to consume for display mostly. It is a generalization of course and there are exceptions to the rule, but from my experience working with both for 20 years, from fully simulated aircraft (Meridian and unreleased A320 simulation) and fully simulated standalone gauges, this is what strikes me the most in the differences between the two SDKs.

[mSparks 2,094]

37 minutes ago, RXP said:

@mSparks I believe the example you're giving might not be entirely illustrative, or at least, I can read both source code equally easily (a little bit more easier for me in C++ though). The main issue with Simconnect in my opinion is elsewhere though

I wouldn't say it even scratches the surface. yep, completely agree with everything else you said.

What I was leading up to illustrate (and the reason I linked that C source is nanobot has source code OCD) is even when you get to a similar state (both those do engine ECC - at least as far as I understand the fbw framework) the gap in development workload is still gigantic; not least because that FBW code (should - correct me if I am wrong) actually ends up in a javascript VM anyway, which is both less performant than lua, and brittle to boot.

C to WASM has all the disadvantages of virtual machines and none of the advantages.

This is why 3 or 4 devs over a few years can release the CL650 for XP, and 200 seasoned developers release the CJ4 for MSFS after 6.

That isnt a trend I would say anyone who has actually thought about it believes will change.

Well, I can think of one possible change.

The fbw a320 is gpl3 licenced 🤣

Edited February 3, 2022 by mSparks

[GoranM 3,789]

42 minutes ago, mSparks said:

This is why 3 or 4 devs over a few years can release the CL650 for XP

2

Edited February 3, 2022 by GoranM

[mSparks 2,094]

11 hours ago, GoranM said:

2

I counted

You, Totoritko plus 1 or two people with the actual CL650 to get 3 or 4.

I forgot Cameron, but he mostly seems to count against you, so yes, back to 2 😛

[Biology 1,347]

13 hours ago, mSparks said:

I wouldn't say it even scratches the surface. yep, completely agree with everything else you said.

What I was leading up to illustrate (and the reason I linked that C source is nanobot has source code OCD) is even when you get to a similar state (both those do engine ECC - at least as far as I understand the fbw framework) the gap in development workload is still gigantic; not least because that FBW code (should - correct me if I am wrong) actually ends up in a javascript VM anyway, which is both less performant than lua, and brittle to boot.

C to WASM has all the disadvantages of virtual machines and none of the advantages.

This is an X-Plane 12 thread not MSFS so I will not go into more detail but you have several misconceptions on how MSFS' WASM implementation works. WASM code for MSFS does not run in a virtual machine, it runs entirely natively.

In short WASM is an instruction set, just like x86-64, ARM or any other instruction set. However the way it is designed and the way it separates code from data makes it "safer" by nature. In MSFS code safety mostly depends on the fact that most "unsafe" code will not compile into WASM at first place. Other than that compiling for WASM is no different than compiling for x86-64 or ARM, in fact FBW uses automated builds on Linux for their A320. When the aircraft loads for the first time, MSFS transpiles the WASM code into x86-64 code using inNative and caches the results - from that point it runs as native x86-64 code with no virtual machine at all. Code safety comes from the fact that the code was able to compile into WASM at first place and sandboxing around system calls, nothing else. I also have my own fair share of criticisms against MSFS, but such criticisms should be based on facts shouldn't they? X-Plane is a great simulator and stays my favorite in most aspects thanks to its well thought out and polished design (not talking about UI, but the overall simulator) that reminds me of Mac OS, but this doesn't mean the rest are awful.

SimConnect has its own set of really annoying issues like high and unpredictable latency, but none of these are directly related to WASM as they have been present since FSX. P3D does not suffer from that as much due to the fact that it has a custom interface called PDK, but developers still need SimConnect for handling of simulator and local variables. Not exactly sure though, as I only develop for X-Plane and MSFS.

13 hours ago, mSparks said:

This is why 3 or 4 devs over a few years can release the CL650 for XP, and 200 seasoned developers release the CJ4 for MSFS after 6.

Assuming the 6 year figure comes from the fact that MSFS took 6 years to develop, this is a rather nonsensical comparison. The CJ4 itself did not take 6 years, the entire MSFS project took 6 years. This is really not a great example to demonstrate development for MSFS is much slower if this is what you aimed for.

Also the CL650 took 2 developers - Saso for the systems and Goran for the art for the most part with some exceptions.

Edited February 3, 2022 by BiologicalNanobot