Jump to content

Recommended Posts

Posted

This version of XFSE has been patched to allow use of a file called xfse_alias.txt instead of modifying the ACF description.

Create a text file "next to" your .ACF file, fill the text file with exactly the same information you would normally put in the ACF description.

Done.

If there is no alias file the XFSE script will fallback to the old behavior and load the description data from the ACF.

I have disabled the XFSE 'in-sim' updates so that you don't accidently over-write the patched version.

I do not have the Python plugin installed and I have no idea how to thoroughly test FSEconomy so I have not tested this in sim but I have double checked it for bugs and hope that it will work as intended.

If someone can please test this out and let me know if it works we can look at getting the changes accepted into the main plugin version.

Thanks!

PI_xfse.py

  • Downvote 1
Posted

ok, I just had the first chance to fire up xplane in days. Unfortunately, the patched plugin won't work. While one can successfully log in, the "start flying" button does nothing. Also one can't "X" the pop-up window (make it vanish).

Posted

...thanks for the feedback, im not real sure why it does that, maybe the self check is smarter than I thought.

Would it be too much to ask to get you to take this up with the author of XFSE directly?

I have way to much on my plate and the new code is pretty clearly commented where and why it's been changed.

Code mods are released as BSD license (free to use, however you like..) or whatever suits the XFSE license better.

  • Downvote 1
Posted

Just had a thought (I know, you can smell the wood burning)...

As an alternative to this process, a quick check on the datarefs shows that /sim/aircraft/view/acf_descrip seems to be (somewhat surprisingly) writable. I believe this is the setting that needs to be changed for XFSE to work. Perhaps this would be a better approach - it could be set up in the plugin to read it from the xsFalco.ini file (as used for the default VFR Code). This would avoid any need for the original author of XFSE to modify his script and give a more flexible system all around as well as neatening up the files associated with the Falco.

Setanta

Posted

Modifying the ACF package data for a string that -only- XFSE needs is horrible. In any form.

If anything, XFSE should share a new dataref that we can write to if we want to.

Actually there's nothing 'horrible' about it at all. The whole problem seems to stem from the false assumption that the acf_descrip data is fixed for a given aircraft, which it obviously is not - it can easily be (and often is) modified in PlaneMaker or under plugin control. The Falco plugins seem to make this assumption, which is poor programming practice at best. XFSE assumes that the acf_descrip is user modifiable but assumes that it won't be modified by another plugin during a session, which is somewhat more forgivable.

Probably the best solution would be some modification of practices on both sides to remove this dependency - both should really use a file external to the .acf to store the information they require. Actually if the Falco did this then users could tweak until their heart's desire and it would work fine with XFSE as it stands.

Setanta

Posted

Modifying an aircraft is not the way to go, and when we discussed this with Laminar most recently they felt the same way. It was meant for the developer of the aircraft, not anyone else.

We've laid a base ground for someone to correct this. Better to work on a fix in the FSE realm now than later...almost any future X-Aviation aircraft will work the same way.

Posted

Both of those fields contribute valuable Copyright information to the package.

It was an old trick to download someone else version 7 ACF, change the textures, change those two fields and re-upload claiming it as your own.

These fields only increases in importance with payware.

When you buy a product you expect quality support.

If "the customer" modifies the product and somehow forgets about it and then starts reporting bugs it's frustrating for everyone.

(Opening a 9.5 acf in Plane Maker 9.4 'just to change that field' could potentially lead to issues... who knows. History says it's safer to assume yes.)

Our plugins work nicely with our products and they ensure quality support by clearly identifying a factory-sealed product.

I've gone out of my way to extend a 3rd party plugin so that it can co-exist more easily with everyone's aircraft, everywhere, right out of the .zip.

If the patch is adapated, in the near future, you can look forward to almost never having to tweak that field ever again.

You're welcome.

  • Downvote 1
Posted

Modifying an aircraft is not the way to go, and when we discussed this with Laminar most recently they felt the same way. It was meant for the developer of the aircraft, not anyone else.

We've laid a base ground for someone to correct this. Better to work on a fix in the FSE realm now than later...almost any future X-Aviation aircraft will work the same way.

While it may have been meant purely for the use of the developer the actual data is easily accessible to anyone. This may change in the future but right now this is the way things are - and if something is easy to modify, you can bet your ass that someone will modify it :)

Setanta

Posted

Both of those fields contribute valuable Copyright information to the package.

It was an old trick to download someone else version 7 ACF, change the textures, change those two fields and re-upload claiming it as your own.

These fields only increases in importance with payware.

This is the problem I was trying to point out! Because these fields are easily modifiable their value as a reference point is minimal.

When you buy a product you expect quality support.

Yep, and unlike some payware providers I've always been very pleased with the support I've got with aircraft I've bought from X-Aviation.

If "the customer" modifies the product and somehow forgets about it and then starts reporting bugs it's frustrating for everyone.

(Opening a 9.5 acf in Plane Maker 9.4 'just to change that field' could potentially lead to issues... who knows. History says it's safer to assume yes.)

Very true, but sadly it's the nature of the beast when it comes to X-Plane. People will tamper and tweak and then complain when they break something.

Our plugins work nicely with our products and they ensure quality support by clearly identifying a factory-sealed product.

It seems to me that your exception to my original idea was that it involved the user modifying the original .acf file. The whole point is that it wouldn't. It would remain in its factory sealed condition. What would be changed is the data within the running copy of X-Plane. Would this cause problems for your plugins? What I was looking for was another way to change the acf_descrip without having to modify the original file in PlaneMaker which causes problems with the update procedure.

Setanta

  • 2 weeks later...
  • 4 weeks later...
  • 2 weeks later...
Posted

Good morning everyone!

I got the same problem now, but the difference at me is that I´m still with V8.64, so that the new plugin version 1.63 won´t work for me. Is it somehow possible to update the plugin version 1.41 for V8.64 as well?!

If not, then I´m just in bad luck and have to cope with a few less planes in FSE.

Sebastian EDDL

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...