Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by tkyler

  1. I've added commands for those transponder buttons, as well as a few others. We're getting close to releasing the next update and these commands will be included. -tk
  2. My bad, I accidentally pushed that update log to the web prematurely. Its not out yet...but most of those are done. I'll pull that so as not to cause more confusion. I also implemented CaptainCrash's performance enhancements which was a very big job and that is also done. I'm down to final testing and reworking the GUI before deployement. Tom
  3. You cannot reach that ZFW value (in lbs) with the Preflight menu. We made a reasonable assumption of how much a plane is likely to be maximally overloaded based on Jan's career flying it and allowed that value...beyond which we didn't expect anybody to try. If you max out all the passengers and cargo bays to their limits and set the wt factor to 1.5 (to simulate a plane full of 200+ lbs people) then you'll end up with max ZFW just shy of 126,000 lbs. We made assumptions also about "nominal cargo density"...in other words, we assumed folks wouldn't simulate a cargo hold full of lead. Full fuel with max ZFW via the preflight menu that gets you to 161k, 25,500 over MTOW, which we thought should satisfy users wanting to try some overweight flying.....for at least 99.9% of use cases. Now You CAN achieve that ZFW value through the regular X-Plane weight sliders....BUT....with a caveat. We custom set the weights whenever the preflight menu becomes visible. SO...you can set total payload weight to approximately 70800 lbs (you probably won't be able to achieve 143511 ZFW exactly because of X-plane's slider resolution)....but once done and you "Apply changes", then do NOT open our preflight menu after that...as the total weights will be reset based on where the sliders were last set. This will allow you to simulate your overweight flight....but I suspect you may really have a challenging time with your climb rate and takeoff speeds. I think a ZFW of 143,000+ lbs....were some official to find out that you actually loaded the 733 that heavy...might have a thing or two to say about that...as well as any license or certifications or job security you might possess Now if you were to say, "this is annoying, I like to fly 20,000lbs overweight on all of my flights....then we can up the wt multiplier for a future release, I'll admit, you're the first one to ever ask to achieve a weight this heavy to my knowledge. -tk
  4. Same here, and IMO, mostly for the reasons I mentioned above. In the business sense, they absolutely are. I believe the flight sim market to be big enough and each player to be competitive enough for end-consumers to reap the benefits and ergo, I see the competition between MSFS/Laminar healthy as is. Now the "intra-X-Plane" competition for distributing 3rd party works spawned by Laminar's entry into the store space ....then that is a different discussion regarding the benefits of competition, one I'm not interested in participating in textual form...its just too big of a discussion. If one competitor is so big and formidable as to render the others non-competitive, then there could be undesired collateral consequences. I think the XP community is aware of this and relevant players are working to limit such collateral damage. -tk
  5. Given that assumption, sure, your points would absolutely be valid points of thought. I don't want to use the word "concern", because that's relative to each person. I'm not bent on putting my wares on the Laminar store for several reasons I won't go into here, but suffice to say there's many considerations and factors with regards to product type, quality, market, deployment / support that go into distribution decisions beyond the simple exposure of a convenient insim "store page" that users will see. So while on the one hand, I can see the benefit of our products "easily waved in front of the faces of customers previously unawares of our wares"....on the other hand, and given the types of products I like to produce and my own experiences over the years, I can also forsee a very large range of potential pitfalls that Laminar is less equipped to handle over the long-term...and not completely sure they should try to do so. If I was magically put in charge of "product support" for Laminar's, I would put forth an argument that supporting products over a certain level of complexity could be cost prohibitive and resource draining. Its my opinion that the special needs/support of high-fidelity, "study level" aircraft developers and the customers who seek those out is a niche space in the sim world and better suited to a bespoke distribution and support system like XA and given our experience, do not see this changing in the near term. -tk
  6. Labels are relative to our own points of view, both views can be construed to be accurate depending on the argument at hand. Near where I live, we have two coffee shops within 1/2 kilometer from each other and indeed two starbucks within a kilometer of each other. From the perspective of "starbucks corporate", those two stores don't compete...but ask the managers of each of those stores if they're competing with each other for 'performance bonuses' and from their perspectives they are competing. Regarding the two coffee shops NOT the same company, each has some 'value point' niche they cater to (i.e. the "space") which allows their business to attract customers and be profitable, because the size of the market supports it, BUT, they each do need that 'niche hook', whether it be location, a "convenient driveway" or just plain better coffee. I'll point out that "loyalty" can be a hook too. So while MS / Laminar spaces obviously overlap, it can definitely be argued that there are portions of those spaces of 'the simulation experience' that do not overlap and each excels in differing areas where those markets are big enough to support both. XA has some hooks that I don't think Laminar can effectively cover in a cost effective manner, nor handle the logistics of supporting products of a certain fidelity level as they tend to be 'high maintenance'. In the space XA occupies and we don't see much changing and expect to continue providing high-fidelity products. -tk
  7. I can't help the dissapointed. There is a quite well known phrase, "Disappointment is the difference between expectations and reality". We have tried to be as forthcoming as possible with setting expectations by telling folks it will take the majority of this year getting converted to FMOD and improving the FMS....but beyond that, there are also very big changes necessary 'under the hood'....big and time-consuming. Folks think that its always 'evolution'....just incremental work, but with tech, eventually the patches get too heavy. There is a very major overhaul of the "black box" bits to ensure future compatibility and the IXEG's continued existence....a rewriting of nearly 70,000 lines of code in a new language (that took 3 years to write originally) , stuff you won't see but I have to do to keep the IXEG compatible for the future. Guess what...its going to be silent for even longer while I work on the FMOD and code refactoring / FMS. Settle in...enjoy some other wonderful products for X-Plane, but know that it is not abandonware....and we won't be charging for updates for years to come probably. -tk
  8. I know how you feel Mike....I felt a similar sting reading your comments on Toto's Discord a while back, insinuting a simple swap from your work to mine would "make eveything OK" and I was just too lazy to do it....and clearly my defensive posture resulted in a harsh turn of phrase above..which doesn't make it right. At the end of the day though, we get the customer support emails (a much larger contingent than is present on forums) and as such, I have a broader perspective of my customer base ...and enough experience in this market to know that your changes would result in making several customers happier, but also several more disappointed and I have to answer to those folks. I'm sorry if it stung a bit. What we're dealing with here is a "philosophy of development" given known limitations in 'modeling methodology'. For a good while I've watched us aircraft devs "put in the numbers" and complain to Austin when things don't perform right. But at the end of the day, these are just a big collection of numerical models and approximations, some better than others depending on lots of factors. So as aircraft devs with 'approximate models' in many places, we've always had to determine "which numbers to prioritize" given the state of X-Plane's flight/systems models. If, for example, you prioritize "accurate blade angles and engine parameters per handbooks" but the plane's performance is off in some regime because X-Plane's 'black box models' are off or too generic in places ....then you have to ask yourself, "can a user see the blade twist angles of the flight model? ..... or can a user more easily see the "off-nominal performance" and you make your decision about what to prioritize and compromise. If I said, "I'm putting in all the accurate numbers and will wait for X-Plane to 'come to me' and perform correctly before I release the product....well..you can imagine how that will go, so my philosophy is different. Numerical compromises and fudges are required for more balanced performance across the envelope in my experience. Indeed you have put in a crazy amount of accurate info into Plane-maker, and I do appreciate your work and it won't go to waste. It is not a simple swap and deploy because as you've noted, the X-Plane models aren't perfect so some numbers will have to change to accomodate the ground regime; however, your work is a wonderful springboard that I do respect and will simply have to look at parameter by parameter and gauge the effect against their impacts in a broader range of regimes. I hope I can strike a balance that satisfies enough. -tkyler
  9. in progress. I have the FMOD project file going and some sounds ported over, but there's about 140 of them in total I think....and I'm having to audit each one....look at the code, reverse engineer the "equations" ...with multiple parameters and get those to graphical form, then fashion those up in FMOD.....super tedious work, and sorry for the time, but this will free us up for compatibility for many years to come and was an inevitable overhaul. I for one will be super happy when done so I can get on to the FMS stuffs.
  10. none to speak of. I did spend some time trying out Captain Crashes "fixes"; however, I found out that he only tested in "cruise conditions" to "match numbers", because he had charts with numbers......but in doing so.....using his new prop / engine settings, the plane is completely inaccurate for ground ops, with insufficient thrust for taxi without going well into the alpha region. When I asked him about this he said, "no, I didn't test on the ground"....DOH... This is why I'm generally roll my eyes at community members with "fixes"....their perspective is usually very one dimensional, only regarding whatever it is they are passionate about. but the whole of the system is very inter-dependent. I'm keeping part of his work, and dismissing other parts..and its a parameter by parameter evaluation. So sorry..no news yet, but certainly the work is still in my inbox. TK
  11. shouldn't be too long, within a couple of weeks. Mom's health, holiday time and a much-needed vacation have been a distraction for a good bit...just one more event to get past this weekend and then I'll be back on things regularly. -tkyler
  12. TBH, we can't fully blame them (I'm one of them with the MU2) ....we've been 'crossing our fingers' for a while that XP12 doesn't break our radar display....and the spectre of such still exists. Its like two people walking towards each other and that awkard moment where neither is sure which way the other one will move and you kind of stutter-step....a lot of devs and Laminar are doing that right now IMO. We've gotten lucky in a way that we haven't had to do a darn thing to 'get around' the new weather system..we happen to select a method that has held up thus far..but it is based on the previous weather system pardigm....and as such, we are always 'looking over our shoulder' at it so to say, in case is sneaks up on us one day All that said...I do think the time is coming where it needs to be addressed. There is a XPlane developer conference in February and I suspect this will get discussed. -tk
  13. Maybe...if you have hardware connected (not necessarily assigned) but also want to be able to use the mouse, then the pref "Manips with Hardware" should be checked.
  14. I'll assume you're on mac? Its a known issue..and yea, tough to nail down. Always on the lookout for clues on this one. -tk
  15. no, the tank types need to be changed in PM. I've done this for the next patch. There is no "fix" coming from Laminar. If you open up one ACF in Planemaker and set tanks 1, 2, 4 and 5 to type "TRIM", then it might work. I say MIGHT because Laminar confirmed that Austin defaulted the fuel tank draw to be "side based" in the first beta 12.08b....instead of 'ALL' and I haven't tested whether or not the latest update b3 fixes that. Tank type TRIM has no fuel transfer algorithm associated with it, hence my plugin handles it. Any other tank type and X-Plane moves the fuel around per its own algorithms, which is probably what you're seeing. For myself, I simply initialize that dataref now to what I need...TBH, I didn't expect Austin to change that one. SO...if they did initialize the fuel tank selector to 'all' in the latest BETA....AND you set the aforementioned fuel tanks to TRIM, then it should work as it did previously. I've done this already for the next patch. Regarding the fuel flow and torque? Doubtful. A performance 'pass' needs to be done again. I haven't touched it in a long enough time and X-Plane has had quite a bit of tweaks since. I've started on that process...but flight testing takes quite a long time. ...the perf charts have performance figures for something like 10 differing temperatures and different altitudes and torque settings....when all permutations are considered, it could add up to multiple dozens if not 100+ test flights......and still you're at the mercy of the X-Plane model. BUT yea..the perf needs some work. -tk
  16. Yea, sorry about that, I had a senior moment....those files were for the MU2, not IXEG. I happen to be in FMOD at the time and simply forgot which project file I had open... I don't think MU2 files would do you any good here tk
  17. Got this on our list and will definitely take a look. -tk
  18. ah..looks like its an FMOD soundpak....so that is interesting. I will note that I used FMOD 1.1 for the Moo...and Laminar has been using 2.0 for some time. I'm beginning sound work for the IXEG and will see about exporting the Moo sounds to FMOD 2.0 for the next patch...it SHOU......that should be the starting point for any debugging at the minimum...I need to get on the latest and greatest that Laminar uses. -tk
  19. Hi Raoul. this is known and indeed fixed for the next patch. I've been caught up with the IXEG, but have turned my attention to the Moo....so hopefully get a patch out soon that includes this fix. Thx. TomK
  20. @rosseloh Thx for that report. After quite a bit of investigating...it may be X-Plane didn't 'break' anything. As the sim evolves, Laminar puts in more detailed models and for older aircraft where those details didn't exist, then Laminar has to toss in some default values. In some cases, those default values provide behavior counter to the way things used to be...so while it seems X-Plane BROKE something...they really didn't I think that's the case here. X-Plane has refined their fuel transfer and 'tank types' a little ways back, but since I wasn't affected, I never bothered to look at their new system and try and leverage it...I just let my old 14 year old fuel transfer code stick around. I think they might have "tightened up" some code, which closed holes in their own code. I've been able to manually set up a fuel tank / dataref config that seems to work, but need to tie it into the cockpit controls. If it works in 12.08, the that will be a good thing and I'll move focus to the Moo for a bit and get out the next round of patches. TK
  21. Just an update on the fuel transfer....there has definitely been some "wonkiness" in the latest update with regards to fuel transfers. The report is in their system so we'll see. Whether or not a fix "comes up short" or exposes other issues we won't know till it comes out. One of the things we see with X-Plane is "new systems paradigms" coming online as XP evolves....and the fuel tanks / transfer sequence is one of these things that have evolved when Austin worked on the F4 model. So in some cases, it may or may not be a 'bug' per se....but an 'evolution' that requires us 3rd party devs to reconfigure our ACF files. The MU2, for example, doesn't yet integrate the new "weight stations" and so this can cause some funny business in some cases and isn't really a bug, but my needing to research XPs latest features and make sure the MU2 integrates them properly. So we'll see what comes of this fuel thing....but at the least I have some input with Laminar. -tk
  22. Hi all, with the upgrade transition finished, I thought I'd report on whats planned to help set expectations for the future and into 2024. A high priority is weening off of technologies that may cause "show-stoppers" for customers or in danger of causing conflicts as XPlane and computers evolve. This means the transition to the FMOD sound engine is first up...as we've seen some issues for customers and is a sign that things aren't going to get better. This is a pretty good sized job as we have quite a few sounds we have to port and we also have a LOT of code we have to excise without breaking other things. A port to FMOD easily sets the stage for many more years of compatibility. We don't work completely linearly...so in interstitial gaps in time between FMOD work, we'll also begin integrating in the XP11 Navdata format. Users won't see this for some time as its a big under the hood change. This is necessary not only to improve the IXEG FMS, but is also necessary for two future products with FMSs and as with FMOD...ensures forward compatibility...so this move to the XP default is also quite important. Third, we'll also begin work on the FMS VNAV / holds / performance predicitions. This work depends on the XP11 navadata to some degree, but not competely so we'll be able to make strides in this department while working on the XP11 navdata format transition also. Also, we're refactoring (rewriting) an enormouse amount of code for future-proofing and developing a new graphics library along the lines of what the RSG and TorqueSim folks are using. This will open the door to more engaging graphics for GUIs and value-added interfaces such as failures and EFBs etc. and Finally, we'll work on a new, high-resolution exterior model with new paint kit. We expect this work to take most of 2024....but it very much has applicability in the other projects we're doing so the end of the road isn't just some "under the hood" stuff on the IXEG, but also new models. Thank you for your support, we'll continue to keep working. -Tom Kyler
  23. It was? That's pretty incredible because the 737 Classic doesn't have an altitude ladder display. ..never did. Check out Jan's old videos ...looks exactly like your screenshot.
  24. you have winglets option on? There are no logo lights with the winglet option. Logo lights work fine for me with "no winglets" -tk
  • Create New...