3.6 BETA requests

[Sling]

Keith,

For either of your proposed method’s you will need text input. How are you proposing to achieve this? What i’m suggesting is that you already have the flight plan in a txt file so why not read it to import your flight plan.

Corjan,

I understand your reasoning on this. I like Jacques am a little disappointed that a feature that was available was removed without mention and consideration of the fact that it was being used and now code no longer operates in the latest versions of AM. As you suggested and as a means for getting code that used the io library working again, can I therefore ask for the basic file reading we currently have be expanded to include these features.

File creation.
File editing.
Files not restricted to the resource folder or perhaps another folder(s) that can easily be accessed by a user to add remove files such as flight plans, config/settings files etc.
A means from the API to be able to include code for file selection such as a free text/drop down selection type input.

Tony

[Keith Baxter]

Keith,

For either of your proposed method’s you will need text input. How are you proposing to achieve this? What i’m suggesting is that you already have the flight plan in a txt file so why not read it to import your flight plan.

Tony

Tony,

I agree 100% with you.

I have accepted the fact that copy and paste, importing txt files etc is not to be. Should Corjan change his mind or an alternative method be added then I will look into adding it to the instrument. So for now I am moving to other methods of getting flight plans into AM and that is automatic flight_plan generation. I did have a quick look last night on how this is achieved and it seems that there is NO easy solution.

I am not going to clutter this thread with the feasibility, merits and methods of creating a Flight_Plan so I will open a new one under lua help. We can continue to discuss that there.

Keith

[Keith Baxter]

Can we please have a persist_append() function.

This would give me a gateway to append tables to a persist_id json.

My thinking. I can export a Flight-Plan in whatever format and convert it to json. Then by simply placing that json in the library, in code append it to the persist_id.

Am I making any sense?

Keith

[Corjan]

Simply use the table.append function in lua, and call the persist_put again.

Corjan

[Keith Baxter]

Simply use the table.append function in lua, and call the persist_put again.

Corjan

WOW, That was easy.
Thank you Corjan.

Keith

[JackZ]

Corjan

As I was reading again in this thread our respective thoughts and position about the use of Lua « advanced » features, I recalled that you mentioned the point of keeping the instrument Lua code as standard as possible (meaning Os independent) on all platforms, to keep basically the user from being frustrated when an instrument doesn’t work on a platform. This was your main argument against opening the language, and it made sense, in a way...

But as an afterthought, and as a matter of fact, this is already the case:
Most of the community instruments in the store are developed for one sim only, and even « worse » , they are built only using standard XPlane or FSXvariables and hence are not compatible with the latest add on “à la mode” (the forum is already full of complaints or requests for this kind of issue). On the contrary some very sophisticated instruments are working only for a specific add on (I am thinking about the Zibo ND by Jeeden, or the OVH developed by Russ for the IXEG, or my own OVH for the FFA320).

The “one size fits all” politic makes sense, but with the inherent default of keeping the level of features to the lesser common denominator. And has a side effect of putting all of the burden on you as the main developper, and having sometimes to recreate features from scratch (I know you love it! )

Even though I have no rights to tell you what to do (aniways that is not my point), I would like to state again my perception of the three levels of customers that Air Manager currently has:
1- Casual customers, that will never use the create/edit tab, and will merely either buy a paid panel or use one of the numerous community instruments available (sometimes even complaining/asking for free instrument devoted to their “super addon(TM)”, without being able nor willing to develop any by themselves). Their programming skills is kinda nonexistent and will probably stay the same. If they want to use hardware instruments, this is to be basically a “turnkey” instrument.

2- Serious simmers, which dedicate time and money for their passion, and are willing to take some time to learn and either develop medium to small instruments or modify existing instruments to suit their needs. Hardware instruments are on the menu provided they are easy to use/develop.
The embedded code editor is a welcomed addition.
But they will not have the skills nor the time to go deeper in instrument development, hence rely on either goodwill or advance in prepaid instruments. They are the main source of community instruments, and a great asset of Air Manager.

3- Computer geeks and Hardcore simmers, which have both the passion, the time and the skills to develop a sophisticated instrument, primarily for their own specific needs. And that will use whatever exotic features of AM for this purpose, including the Message Port (which by definition is completely system dependent, and I am still waiting to see any instrument using this feature on the community store ). They will still use Notepad++ or whatever external code editor for their use, though the recent debugging features are welcomed.

As an example, I consider myself as a mix of type 2 and 3, and as a computer programming amateur, AM is for me a tool to simply develop concepts for fun, try to learn new programming tricks, and a way to play with Skinman and draw things...
Using eventually these instruments in my sim is secondary to me, some of my instruments are WIP and will stay so. Guess Tony, Gilles and Keith to mention a few are the same...

The need for “maximum compatibility” of an instrument’s code can be a good argument for the type of users 1 and (in a lesser extent) 2, as I understand you at Sim Innovation don’t want the hassle to provide endless customer support due to exotic configurations.

But for the users types 2 and 3, the more features we have, the more things can be done. The apparition of the canvas is a very good example of what AM3.0 offered over AM2.1, along with RPI/Arduino interfacing
If these users are deliberatedly maintained “between rails”, I fear this will also end up with frustration as well, as some projects have to be put on the shelf because of the lack of feature, in the hope that the needed feature will be one day incorporated in future version of AM.

This reminds me the time when I started to develop a very basic graphic library in AM 2.1 using the “one pixel line” trick invented by a poster, this as a mean to further enhance the graphic features of AM at the time. I recall that this library was scarcely used to develop some concepts which are now commonly in use with the canvas features, such as parametric instruments or advanced ND display. I remember also this started out of my own frustration!

IMHO, the three categories of AM customers are equally valuable, and I definitely think that Sim Innovation should never neglect any of these. I know it is a difficult balance to keep, but that’s the key of any business.

My point is, there should probably be a reflexion about how to accommodate the different needs of the three categories of customers above mentioned.

As for the problem “features versus security” here’s my suggestion:
- Keep a list of “essential” Lua libraries available as an option for hardcore users. These would not be installed as standard, but could be included via “require” and be specifically installed by the user. This simple fact alone(along with the lack of documentation in the wiki and the appropriate disclaimer) should be enough to deter 80% of the people to play with fire!
But the remaining 20% would be happier and more importantly would eventually come up with new concepts/use valuable enough to be incorporated as standard in future versions.
This approach would be valuable for both parties IMHO.

- For security reason the instruments developed using ext libraries should either be kept only for the users’ own personal use (and as a policy would never make it to the community store for example), or if ever needed, could be distributed as a package (along with some library installation instructions and proper disclaimers) via other distribution channels than the store (forums/add on library such as XPlane.org’s for example), relieving Sim Innovation from any kind of support on these.

That is pretty much what already exists with tools such as FSUIPC Lua modules or FlywithLua/Python/SASL addons for example. Those modules use a tool/language to develop something completely independant from the tool itself.

Sorry for this lengthy and somewhat verbose “food for thoughts”, but I felt that I should express myself and advocate for a more open Dev environment for advanced users( at their own risk).

Please Corjan and Ralph, don’t take this as a criticism or an outburst, but merely as a friendly reminder coming from a long time and dedicated supporter. In Sim Innovations, there is the very nice word “Innovation” and I feel that this innovation most of the time comes from your customers, provided they can unleash their creativity.
Keith is in my opinion a perfect example (no pun intended) as I noticed that some of his endeavours actually ended as new features or improvements of AM.

Would be delighted to have Corjan, Ralph and Russ and other’s opinion.

Jacques

[Corjan]

Hi,


Wow, that is quite some reading

Don't worry about us getting offended. At the end, I'm happy when you guys cooperate with the evolution of Air Manager.
Unfortunately, sometimes we have to make choices that don't benefit the community.

I think this is such a case. At the end, it is a choice between freedom as an instrument developer vs. the stability of the complete suite.
I will always choose the latter if I'm forced to choose.

In general, I honestly feel like our product offer a lot of freedom to begin with. Surely if you compare it to similar products on the market today (simvim, panel builder, XHSI).

Also, in this particular case, I feel like the persistence and static_data API's come really close to offer the same functionality as true I/O would. It will for sure make life easier as well, since you don't have to deal with file formats, you can just throw lua variables around.


Corjan

[Sling]

Any thoughts on these requests Corjan.

As you suggested and as a means for getting code that used the io library working again, can I therefore ask for the basic file reading we currently have be expanded to include these features.

File creation.
File editing.
Files not restricted to the resource folder or perhaps another folder(s) that can easily be accessed by a user to add remove files such as flight plans, config/settings files etc.
A means from the API to be able to include code for file selection such as a free text/drop down selection type input.

[Corjan]

Hi,


That is going to be the same answer, sorry!

You can use persistence to create or edit data, it has an easier interface then a true file I/O interface. You cannot mess with files though on a file system level, because that is exactly what I don't want users of Air Manager to have to do.


Corjan

[Corjan]

The io library should never have been part of Air Manager. It is included by default when you create a lua context in code.

Sorry for the trouble if you are relying on it now,

Corjan