Jump to content


New Members
  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

9 Neutral

About Steeler

  • Birthday July 11

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
  • Interests
    Playing music (guitar), developing software, photography, flight simulator

Flight Sim Profile

  • Commercial Member
  • Online Flight Organization Membership
  • Virtual Airlines

Profile Fields

  • About Me
    Flight simulator enthusiast

About Me

  • About Me
    Flight simulator enthusiast of the 80/90ies, newjoiner since FS2020, author of Sky Dolly, a free flight recorder
  1. Dear community, I am excited to announce that the latest Sky Dolly v0.6 preview release has just been made available yesterday: https://flightsim.to/file/9067/sky-dolly Sky Dolly v0.6 as reached a major milestone, namely the support of database (SQLite) persistence - the "logbook". Flights are automatically persisted - away with pesky file handling 🙂 Features include: Smooth replay with cubic spline interpolation of the sample points Variable record rates, from as low as 1 Hz (great for conserving space on long commercial airline flights) up to "auto" ("as fast as possible" - great for "acrobatic flying") Basic simulation variables "with visual impact" are recorded: flaps, gears, ailerons, rudder, spoilers, ... Initial flight conditions, aircraft information, waypoints and simulation times (local and zulu) are recorded Basic store / restore / delete database functionality (including backup and disk space optimisation), with sophisticated flight filtering on the roadmap Easy and inutitive user interface, with keyboard shortcuts Very resource friendly (< 1% CPU usage during recording, on an i7 4.2 GHz CPU) Basic CSV import/export Source and (older) binary releases: https://github.com/till213/SkyDolly Happy flying and recording 🙂
  2. Ah, and one more thing: I did not intend to imply that wing folding (as requested per simulation variables FOLDING WING LEFT|RIGHT PERCENT) wasn‘t working. I was asking whether it would work (when requested via the mentioned simulation variables). Because if the answer was „yes“ then I would feel a strong urge to purchase the Corsair (once in the sim marketplace)… (which makes it obvious that I don‘t own that aircraft yet, otherwise I would already know the answer to my question respectively could verify it myself, e.g. with the „SimvarWatcher“ example app which comes with the SDK). P.S. I don‘t see an „edit post“ option - yet? Perhaps that‘s because of my „noob level“ here in the forum (my posts still need to be audited by an administrator), or because I am using the „mobile web version“ right now… in any case, sorry about the consecutive posts.
  3. Oh, I am sorry about the confusion here, perhaps I wasn‘t clear about what I meant when asking about the support of simulation variables: my only intent is to use them via the official SimConnect API which exposes those simulation variables to external application. Most of them can also be „written“ (e.g. the mentioned FLAPS HANDLE INDEX or the CANOPY OPEN), others are „read-only“ (for one reason or the other). So I am specifically talking about this here: https://docs.flightsimulator.com/html/index.htm#t=Programming_Tools%2FSimConnect%2FSimConnect_API_Reference.htm By no means do I intend to modify any aircraft configuration files. And yes, I fully agree with your „whatever you do it‘s your fault“-policy in this regard. Full disclosure: I am the author of one of the free „replay tools“, hence my interest in the support for those simulation variables. But as I am developing the recording application for my own enjoyment - and hopefully the usefulness for the community ;) - I believe my motivations are leggit ;) And hence my initial question whether the Corsair would „react“ to changes in the simulation variables FOLDING WING LEFT|RIGHT PERCENT (which are writeable) and CANOPY OPEN (where I understand the answer was „no“ - because for stress crash reasons). And to be clear: I am mostly (only) interested in the simulation variables with a „noticeable visual effect“ (flaps, ailerons, … and of course wing folding) - not in accurately reproducing every single lever/switch operation (e.g. enabling autopilot or setting some heading/course/track etc.) That‘s just fair game and I do understand „time to market“ commercial requirements etc. and that you have to „use what‘s there (in a working state)“. So all I am asking / hoping for is that you - as „registered developers“ - do „actively“ report those deficiencies to Asobo and once they are improved / fixed in the SDK / FS2020 that you keep updating your own products as well (if „commercially viable“ - and I do wish that you make lots of money with the Corsair! ;)) Being an „early adopter“ not only means to „wade through unfinished APIs“, but hopefully also gives you the opportunity to actively improve/influence them! I am absolutely fine with that: I take an honest „sorry, can‘t do, won‘t do“ answer anytime over some BS-marketing ;) Thank you for your time for reading my post!
  4. Well, that's not the kind of answer I was hoping for as a consumer: I consider the SimConnect API integral part of every addon product, so every aicraft should report and react to simulation variables as far as possible. Yes, I absolutely agree that the state of the API is... well, "improvements can be made" 😉 But many simulation variables such as the FOLDING WING LEFT|RIGHT PERCENT, TAILHOOK POSITION etc. exist since long time. And yes, not every special lever can be properly modelled/controlled with simulation variables - simply because no such variable might exist yet. Then that's where "local variables" come into play (I guess - again, I am not familiar at all with aircraft design aspects of the SDK). If there are issues with the simulation variables - such as the mentioned "stress crash" - those should be actively reported by every developer to Asobo, for futher improvements. What worries me more however is the "if you break it, it's your fault" part of your reply: it's one thing if the aircraft does not react at all to simulation variable value requests (e.g. the Spitfire does not react either to CANOPY OPEN, as it uses "local variables", just like the T-45C Goshawk). Now as a consumer of those aircrafts that is disappointing, but I can understand that the API "might just not be there yet". But an aircraft (the logic thereof) should never "break" if an attempt is made to request simulation variable changes. And if it does, I expect the developers to take care of it. Anyway, I will hold off from purchasing more aircrafts for the time being - I was very much looking forward to see the wing folding in action! - and observe how third parties are embracing the SimConnect API respectively whether Asobo will manage to get it into production quality anytime soon. Because latest when Asobo is providing their own "replay functionality" within FS2020 the question how to record all levers and handles in an aircraft will popup again (also for us consumers).
  5. That is an interesting point, one which I hadn't considered. Ironically the two aircrafts that do support the CANOPY OPEN simulation variable (that I know of!) are fighter jets: the freeware Dassault Dornier Alpha Jet and the Fiat G.91. But yes, in both cases landing procedures do not foresee to open the canopy ;) But I am definitively going to check out at which speed a stress crash would happen. The greater picture here is of course that IMHO Asobo should make sure that every aircraft properly supports their SimConnect API: the aircraft has a tailhook? -> It should support the existing TAILHOOK POSITION simulation variable. Canopy? -> CANOPY OPEN. Wing folding? -> FOLDING WING LEFT|RIGHT PERCENT. Etc. If there is an issue with "stress crashes" which should not happen for a particular aircraft / canopy style then that should be reported to Asobo and e.g. an additional "stress speed threshold" should be introduced. That would be the proper solution. But yes, I very much agree that the SimConnect API appears to be in a very "work in progress" state. But given the fact that it exists for like two decades already doesn't necessarily raise hopes that it will ever be "cleaned up". For instance the FOLDING WING HANDLE POSITION: why is it just readable? Why is the FLAPS HANDLE INDEX writeable then? Whether a given simulation variable is only readable or both readable and writeable seems like an arbitrary decision, or rather like an afterthought by the API designers. One can only hope that with the popularity of FS2020 there will be efforts made by Asobo to "clean the API" up, such that it also becomes more popular (or actually "usable") by aircraft designers.
  6. Out of curiosity (I am not familiar with the aircraft modelling aspects of the MSFS SDK): are there technical reasons or other advantages for not supporting e.g. the simulation variables CANOPY OPEN and FOLDING WING LEFT PERCENT, FOLDING WING RIGHT PERCENT? According to the SDK documentation (SDK Documentation (flightsimulator.com) they should be both readable and writeable?
  7. Hello, does the Corsair properly support the SimConnect API? Specifically does the canopy and the wing folding react to setting the corresponding simulation variables? Thanks!
  8. You get access to the next and previous waypoint of the current waypoint segment, including lat/lon/alt. Unfortunately there doesn‘t seem to be a way to get the entire flight plan (or at least the first and last waypoint). Alternatively you could subscribe to the „airport facilities“ list, but a) the FS2020 implementation is currently somewhat broken and most importantly b) it won‘t tell you the final destination either. Only the airports within a certain radius (if it would work).
  9. I can help here from a first hand experience (Mac user here, too ;)). Technically: yes. In my case I have installed Windows 10 on a separate, external SSD. Just because I did not want to "mess around with the fusion drive" that is installed in my iMac 27" from 2017. And I wanted to have a "clear separation of data" etc. - but a "boot camp installation" on your main drive should work equally well (for as long as Windows runs "natively" on your Mac, and not in some kind of virtual machine, that is). Any "USB joystick" should work, really. I had a several years old 40+ EUR "plastic joystick" from Logitech and now a Thrustmaster HOTAS WARTHOG throttle and stick. Everything works as expected. Of course it always boils down to "how many buttons and axis of a specific joystick are recognised and supported", but that's rather an FS2020 specific question than a "bootcamp / Mac" related question: bootcamp (Mac) should impose no restrictions here on USB joysticks. Uhm... as others have already mentioned: "It is highly unlikely that you get any satisfactory performance" with an integrated Intel Iris GPU. I mean, you might get FS2020 to actually run, but the limited amount of VRAM ("video ram", as opposed to your "normal" RAM) itself may already be a showstopper. For reference: I have a pretty maxed out iMac 27" with an Intel i7 4.2 GHz, 32 GB RAM and an AMD Radeon Pro 580 with 8 GB VRAM (that is, the "maximum GPU option" for that system at the time!), and I can play FS2020 with "full HD" (1920 x 1080 resolution) with "High" settings (with some settings set to "Ultra", while other settings lowered). I have never really done any real "frames per second" (FPS) benchmarks, but subjectively I'd say I get around 20 FPS under "normal conditions". "Photogrammetry heavy" landmarks such as London however put my system on its knees and are barely playable with those "High" settings. Now you do the math where that puts your Intel Iris performance 😉 Again, if you put everything to "low" (including your expectations ;)) it might actually be fun to play - best bet is to try it with "one month of the XBox gaming pass", which costs around 5-10 EUR a month, or so I understand...
  10. Yes, so I have noticed 🙂 I'll first go through existing posts and "get the general feel" for this forum, and then I try to contribute with answers as much as possible - and maybe occasionaly also a question of my own of two 😉 See you in the skies!
  11. Hello community, My nickname is Steeler - a name chosen at a time when I wasn‘t even sure whether that was a proper English word or name. So yes, that puts us back into the „golden time of PC flight sims“, or actually even before that! My first „serious“ flight simulator was probably (memory is a bit foggy here) Microprose Gunship on the C64, but I faintly remember having played Flight Simulator II. Other „big names“ - all fondly remebered - and a new Amiga computer followed: Interceptor, Falcon, Flight Simulator IV, Their Finest Hour, Chuck Yeager‘s Advanced Flight Trainer… gosh, how I remember when AFT was supposed to be released and I walked from computer store to computer store, until I actually found a copy in a tiny game store! And I couldn‘t actually play it for another couple of days, as I was on christmas holidays or so with my grandmom - that is, „away from computer“! Oh and I fondly remember the first „online“ battles with Falcon 3.0 when friends and I connected your computers (still Amigas, IIRC, but later PCs for sure) with a „null modem cable“. In the mid 90ies I basically stopped playing computer games almost completely, so it wasn‘t until FS2020 came along that I made a „return“ to flight simulators. Well, „return“ is probably a little too big as a word: I simply enjoy the beautiful graphics and especially the gorgeous cloud rendering! That‘s what we have been dreaming of as kids! As such I don‘t mind too much low(er) framerates or the occasional stutters, or that the stock aircrafts do not behave 100% „like the real world“ (I couldn‘t tell the difference myself anyway). But they all have a distinct flight model, and they make me feel as if they were „the real thing“. That‘s all really I personally expect from a PC flight simulator. Oh, and I am so enthusiastic that I developed my own flight replay tool (open source) and I am now the proud owner of a HOTAS stick and throttle 😉
  • Create New...