What a fuss over something so inane. 

more legitimate customer support issues, simply because he/she didn't follow simple instructions.

 

Of course this is THE number 1 issue you have to deal with in technical customer service

 

I do this the whole day for three different companies (two of them in the X-Plane world, another in the "real" world), and even at the 1000th repetition of the typical, absent-of-useful-information "It does not work!!" ticket or call, customers have to be pampered, politely and patiently, because they are the customers, and because as a developer you can't expect users to read manuals, or to understand them in the way the manuals were intended. (I did part of my PhD thesis about this challenge.)

 

HOWEVER, sometimes we (i.e. people working at customer care) have to make clear statements that some things are not possible, not planned, not feasible, not free of charge and not going to change -- without explaining all the technical detail. And sometimes even a blunt "end of discussion" message is needed. This does not feel good (neither for the customer nor the person having to do this), but it's still necessary. Sometimes, in rare cases.

Of course this is THE number 1 issue you have to deal with in technical customer service

 

I do this the whole day for three different companies (two of them in the X-Plane world, another in the "real" world), and even at the 1000th repetition of the typical, absent-of-useful-information "It does not work!!" ticket or call, customers have to be pampered, politely and patiently, because they are the customers, and because as a developer you can't expect users to read manuals, or to understand them in the way the manuals were intended. (I did part of my PhD thesis about this challenge.)

 

HOWEVER, sometimes we (i.e. people working at customer care) have to make clear statements that some things are not possible, not planned, not feasible, not free of charge and not going to change -- without explaining all the technical detail. And sometimes even a blunt "end of discussion" message is needed. This does not feel good (neither for the customer nor the person having to do this), but it's still necessary. Sometimes, in rare cases.

 

Pampered, politely, sure.  And Cameron would agree with you.  It's when they start telling YOU that YOU are wrong, and they want it done THEIR way.  And if they can't do it THEIR way, they keep asking "Why??".  And if they are told why, they don't like the reason.

That's when it can get irritating.  Especially when a reason was already given.

I think this is where it probably started to go awry:

 

 

 

How hard is it to code an extra dozen lines or so to scan the entire Aircraft directory for the B733.acf file, and for good measure, throw in an MD5/SHA1 check-sum check? Do we need hard-coded file paths in this day and age? Is the 737 Classic add-on so fragile that a different parent directory will break functionality? 

 

I appreciate the fact that you wanted a slightly more technical answer to your query. You might be more code-savvy than the average user. I don't know you or your technical background (I'm not digging! I don't need to know ) X-Aviation don't know you either, but with all due respect, asking a developer how hard it is just to do "X" could be interpreted as a direct slur on their capabilities. Forum speak (i.e. what we type) is at risk of being read in many different ways, some worse than others.

If we were sat around a table face to face, then things may have been different.

I am also having a hard time seeing what the problem is with not being able to install the plane exactly where I want to. It's not like you have to give away your first born to use the IXEG...? It's basically a non-issue and pestering the devs about it takes away time from legitimate issues that might exist. 

 

EDIT: For example the Gizmo soft crashes I'm getting now with 1.0.6... :(

 

 

It's when they start telling YOU that YOU are wrong, and they want it done THEIR way.  And if they can't do it THEIR way, they keep asking "Why??".  And if they are told why, they don't like the reason.

 

That's part of my "HOWEVER" paragraph Sometimes, you have to make perfectly clear that a further discussion won't change anything, even if the customer is not happy with that. Of course you always need to find a balance between user wishes and developer possibilities, but, so bad as this sounds for the customer, in the end developers are not obliged to accept every request for change, and they are also not obliged to explain the reasons behind request rejections.

Ladies and gents, thank you for all your replies. Before you get out your pitchforks/tridents/assault weapons/ballistic missiles - please hear me out. I have nothing against X-Aviation as a whole, or their products, which I know are truly superior to what other X-Plane developers have offered since. Their customer service, when it comes to updates, is spot-on, and when we request for a downloads reset, barring server issues, is responded to quickly and professionally.

 

However, I have personally seen smatterings of elitism and pompousness from developers and support staff there and even at the x-plane.org forum, who simply say, 'you're the customer, we do it our way, and if you're not satisfied, don't use our product'. Unfortunately, I'm not even an adult yet with a fairly large salary to just write off a purchase and move on with life. I'm in my late teens, and am a conscript who is given a paltry $400 in allowance. I spent nearly a quarter of that in purchasing the IXEG 737; I can't just stop using it or not notify the developers if I feel a decision they've taken is, I feel, wrong - I'm obviously not getting my money's worth, then.

 

As for why I brought this up, the reason was simple - I wanted to keep all my large tube-liners in one directory, simply for organisation's sake: GA planes in one place, fighters in another, props in yet another, and so on. Certainly, as a few of you have mentioned - a relatively minor issue. I just felt that requiring to have a plane in a particular directory was strange, and completely uncalled for at that point in time. I've used X-Plane for six years now, and this was the first time I'd ever encountered such behaviour.

 

I then realised that the 737 installer as well as the updater also placed the Gizmo64 folder in /Resources/plugins/ which was probably the cause for all this. If the Gizmo64 folder had been placed with the 737 aircraft folder, and was installed with the 737, à la how SASL works with Flight Factor's planes, then we wouldn't be having this discussion at all, since the plugin would simply go to its parent directory and perform the update. Now, however, Gizmo64 goes to one place, the 737 must go in another, and we have the uninstaller for the plane in yet another place, in the X-Plane root directory. If anyone has run Skyrim (or any other recent Bethesda game) with mods and add-ons, you might understand why I am being pedantic about directories - a seemingly minor matter. Until a virtual-directory manager came along called Mod Organizer, mods would tinker directly with the game files and result in a terrible mess when several different add-ons, changing conflicting files, were used.

 

In fact, we can look even closer - I (and probably several others of you here) have heard horror stories of how people wanted to change disk drives, or clean-install an operating system, and how tedious it was to migrate their FSX install with all their tweaks, plugins and add-ons over. With X-Plane, we have it simple. Even in this very forum, a short while ago - Tony expressed amazement at how easy it is to transfer an X-Plane install from OS X on one system to Windows 10 on a newer one. I am just afraid that with the advent of installers in X-Plane, we will lose this immense flexibility we have. It's one short step from requiring custom directories, to writing to the registry, to installing in a different directory altogether. 

 

I meant no offence to any of the staff and developers at X-Aviation, some of whom have been genuinely pleasant to see in action (specifically Captain Jan Vogel). However, some of Cameron's ad-hominem attacks (calling me lazy, ignorant, borderline stupid, etc.) were genuinely hurtful. If I were truly lazy, I'd simply have changed directories and moved on with life, instead of even bothering to type out such a post. 

 

Mario, thank you for a developer perspective, but I really hope that you understand where I'm coming from. My (a customer's) view is simply as such - if many developers do it this way (use .zips, stick to one folder location and keep things tidy), and it follows X-Plane's ideals, then why does X-Aviation have to do it differently and result in headaches for itself and others? Your post here, Mario, puts perfectly into perspective what I'm trying to say.

 

I likened X-Aviation's actions to MNCs because this reminds me of a highly anti-consumer and even anti-OEM policy that nVidia implemented with a driver update last year: notebook GPUs were locked from overclocking. This caused a huge uproar, causing nVidia to go back on its tracks and release a patch to re-enable overclocking. nVidia's reason: laptops are too poorly cooled to allow overclocking to happen. Users' reply: No, we have thick, powerful, well-designed laptops (something like this) meant to push hardware to its limits; some of our products were even advertised for overclocking.

 

To be clear - X-Aviation's actions are nothing like what nVidia had done, but it felt restrictive. That's all, everyone. I hope you understand why I made this post and the one at X-Aviation. Now, obviously, I'm resigned to moving the 737 Classic out of Heavy Metal, and creating a 'X-Aviation' folder just for one plane, or create some sort of symlink. Oh well... you gain some (now we have VNAV without needing a T/D! Excellent!), you lose some.

Unfortunately, I'm not even an adult yet with a fairly large salary to just write off a purchase and move on with life. I'm in my late teens, and am a conscript who is given a paltry $400 in allowance. I spent nearly a quarter of that in purchasing the IXEG 737

 

Best money you ever spent.

:wink:

Best money you ever spent.

:wink:

Fair enough. The 737 Classic is a work of art.

Ok ScramJet . .. I gave you a +1 completely by mistake. I meant to hit the selective quote button ... roflmao

 

You said this .. " I just felt that requiring to have a plane in a particular directory was strange, and completely uncalled for at that point in time. I've used X-Plane for six years now, and this was the first time I'd ever encountered such behavior." 

 

That's elitism right there lol. 

I'm done with this thread, your sense of entitlement is staggering. Grow up kid.

That's elitism right there lol. 

I'm done with this thread, your sense of entitlement is staggering. Grow up kid.

I'm sorry, but you mean being baffled by new behaviour, and finding it unnecessary = elitism? 

Why don't you just create a shortcut, it would probably work

Two observations;-

 

- The 'issue' is rather minor IMHO, and it would perhaps have been less stressful for you to just accept it, a little earlier in the timeline.

 

- The attitude shown by the vendor is terse and perhaps unnecessarily rude in the quoted passage, and I have seen other examples on the X-Plane forums that do perhaps suggest that Cameron is a little on the hot headed side. :smile:

 

 

Mario, thank you for a developer perspective, but I really hope that you understand where I'm coming from. My (a customer's) view is simply as such - if many developers do it this way (use .zips, stick to one folder location and keep things tidy), and it follows X-Plane's ideals, then why does X-Aviation have to do it differently and result in headaches for itself and others?

 

I can fully understand your view, because I am a customer, too. And very often I have ideas how something could be done in a way more convenient for me -- but I also know that I am just one customer, and that the developers have to respect the needs of many other customers.

 

That's why I brought up the scenery_packs.ini example. From my personal view, I detest this file. In my personal view, it was one of the biggest strengths of X-Plane that no scenery configuration files or databases were needed, and for me, scenery_packs.ini was the first step to a FSX/P3D-like way of obstructing scenery organization. But from a developer and customer care view, as well as from my research in this field, I know that organization on a file system level is not for the majority of people. And indeed, freeware tools like XOrganizer, which provide a GUI for this task (but further obstruct the actual process) are quite successful.

 

 

 

I am just afraid that with the advent of installers in X-Plane, we will lose this immense flexibility we have. It's one short step from requiring custom directories, to writing to the registry, to installing in a different directory altogether. 

 

This can very well happen. It already does. For "traditional" X-Plane users, this is a loss of flexibility. For new X-Plane users, esp. those coming from gaming or from FSX, installers are the way to go. Having not an installer and being forced to organize files manually or with a plain text file, such as in Custom Scenery, is seen as bad usability for some of them. But usability is not the same as operability, and you have to balance both sides. How you do it depends on who you want to reach.

 

By the way, regarding Gizmo (because you mention on several occasions that it's installed globally), this has a lot of advantages -- not just for the developer, but also for the users. Because it makes updating so easy. Compare that to GroundTraffic, for example -- I have installed that plugin in more than a dozen scenery folders, in a lot of different versions. They are all loaded simultaneously, because it can't be installed globally. I would feel much better if I had one version of GroundTraffic installed globally, because then I knew which version I'm running, and that I can keep it up-to-date easily (because the scenery developers usually don't update the plugin they include).

 

I can fully understand your view, because I am a customer, too. And very often I have ideas how something could be done in a way more convenient for me -- but I also know that I am just one customer, and that the developers have to respect the needs of many other customers.

Thank you very much for saying that, Mario. In turn, I regret having made a mountain of a molehill. Nevertheless, Cameron's rather incendiary replies made me feel quite terrible. I ought to bring it up to him. 

 

 

 

This can very well happen. It already does. For "traditional" X-Plane users, this is a loss of flexibility. For new X-Plane users, esp. those coming from gaming or from FSX, installers are the way to go.

Fair enough - even PMDG has done it with their DC-6. I use plenty of freeware like 7-Zip, HWMonitor, and try to use the .zip versions whenever available. I feel it's a rather unfortunate trend to tend towards installers, but when the tide goes one way, we have no choice but to adapt and follow.

 

 

By the way, regarding Gizmo (because you mention on several occasions that it's installed globally), this has a lot of advantages -- not just for the developer, but also for the users. Because it makes updating so easy. Compare that to GroundTraffic, for example -- I have installed that plugin in more than a dozen scenery folders, in a lot of different versions. They are all loaded simultaneously, because it can't be installed globally. I would feel much better if I had one version of GroundTraffic installed globally, because then I knew which version I'm running, and that I can keep it up-to-date easily (because the scenery developers usually don't update the plugin they include).

You have a valid point there, Mario. Could we then call it a limitation of X-Plane instead - the way plugins are handled? Hypothetically speaking, could Laminar restrict all plugins to go into the /Resources/plugins folder, to ease updating and have only one instance of each plugin running? I myself have wondered why I had five instances of GroundTraffic running.