New patch and XML gauges...?

Seahawk72s

Seahawk72s

SOH-CM-2023
Dino reported..
I am happy to report that recently released Micrsoft Flight Simulator patch (1.8.3.0) has solved all the loading problems with complex XML gauges... this means that the M-346 for MSFS development can continue and the plane will definitely come to the new sim.

This also unlocks the possibility of working on the F-35, the Eurofighter and the F-14D...although, on those planes, I still need to do some testing to see if the problems with supersonic flight dynamics are still there.
Click to expand...

Can others confirm XML gauges are working..?
 
Each time I load an FSX plane up and go to the VC MSFS crashes!

May have fixed that, but they have broken some kind of backward compatibility - for an aircraft that has no 2D XML gauges, all being 3D modelled.
 
centuryseries said:
Each time I load an FSX plane up and go to the VC MSFS crashes!

May have fixed that, but they have broken some kind of backward compatibility - for an aircraft that has no 2D XML gauges, all being 3D modelled.
Click to expand...
Same here with two different aircraft. Only benefit is that it loads a lot quicker on the second and subsequent launches. :encouragement:
Will have to check out the link mentioned above.
:ernaehrung004:
 
centuryseries said:
Each time I load an FSX plane up and go to the VC MSFS crashes!

May have fixed that, but they have broken some kind of backward compatibility - for an aircraft that has no 2D XML gauges, all being 3D modelled.
Click to expand...

I get the same result. Usually it crashes just after I press 'fly'
 
Hi,

I confirm: using MCX and deleting mouse rectangle in the interior model solve this probleme :encouragement:.
 
centuryseries said:
Doesn't that stop the cockpit switches etc from working? If so it solves one problem but creates another!!
Click to expand...
Yes, I agréé but this patch isn't mine. I have only experiment this tip and saw that with 1.8.3.0 FSX aircraft can be used if you modify MDL. Why Asobo has made modification, I don't know. Is't an error of developer? I think so.
 
Asobo arent going to keep backwards compatibility as a viable option if it places too much restrictions on native code. That's a bit like detuning a ferrari so it can work with crap fuel.

Fix is for devs to compile as much complex gauge code into the mdl and/or switch to the new code paradigm ... which is a bit of a head-ache until the sdk is fleshed out... or is this a case of " I need to get my development into MSFS as soon as possible even though it isnt a truly dedicated model " issue.
 
pilto von pilto said:
Asobo arent going to keep backwards compatibility as a viable option if it places too much restrictions on native code. That's a bit like detuning a ferrari so it can work with crap fuel.

Fix is for devs to compile as much complex gauge code into the mdl and/or switch to the new code paradigm ... which is a bit of a head-ache until the sdk is fleshed out... or is this a case of " I need to get my development into MSFS as soon as possible even though it isnt a truly dedicated model " issue.
Click to expand...

You could argue that backwards compatibility will keep people using MSFS until enough native products come out. So backwards compatibility can be a good thing.

A lot of developers (myself included) were not able to get into the test program and so are on a back foot requiring many months of learning in order to release anything.
 
centuryseries said:
You could argue that backwards compatibility will keep people using MSFS until enough native products come out. So backwards compatibility can be a good thing.

A lot of developers (myself included) were not able to get into the test program and so are on a back foot requiring many months of learning in order to release anything.
Click to expand...

I hear you . I too wasnt in the test programme. Just means we're all in the same boat. So the question becomes... do you spend time modifying your stuff to work as ports... or embrace the new paradigm and hope the SDK is fleshed out sooner rather than later ? Or build for both? release one and msfs to come later ?

Some devs still arent utilising true PBR for P3dv4+. There is obviously a market for ports however moving forward I cant see backwards compatibility lasting if Asobo need/want a feature that would essentially kill the portover addon. I happen to think it is still very early on in the life of MSFS to think that portovers are locked in. Next patch could change it all again and you need to rethink the process.

I'd also argue that the majority of new users to msfs dont even know about legacy flight sim and probably care less. It's the changing face of our hobby. They're the type that will only buy from the marketplace and wouldnt know one end of a .cfg from another ( and to be honest why should they , it's like driving a car you dont need to know how the variable cam timing system works when VTEC kicks in ).

The beauty of development is that it is so exciting. Frustrating but exciting all the same.
 
But you dont have to use the legacy model. Mine and Roberts P-61 doesnt use it and it flies wonderfully..

I worry that the social amnesia that seems to be blankeeting the world is going to cause a lot of the legacy aircraft that deserves to be maintained for histories sake, will be forgotten and left to rot and all we;ll have are these new shiny flashy pieces of modern trash and people will forget their roots in aviation.. I would hate to see any of these old planes vanish. I'd much rather they be ported or converted and perhaps become the inspiration for a fully modernized version of them to be developed..
 
Agreed, I've ported a dozen or so FSX models, almost all from the 40's and 50's, that have functioning instruments and fly well using the modern flight model.
Old planes have character and history, in R/L and in FS :)
 
My aircraft port okay, except for the B-58 Hustler..... but the aircraft I've ported (A-12 and SR-71) don't fly right, the elevator and aileron (combined to be elevon) do virtually nothing even after transposing all the data points over from the air file. I've double checked the area, the degree of movement, the scalars - but cannot get it to pitch and roll.... Its really odd.

Has anyone else experienced that?
 
Most of my imports have been props and relatively simple, but not seen anything like that with Meteors and Hunters.
Did you use the LegacyImporter with an Airfile export?
Or from scratch using the SDK?
Cheers
Keith
 
Hi,

I used neither, I created the new cfg files for flight_model, engines etc with figures based on the old aircraft.cfg and the .air file using the handy spreadsheet over at FSDeveloper.com to cross reference the data points since the new data points mostly are not called the same thing as they were in the .air file unfortunately.
 
Last time I tried that importer, it didn't generate the layout.json properly, but willing to try again.

Will have another go later!
 
The latest version .3.3 generates a virus warning for me so I'm using the older version.
Not had a problem with the JSON file.
 
pilto von pilto said:
Asobo arent going to keep backwards compatibility as a viable option if it places too much restrictions on native code. That's a bit like detuning a ferrari so it can work with crap fuel..
Click to expand...
Hi,
With the last patch 1.9.3.0 mouse rectangles are come back and usable so it was really an error of Asobo in the 1.8.3.0 version..
 
You must log in or register to reply here.
Back
Top