Author Topic: PSX + X-Plane for scenery (Read 319991 times)

mgeiss · « **Reply #400 on:** Thu, 12 Jan 2017 12:00 »

Hi all,

I'm also flying on Pilotedge, and with the new expansion area using the PSX+XView combo on PE would be great!

mikeindevon · « **Reply #401 on:** Thu, 12 Jan 2017 16:00 »

Hi,

I am happy to develop some extensions to XView, but I am not happy to release the c++ source. There seems to be three areas of extension that people want:

1. Transfer of groundspeed to online controllers. This is just not possible using the current X-Plane SDK as plugins cannot write to the groundspeed variable, only read it. I have asked LR to change this but I doubt they will as it has the potential to wreck their flight model. The only way to get round this in my view is for the online interface plugins to get the groundspeed directly from XView rather than X-Plane. I believe that this could be achieved with inter-plugin communication (although I have never tried this) if I were to expose an XView dataref. Clearly this requires somebody to modify the online interface plugins.

2. Transponder not functioning correctly. This was a limitation of the stock LR 747 model that I used. I don't know if the XP11 version has a better implementation of the transponder. Any info on this would help.

3. Use of the XP11 747 as the basis for PSX Plane. I would be interested to know what advantage this would have for the users and what enhancements would be interesting. Implementing a new PSX Plane involves little if any change to the XView code: the implementation is almost entirely done by modifications to the .obj files in the stock aircraft subdirectory. If you like to compare the stock and PSX Plane .obj files you will see where the differences are. Working with these files is not easy and took a considerable proportion of the XView develpment time. It is also necessary to have the 3D modelling package AC3D.

I see the way forward as this:

* users to compile a list of requirements for the extensions
* somebody take on the mods to the online interface package to talk directly to XView (this may not be possible in all cases eg VATSIM because of their NDA)
* somebody take on the mods to the obj files in the XP11 version of the 747 using my datarefs and additional ones as necessary.

Let me know. Perhaps we should start a separate thread for this.

Mike

mgeiss · « **Reply #402 on:** Fri, 13 Jan 2017 04:33 »

Regarding 1.) While the GS dataref itself is not writable, it's value is determined by the velocity vector IIRC. So when you write the rlevant data to

sim/flightmodel/position/local_vx
sim/flightmodel/position/local_vy (might not be needed, as it's the vertical component)
sim/flightmodel/position/local_vz

the GS should be calculated correctly.
http://www.xsquawkbox.net/xpsdk/mediawiki/MovingThePlane#Changing_the_Aircraft.27s_Velocity

Regarding 2.) I wouldn't mind if I had to set the transponder mode and Ident through X-Plane's built in commands (see below, but you probably know those :-) ), instead of using PSX functions for the purpose of flying online.

sim/transponder/transponder_ident
sim/transponder/transponder_off
sim/transponder/transponder_standby
sim/transponder/transponder_on
sim/transponder/transponder_alt

So if it would be possible to make X-Plane think the PSX representation is just a plane with a generic Transponder in Plane-Maker, those commands should work.

mikeindevon · « **Reply #403 on:** Fri, 13 Jan 2017 12:30 »

Thanks for the tip regarding point 1, which I can implement easily. At present I just put in local_x, local_y, local_z, theta, phi and psi. I will do it in the next few days and we can see if it works. Regarding the transponder, I will have a look at the details again - I can't comment at the moment.

Mike

Pierre Theillere · « **Reply #404 on:** Fri, 13 Jan 2017 13:04 »

Hi Mike!

Amazing news, and congrats for the pending update! Will the new XView remain compatible with X-Plane 10.51? I admit that, for now, I'm sticking with it.. as it's already quite a nice and smooth scenery generator on Mac!

mikeindevon · « **Reply #405 on:** Fri, 13 Jan 2017 15:25 »

I can't see why not. It's a very small mod.

mgeiss · « **Reply #406 on:** Fri, 13 Jan 2017 20:42 »

Just to note: local_vx, vy and vz need to be in meters per second, and also X-Plane's GS variable/dataref is in meters per second, not in knots... I stumbled upon this when I wrote a lua script to show some flight data when hiding the instrument panel.

Bastien · « **Reply #407 on:** Sat, 14 Jan 2017 12:40 »

Hi All,

Thank you for your investigations !
The news sounds good !

I'll do more test for transponder between PXS and X-plane, because I got it working for one time .... but I don't remember how ....

Mike, is Xview plugin activable/desactivable from xplane plugin admin menu ?
For me it seems to be not

Thank's
Bastien

mikeindevon · « **Reply #408 on:** Sun, 15 Jan 2017 10:45 »

Quote from: mgeiss on Fri, 13 Jan 2017 20:42

Just to note: local_vx, vy and vz need to be in meters per second, and also X-Plane's GS variable/dataref is in meters per second, not in knots... I stumbled upon this when I wrote a lua script to show some flight data when hiding the instrument panel.

I have implemented a version that inputs the local_vx etc and DRE shows these to be exactly what I would expect and in agreement with the PSX groundspeed. For example, flying true north at 261knots gives me a value of 134m/s for the appropriate velocity component and the other two approx zero. So far so good. However the groundspeed is set initially but is never updated and the value is different each time you run the sim. On the run quoted above it was 103821816.0 ! X-Plane can't cope with this number and the view goes dark. If I input fixed velocities of much lower values, the groundspeed value is lower, remains unchanged, and the view doesn't go black.

From all this it would appear that inputting the local velocities does not work. Bear in mind that I have to disable the flight model to let PSX drive the X-Plane position.

This is a shame. Any other suggestions?

Mike

mgeiss · « **Reply #409 on:** Sun, 15 Jan 2017 14:50 »

That's a bummer. I'm araid I'm out of ideas at the moment.
I'm far from an expert in this regard, I just did some lua scripts for X-Plane which work with "normal" addon planes.

NAVPI · « **Reply #410 on:** Fri, 27 Jan 2017 01:06 »

[blank]

mgeiss · « **Reply #411 on:** Fri, 27 Jan 2017 04:32 »

Yep, that's the main problem. Theoretically, I guess you could activate the flight model for a very short instance every second (or so), let the groundspeed update, and quickly deactivate it again. But that might of course lead to other kinds of problems and you would probably need to stop this on the ground.

But we might have at least a solution for Pilotedge. I wrote about the problem in their forum and asked if passing the missing variables via custom datarefs to their client could be an option. This is what they said:

Quote

Keith has expressed a willingness to have the PE plugin look for a custom dataref such as "/custom/xview/groundspeed" say and read that. If the X-View developer wants to create something like that, that would be ideal.

So when there is some spare time you could get in touch with them ( info at pilotedge.net ) and talk about how this could be done. But there's no hurry!

Eldrarak82 · « **Reply #412 on:** Thu, 9 Feb 2017 17:58 »

So, just wondering if there is a mirror for the XView plugin, as it seems as though www(dot)larkshayes(dot)com is currently not responding to connection requests.

"This site can’t be reached - www.larkshayes.com refused to connect."

JohnH · « **Reply #413 on:** Thu, 9 Feb 2017 19:50 »

I just tried the site www.larkshayes.com from my Imac using Safari and had no problems or error?

John

Quote from: Eldrarak82 on Thu, 9 Feb 2017 17:58

So, just wondering if there is a mirror for the XView plugin, as it seems as though www(dot)larkshayes(dot)com is currently not responding to connection requests.

"This site can’t be reached - www.larkshayes.com refused to connect."

inshibaya · « **Reply #414 on:** Fri, 10 Feb 2017 20:33 »

Hi everybody.

I tried Xview with wplane10. It works perfectly for me except when I load a gate position from PSX:

If i load a cold and dark situation at a gate position, the plane is not aligned correctly in XP10
If i load a runway position from psx, all is aligned perrfectly...

When i load the gate position from PSX, the heading does not move. If I select a "take-off" position then the Heading change and is correct. Perhaps a psx configuration pb?

Sorry for my english... :-)

Hardy Heinlin · « **Reply #415 on:** Fri, 10 Feb 2017 20:43 »

Hi,

this has nothing to do with XView. The gate database in PSX contains no gate heading data; so if you click on a gate button in PSX, the heading will not change.

Official gate databases are actually intended for use as a present position reference during IRS alignment. Using the gate database for other purposes too is just a special feature of PSX.

If you want to store a certain position at a gate with a specific heading, you need to save a situation file.

Regards,

|-|ardy

cavaricooper · « **Reply #416 on:** Fri, 10 Feb 2017 20:47 »

FWIW I have had this issue and entering the correct heading in the PSX POSITION page seems to fix it satisfactorily for me. Useful when flying from a different airport than the one you last landed at.

HTH

C

inshibaya · « **Reply #417 on:** Fri, 10 Feb 2017 21:22 »

Thx for your quick answers

asboyd · « **Reply #418 on:** Sat, 11 Feb 2017 05:56 »

I have also found that P3D aligns correctly with PSX gate info, but XP10 is way off especially at YSSY...
I move the aircraft in XP11 and then enter the info as a long and lat to save in my situ so I can load one for P3D and a different one for XP10...

If you use the runway as the start point both are OK

But when flying into an airport it is not a problem as the gate info is not as important...

Cheers,

Hardy Heinlin · « **Reply #419 on:** Sat, 11 Feb 2017 06:44 »

Please note that the gate lat/lon data has a resolution for use as a present position entry in the FMC for IRS alignment. So it's not that accurate to put the aircraft exactly on the spot in the scenery. Some gates in the scenery are even so so close to each other that the low resolution in the database rounds their lat/lon numbers up to the same final value.

Cheers,

|-|ardy