markdf

I'd certainly be interested in at least a potential conversation about it at some point - I'm a recently retired C/C++ dev (I'm assuming that's what it's been built in - if it's VB I'd unfortunately be lost). I spent most of my career in embedded systems development, but the last few before stopping working professionally involved Lua as a Train Simulator addon developer, even if nothing comes of it, it would be a shame if bug-fixing/maintenance ceased for such a useful tool. Obviously the important thing is this though: At the end of the day it's your code, and your decision what happens - and I respect that above all else.

Thanks for the many years of support. Is there any scope for another developer picking up the maintenance in the future?

Like I said, I appreciate your correction - I'm just a little too used to people nitpicking just for the sake of it, so apologies if my reply came off a little abrasive, I often come off a lot more blunt than I intend.:/

Maybe provide more info so people have a chance of helping you. Also, insert obligatory notification that PMDG require you to sign your post with your full name

Yep, beyond that your only option is to rebind your throttle to specifically "Throttle 1" or "Throttle 2" in the control settings. Otherwise, yes the only way to do it without changing your controls is probably to get a yoke/stick with a twin throttle

Apologies for barging in on this - but BEX can also (sometimes) be caused if Data Execution Prevention is enabled globally and FSX/P3D isn't excluded from it, possibly worth a check too

My bad, I doubled linear dimensions not pixel count, but the overall point remains unchanged that DSR and SSAA are both applying the same method to achieve a similar end goal - therefore the two compound the strain on the card and can thus lead to losing frames - so while I appreciate the math lesson, you are kind of splitting hairs without actually adding anything to the discussion or changing the point I made

Thanks for the confirmation. Unrelated, but as someone who just lost their weekend to fixing an unexpected server failure I sincerely hope your one doesn't give you any more hassle

Am I correct in understanding from that, that the plan for offline access has been moved to pre-1.0 then? Which if so is welcome news.

If Chaseplane failing causes his sim to fail to start, then no. The end user should not have to play a game of "swap the config files" because of a single program's failure to have any form of graceful error handling when the servers go down.

That may be, but your not noticing doesn't make it any stranger that other people have had issues or make those issues any less relevant or important. In fact, just flicking through myself has shown a few more server failures than I was initially aware of.

I'm saying exactly what I said, most recently the servers were down today in fact, but I'm sure you're capable of reading through the forum so I won't summarise everybody's complaints here since just a quick flick through the topic listings can answer that. It fails any time anything along the route between the end user and the server fails, whether that's because of their servers, the ISP or anything in between.

Not that strange except for the fact that you haven't been using it at the other times their servers have been down, and you've never used it on an unreliable internet/network connection. Pretty simple to explain really.

Thank you for the kind words Jack, it's always appreciated to know that I'm making sense to someone other than myself :) The response I see to a lot of complaints about things like this (not just on this product but others as well) is that "It's still in beta...", or "after the beta", but personally I've always taken the view that if it's good enough to take non-refundable money then it should be dependable and stable. If you can't guarantee that (especially as I said previously - on a product that should be capable of running without the servers) then I believe money should be refundable up until the point that the product reaches a finished 1.0 stage, largely because whilst being charged to be used as testers customers have no other way to hold a developer to account for poor decisions. In contrast over the weekend while I was dealing with a server failure at work, I reinstalled a product where pricing starts at $1600. It phoned home once, verified it's license and now runs completely happily offline. Job done.

This is exactly why always-online verification fails, and why products that use it should not be allowed to overwrite the configuration of the core sim on a permanent basis - especially when it's rapidly becoming clear that CP's backend is just not up to the job of supporting something that needs a connection 100% of the time. System's like this must have some tolerance for connection failures, there's no need for a $40 piece of software to fall over every time it can't phone home. Funny how only yesterday (and one page back) my point about needing to account for server failures needing to be accounted for was dismissed and I was told that failures along the connection path (including servers, ISP and home equipment) were below 1%, and yet we've already had multiple incidents just this year with CP alone. Things fail all the time and something like a camera plugin, where everything except the preset library/online backup system run on your local computer have no excuse for ceasing to function every time there's a glitch somewhere along the line.

There's a huge number of cracked protection schemes out there that would beg to differ - the sheer number of applications and games ranging from indie to multi-million dollar budgets that fail to stop pirates circumventing their protections proves otherwise unless you're privy to secrets that the Microsofts and LMs of this industry are not, but I fear this debate will go around in circles and never lead anywhere but further off topic. I'm not going to subscribe to the philosophy of assuming everyone is a thief until proven otherwise, and you clearly aren't going to sway from that position. Had you said "Piracy can be managed", or "Piracy can be reduced", I'd probably find it easier to agree. Ray has already given many examples of alternate schemes in use by various companies in this very thread, so I'm not going to sit here and retype them This level of verification and restriction is not the normal for the flight sim market of today - this is the extreme end of the scale. I've bought from a lot of companies over the years, not one of them has ever even strayed close to this territory. Before encountering Chaseplane the ability to reinstall my flight sim addons was not even a consideration. This fails at being "least intrusive", were this issue removed then I personally would almost never be aware of the background verification. I've said that I'm willing to pay, willing to consider options like dongles etc, despite you erroneously claiming I'd dismissed all of those as options - I've agreed with your suggested alternatives and yet you're still debating the connection issue with me (and in fact I never dismissed those options as acceptable in the first place) I've said this many times in various ways, but here it is in bold and as simply as I can say it so there can be no incorrect assumptions/interpretations/misunderstandings about my key point: My main issue with the current system is the limit on installs. In a scenario where I can reinstall freely at will I do not care about having to stay connected (so long as the system does not collapse at the first dropped packet.) I do not care what it costs, I do not care if it means keeping a dongle attached. If you disagree or want to debate me then that's fine, all I ask is you actually debate the thing I'm actually complaining about. If you just want to debate about how always-on connection is an inescapable fact of software then you're debating the wrong person - I've got no interest in arguing that with you beyond the exception mentioned above: specifically how it renders the activation limit redundant. Beyond that as long as it happens in the background I really couldn't care less. I can't help but feel you're arguing with what you think I'm going to say rather than what I've actually said. EDIT: Oh, and at this point I'm off to bed, so you're not likely to get any response this side of Thursday. Because I'm way too tired for this right now, have a good evening in whatever your local timezone is :)

I don't actually have issue with the USB approach - if it means I can reinstall as needed, then fine. That's what I care about the most, the ability to remove and reactivate the license as needed for my personal use. Give me that and I'm happy. Also didn't say that I wouldn't be willing to spend a little extra for the convenience and freedom. As I said - it's a great product let down by an overly harsh activation policy. Offer me a solution and I'd go as far as buying a second copy at full price right now. Frankly price is way down the list of priorities for me, and a long way below convenience. I've just spent thousands getting an apartment adapted for disabled access to give me more freedom to move around more freely - I really don't care about a $5-10 variation in price for a software package. I do stand by my statement about piracy ultimately being inevitable - wrong as it may be, if the demand is there it'll happen, so we can't let the fear or threat of it be an excuse to start hampering the experience of legitimate users. A good system should be (mostly) transparent to me after it's set up - be that dongle, remote license checking whatever, as long as it doesn't start becoming an issue that gets in the way of using the software. Other companies in the same industry both above and below this on the cost scale manage to deliver systems that strike an acceptable compromise between security and flexibility so I refuse to be scared by the boogeyman and told that the current system is the only reasonable solution for the developers. In summary, my complaint here is that there isn't a solution on offer here, paid or otherwise, to get around the three month reactivation policy. If one is offered I'll be at the front of the queue to sign up for it.

A very good question indeed. Personally mine is off for a more stable overclock, but I too am curious what the general consensus is these days.

Oh, absolutely. I was only mentioning it in passing in response to a "PMDG would never..." statement - I never meant to imply that you would (or should) do it again, just that you'd release whatever you thought was a worthwhile addition that doesn't lower the quality of the base product. I sadly never owned the 747 back then, so I what little I know about the topic is all second hand (although I'm not quite as sad anymore now that we're getting a real -8 this time!) Edit: I'm going to shut up now, haven't had my morning meds yet, and reading that back I've started to ramble somewhat.

I am on the edge of the scale, but my hope is that my example will demonstrate to them that single activation with a fixed, inflexible time restriction can negatively affect legitimate customers - frequent reinstalls doesn't (and shouldn't automatically) equal pirate or nefarious intent. The reason I'm speaking out so strongly here is largely because under the DRM is an absolutely fantastic product - on the basis of functionality and features it'd be my first choice every time and I'd be shouting it's praises from the rooftops. If it was a badly written program I wouldn't care enough to say anything, I'd just walk away from it, but as it stands I've got zero negatives or complaints about the actual program, which is saying something for me.

Twice this year I've had to ticket because I fell foul of having to reactivate due to my Windows install needing resetting or wiping (on the same machine) and there's been a couple of other times where I just haven't bothered putting Chaseplane back on the system at all to avoid having to write an email to justify why I need to activate again.

That's right - once you activate, you can't reactivate again within three months without opening a ticket. That's the part which really pushes it over the edge for me - my gaming PC is also a development PC for work and I'm frequently swapping hardware around in there or reinstalling completely so I'm not a big fan of having to repeatedly ask permission to use something I've paid for. (Haven't tested it since I reinstalled Chaseplane last, but I know that enabling certain Windows features such as Hyper-V can also change the configuration enough to trigger some reactivation systems)

As you say - there's a lot of examples of developers in the market who've already produced consumer friendly systems to guard against piracy without punishing their users. I'm a developer myself and piracy is an ever present issue, but fear of piracy isn't an excuse for going over the top on protection mechanisms. No matter how good the DRM is, sooner or later it's going to get pirated just the same - Microsoft haven't stopped it, LM haven't stopped it, in fact nobody has. The key is compromise as in your example with Aerosoft and FSLabs: I've never had any issue with reinstalling their products. What concerns me is the thing about removing the connection requirement after beta - is piracy somehow less of a problem after beta? Or is "after beta" just a good answer that avoids directly confronting the issue or kicking it off into an indeterminate point in the future without having to commit to a timetable for removing it? The simple fact is that the people who really don't want to pay won't pay and sooner or later a cracked version will surface no matter how many restrictions they decide to cram into the product. If you approach development from the mindset that your customers are more likely than not to be pirates/criminals, you'll only end up fostering that in the long run whilst at the same time killing any good will towards you when outages cause people to not be able to use the software. Chaseplane is a good program, and I like it a lot - but the DRM polices make me regret the purchase in hindsight to the point that I've delayed a planned reinstall of my PC for a week while I decided if I was going to go through opening another ticket or just buying a competing product that won't cause me the hassle in the future. On balance the functionality just doesn't justify the installation/usage restrictions for me, so in the absence of being able to return it I'm just inclined to write it off as a lesson learned.

"Enough times" in this case translates to "one activation within a three month period" - there's no end user accessible way around that except opening a support ticket to explain yourself. Preventing piracy is fine, but when we start to stray into the territory of asking paying customers to email justify reinstalling if it falls within a three month boundary then it's a step too far. In a system where it's both dependant on an activation system AND being connected to the internet with no disconnections during usage, there is no good reason to not allow the customer to deactivate/reactivate/transfer license themselves since it's painfully easy to verify that the same license is only being used in one place at a time (and can only be activated on one machine at a time) As for the part about going and doing something else: If there's a problem on my own machine preventing me using my software, that's my problem to deal with - I don't mind that. If the problem is caused by over zealous and over-reaching copy protection then it's time to re-assess that system. Good copy protection should be as transparent as possible to legitimate users - I don't care what process it follows in the background, if I'm not doing anything unreasonable with it then I shouldn't really be noticing it doing it's job. (And on every other flight sim product I own, I don't notice it at all - Chaseplane is literally the only one that needs any special attention or outside intervention when I reinstall my system) A lot of people here fly when they can, and don't have to deal with work/family etc. If they can't make use of the software in whatever window they've allotted quite often they might not have another chance until the following weekend for example, and if that happens then it highlights an unfortunate design flaw.

You and I probably disagree on the temporary offline issue - which is fine, afterall there'd be no point in discussions if we all shared the same views :) You've picked up on my key point though - I only take serious issue with the always online when compounded with the deactivation/activation issue. If activations could be managed then I'd accept the internet connectivity as a necessary evil (although a brief allowance should be made for connection glitches at runtime - lets say 15 minutes before giving up?) The allowing for a number of activations in a time period before forcing resorting to tickets, and releasing each one after a fixed amount of time is a good idea - and one that has worked well for me with some of my other products (such as FSDreamTeam scenery which follows that model for example) Sometimes I might need to reinstall 2 months in, other times I might not touch my hardware/OS for 8+ months, so it allows for flexibility while still protecting the developer's investment.