kaosfere

I bought this tonight and have only used it for a few touch and gos with the Wing42 Vega, but there were no immediate conflicts with ChasePlane, everything seemed to work just fine. As I say, though, that's only about 30 minutes of use.

Pretty sure they changed this in a recent release, and you can now specify a temp directory. (At work now and can't check.) Regarding download stalls/aborts, I used to see those a lot. Turning off the "beta" setting for parallel downloads solved that problem. That may have been stabilized recently, too.

Smacks of what I term "purchasing authenticity". You can see this happen in many hobbies which have a "professional" tier above them and stratified cost tiers to go along with it. One of my other passtimes is photography, and it happens there as well -- amateurs spend a lot of money buying professional level gear (like Canon's L lenses) for the authenticity that comes with it whether they need, or can even make use of, any of the functionality it brings. There is a special kind of defensiveness that comes with this, because the people doing it make having the gear part of their identity, and if anyone makes it seem less special, less elite, it becomes a threat to their ego. This can make them aggressive in defense of the "specialness" of what they have, because it is so integral to their self-perception. The funny part of this is that the actual professionals tend to not care as much. They have a tool that they need, but they already walk the walk, so there's no threat to them in people who may make their gear seem less special. In fact, quite the opposite -- if there's something that will do what they need, cheaper, they'll hop on it. I think we see this a lot in some of the "hardcore" fans of PMDG and FSLabs -- it is critical that what they spend lots of money for always be better than other options, because anything less is a threat to the authenticity they've purchased. I'm willing to bet that if you take as a group the people who are vocally defensive of the products from these manufacturers and dismissive of "everything else", you'll find it's almost entirely amateur simmers, with very few actual commercial pilots. What does it matter to them if an AS product is "as good as" FSLabs in some aspect? They still do the real thing every day. I'm not by any means saying this applies to all pros, or to all FSLabs/PMDG fans -- it would be irresponsible to make such sweeping generalizations. But I think it's a definite pattern. (If I were to buy a Bus it would be the Aerosoft one, because I refuse to do any more business with FSLabs, but I already own both PMDG and FSLabs products, so it's not like I can't afford / don't want them. I just have enough to worry about in my life without adding having to maintain my ego over flight sim products.)

Should be easy to find in the aircraft list, it's "Cessna 310R <tailno>".

The 310 should have installed in SimObjects\Airplanes\MV_C310R. See if you have that. An Ryan said, contact MilViz in their forum, they may be able to help you there, or at least confirm that it's something you'll need to talk to your vendor to fix. (It doesn't sound like you bought from them direct). The MV folks are usually pretty quick and helpful when you reach out to them (and the 310 Redux is awesome)

Have you calibrated your controller to make sure that when your throttles are fully back they send the right data to the sim? What do you have for a default flight? It might also be worth making sure that your default flight has throttles back and parking brake set, perhaps even fully cold and dark. I've had planes load in unfortunate states like that if my default flight is set up any other way.

I adore management sims of all sorts. I would definitely be likely to play this.

I really like the looks of this. It's like something Golden Age Simulations would put out, but done by someone who can texture a cockpit to a modern standard. I love the old birds GAS puts out, but in a world of increasingly common photo-real VCs I find it hard to sit in their cockpits for too long.

I agree, they'd be utterly stupid not to have changed/disabled everything by now. (And I'll spare the snark about the level of common sense they've shown to date...) But it's still a bad idea to continue to distribute that information, IMO.

To tooting or a moderator: Please remove the image from the first post as quickly as possible, or at least edit it to exclude everything below the message. That is a dump of user information including hashed passwords which, depending on their hashing algo, could potentially be cracked easily. It does appear to only contain information on FSLabs staff and resources, not customer info, but it is still irresponsible to redistribute it. I have been -- and remain -- critical of FSLabs, but this is still something that should not happen. [On edit: I have also reported the first post. I have no problem with it except for the inclusion of credential information.]

No, all current VR devices have a limited field of view. According to this both the Rift and the Vive have a horizontal FOV of 110 degrees, which is much less than the naked eye it around 180 degrees, IIRC. Having used a Rift with P3D, both native and with FlyInside, I can say that the FOV isn't the problem. Being able to turn your head makes up for that and you get used to it. It's the low resolution that makes reading stuff in the cockpit challenging that's the current limiting factor for me.

Your best bet for many planes is just to google for checklists. In particular for this one, if you search "a-36 checklist", this is the first link. The spreadsheet they link to looks pretty comprehensive, and includes emergency procedures.

Thanks for that link. In particular, from that page: This proves exactly the point I was making: the explanation that it's needed for eSellerate feels distinctly like bull-poopy. There is something more going on here. On edit: it looks like Skywolf deleted their link for some reason. It was https://support.esellerate.net/528#win.

I'm staying out of the debate regarding whether developers owe fealty to customers or vice-versa. However there are a few facts/misunderstandings here that need some clarification. First, regarding the claim that it is "normal" to install stuff into the 32/64 bit system directories -- while doable and not unheard of it is definitely not good practice. Placing things into the WIndows directory itself is something I'm not fond of, but it's not abnormal to do it. Violating the System directories is a bit more of a red flag for bad practice. Second, regarding FSLabs' defence that it's part of their eSellerate configuration -- this may be, but I have examined other software installers for applications that use eSellerate (in particular, various products from FSDT, who not only use eSellerate but also the same Inno Setup installer that FSL uses, which made for an easy comparison). FSDT install their eSellerate files into app data directories and into C:\Windows. I'm not keen on the latter, but as I said, it's acceptable, and certainly moreso than into the System directories. Third, they do not use any obfuscating names: they are "eWebClient.dll" and "eWebControl365.dll", nothing that can be confused with a system file. It's possible that FSL are using a different eSellerate configuration, but that's addressed by the next point. Because, finally, if you search google for "cmdhost.exe" and "eSellerate" you see very few hits, most of them related to this particular controversy. That indicates that FSLabs are definitely using non-standard practice. That is all concrete provable fact -- few matters of opinion there. I welcome provable arguments to the contrary of what I posted above. Now for the opinion: without ascribing malice to FSL it still cannot be denied that they are using questionable and nonstandard methods (deceptive file names installing into sensitive system directories) that, in spite of their initial defense, are clearly not necessary for the proper functioning of the DRM protection they are using. Given the history of this company and other recent controversy, that's at least a really bad look for them, and the explanation they have given is, at best, admitting to shamefully bad practice. They have already made admissions in the past that indicate that they are willing to try to intentionally deceive their customers. In that light, this is a worrisome development. I'll spare you the citing of my technical credentials, decades of experience, and various professional certifications. I don't like the you-know-what waving.

Gladly! I got a response from the author on reddit, and this is in part what they said: While it really seems like the project is dead, it isn't. It is in a paused state. I had to stop working on it because I don't had too much other stuff to do, so the motivation for working dropped. At the moment, I have version 1.5 locally which is working quite - just needs some small bug fixes. I plan to update it within the next two month, but I can not guarantee that at the moment. I will add you to my "people-to-notify" list as soon as the update drops. Because the tool uses FSUIPC, I can only access the values FSUIPC sends me. Unfortunately the FSLabs A320 has a lot of logic outside of the sim, so quite a lot gets bypassed and doesn't get recognized by FSUIPC. I don't plan to add other SDKs/APIs because that would cost me too much time to create / maintain it. Also, it's apparently written in Delphi. An interesting choice, but I guess for personal projects you use what you know/like.