Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/07/2020 in all areas

  1. 15 points
    Ok..another week gone by. 60 more hours of rewrite on the FMS route editing and guess what, we're still easily 95% of the way done Seriously, we are into the more hardcore route editing features now, the really fringe type of data entry patterns...changing your mind "mid transition" selection for example, or selecting a STAR, then approach, going to other pages, then coming back to select another STAR, then TRANS, then swap to a runway with an extension, then shortcut points, etc. Testing earlier in the week had us redesign some other algorithms and we figured we should just power through the work now so it gets done right and we can move on to VNAV without worrying about fragile route editing. With the algorithm structure in place, what remains is simply comprehensive testing/debugging of those algorithms via diverse route entry patterns until the route builds as expected in all cases, for both Navigraph and Aersoft datasets. As soon as that happens, we'll get the patch out. We're working on it daily. -tkyler
  2. 13 points
    Another weekly update. The rather rigorous testing of route editing over the last week had brough forth a few more issues, not unexpected during such a substantial rewrite though... but without a doubt, there are substantially less issues with route editing. Jan's last round of route testing, he was unable to get a gizmo crash when changing procedures aggressively and could swap any procedure at any time. Our goal here is for folks to not be scared of to push any buttons on the procedures page during descent / approach for fear of a gizmo crash, and be confident they'll get the route they expect. So, for example, you can select a STAR and transition.....and fly that without knowing your arrival... and then select your arrival later and it'll just get "added" to your routing. I know I say this every time, we have not begun the VNAV rewrite though....so we can't say how the VNAV predictions will turn out just yet. We have a very small list of issues to wrap up, which I will be trying to tend to this weekend so we can get this patch out asap. After, I will examine the waypoint restrictions and then finally analyze the VNAV and set upon improving that feature. -tkyler
  3. 13 points
    Hello all. What started out as a 'quick bug fix" for our annoying gizmo '470' error has, over the last 80 hours in one week..... turned into a very significant rewrite of our route procedures editing code. I was hoping to have it done by this weekend, but we are not quite ready. We are easily 95% of the way though and will continue to push to get this rather significant FMS update out asap. Depending on the routes you enter, some may not notice much difference, but for others, the difference will be quite noticable with the "routes editing as expected". Of course there is no way we can try all the routes that all the user can. In one 14 hour day, I may enter 100 test routes, all at the same airport, so feedback after release will be much welcome. We have refactored our editing code to be much more maintainable and 'debuggable'. That being said, we are pushing the CDU entries pretty hard at lots of locations and will continue to do so right up until release. I MUST re-iterate...this is LNAV editing code, not the VNAV. VNAV calculations are built upon the LNAV route and so this is a major foundational step towards improving the VNAV. I suspect many routes will improve though with this update. After this route editing effort is stabilized, I will go over the waypoint restrictions and then the VNAV. Holds will come after. -tkyler
  4. 9 points
    This is a lengthy post, explaining our VNAV situation, or at the least, how we arrived where we are today, and where we're going from here. This is a tale of how being too ambitious and trying to be all things to all people bit us and our customers. In the beginning was nav data in XML format....whether other formats were avail in the beginning, I don't know, I only know this was my beginning because I inherited the FMS work and this was the dataset that landed on my plate. It was from Navigraph. The first thing I did when I started was to open up a few XML files to get the lay of the land. I noted several differing "types" of data like so: and decided I needed to know every single type in the dataset so I could design algorithms around it. So I wrote a program to go through all the files and log each unique occurence of a data type, i.e. "Star" "Sid". "Sid_Transition", "Approach", etc. After I had that list (because I couldn't find any spec), I set about programming the FMS....for a few years. All was pretty well. THEN....somewhere towards the end, we loaded up the same XML format dataset...but this time by Aerosoft, thinking "hey, lets support both providers, since there are plenty users of each". ...and for a while things were good; however, we started seeing some issues related to the fact that Aerosoft had additional XML types that Navigraph didn't have...and for which I didn't have code to handle. So I started throwing up 'band-aids' to get the Aerosoft dataset integrated....which would lead to some anomalies for Navigraph users...OK...a few more band-aids ought to do it. And this went back and forth until I had all 10 fingers plugging up holes in the dike. But turns out I needed a few more fingers....OR a more robust dike (hint...that's where this is going). Over time, we'd see bug reports for navigraph users that aerosoft users weren't seeing and vice-versa. Without exception though, the most obvious problem spot was in "decent FMS entries", i.e. STARS, Star transitions, etc. Entering these procedures were frought with all sorts of bugs and gizmo crashes. For online users who frequently enter these procedures in the air, as they approach their destinations, this simply was a deal killer. So...fast forward to today when I'm revisiting the FMS code from a much higher level and seeing that these band-aids just didn't cover the wounds well enough. So..case in point. Here is how Aerosoft and Navigraph each represent STARs with runway transitions, specifically KBOS. Aerosoft uses a data type "RwyTransition" to denote a runway transition waypoint, whereas Navigraph does not. This is where things went south originally when we tried to support Aerosoft users late in our development process. Now when a user enteres a STAR, and no arrival runway has been selected, then you'd expect to load those waypoints in the STAR that are not unique to runways, i.e. "common points". If you're using NAVIGRAPH, you will note that each XML "block" is associated with a runway. So if no runway is selected, we have no way of knowing which block of code to load for navigraph users. If you're using Aerosoft, then I can load the STAR waypoints only (and not the transition waypoints)....except all my code was written for the navigraph formats....and trying to make this work "last second" ended up causing more code confusion and debugging difficult. If I had a bigger picture of all these types from day 1, I would have written better structured algorithms. The good news, is I can see it better now and CAN write better structures; however, better than both these XML formats is the XP1100 dataset that we plan to migrate to in the future. But there is still more good news. Looking at the code with clearer eyes and hindsight, I can see a few trouble spots that I can fix that should make this whole VNAV decent business improve significantly. Indeed one or two poor lines of code can bring down the house and does for a few instantces of entering STARS / Transitions. We are going to add a new message to the CDU, which is NOT realistic, but required in our opinion to avoid confusion. If you select a STAR that is associated with a runway, or has runway transitions, we will display a message "RWY SELECTION REQD". While Aerosoft has the necessary common points separated so as to load those without a runway selection, recall my code was not orginally written for it, and so for the moment, I am not going to create a fork to handle it just yet. Knowing we are switching to XP1100 navdata format, I'll have to gauge the effort of accomodating Aerosoft's transition points differently than the Navigraph data vs the effort of just focusing on the XP1100 integration. It could be, that accomodating Aerosoft's transition points is not so difficult...and in this case, a user could select a STAR and STAR transition without having an approach selected; however, Navigraph folks, we simply need to know the arrival runway before we can load up these "runway transition" STAR types. For STARS that are NOT associated with a specific runway, but serve all runways, this arrival runway selection is NOT required before STAR selection. Many times users don't notice that the STAR they are selecting are unique to a runway (and subject to the case described here) and so in the course of their simming would see inconsistent behavior with STAR selection as they flew differing flights around the globe. This "RWY SELECTION REQD" message will let them know. And finally....my code handling STAR transitions for these "runway transition" STARS was completely borked (by a poor band-aid), messing up the waypoint table and rendering any VNAV calcualtions / representation completely useless. This is why some folks see good VNAV behavior and others do not. It is dependent on which route your are flying, which STAR type you select and whether or not you selected a transition. I believe this CDU message will fix a lot in the interim, but ultimately the swap to XP1100 nav data format, with its consistency and basis in ARINC 429, will be our final and most durable solution. Aside from the issue described here, the other glaring issue is the waypoint altitude restrictions. We will be attacking those soon enough and with clearer eyes, I expect to get this cleaned up also. -TomK
  5. 9 points
    so the 1.31 update has gone out, with the objective being to stabilize our "get back to where we left off with the new toolchain, but conformant to XPlane 11.5" update. Assuming we don't have really big show-stoppers, it is now time to start moving foward rather than just get stable. We have a few things we'll be working on simultaneosly from this point on. With an eye on X-Plane 12, we'll be working on swapping our sounds to the FMOD sound engine. This is a compatibility move, moreso than changing the way our sounds are played because we quite like our sounds. In addition, we'll be working on incorporating particle effects in spots. On the 3D front, the 3D changes will begin with the galleys, cabin and cabin doors and after that wing flex. On the FMS side, first up will be the remaining user-created waypoints, (PB/PB, ATD, LL), then probably VNAV work, including PROGRESS page predictions.. A better VNAV algorithm will make programming holds a bit more predictable and so HOLDS will be after our VNAV work. Once all that is working reasonably well, then we'll look at porting our navdata over to the XP1100 navdata format....which will probably be after the XP12 release and be a pretty heavy FMS rewrite. Thanks for the support and patience, its time to starting improving things again. -TomK
  6. 5 points
    Let's start here: If one thing is for certain, TorqueSim does not sit back and relax after releases.
  7. 4 points
    Upvoted, thanks for being this open about the roadmap. Other developers tend to be secretive sometimes, or respond badly to feedback from the customer base. Nice to see a difference
  8. 4 points
    It's ironic that a few of you are wanting it back. I was getting quite a few DM's on Facebook, and I think a few here, also, asking for it to be lessened or removed. That it was too hard to land and take off. I'll discuss with Saso and ask him if it can be made as an option or just to bring it back as before.
  9. 4 points
    Found the issue with the Localizers. X-Plane 11.50b10 changed one element of the localizer nav data encoding (bearing), which broke the custom localizer simulation code in the TBM. Compatibility workaround will be included in the next TBM update.
  10. 4 points
    Hi Torbinator, I have seen the same (and stranger!) things with VNAV in descent. But I am pleased to report that Tom has implemented some coding changes related to STARs and it´s transitions (as posted above) that also seem to have a very positive effect on VNAV. I have done a few flights with VNAV descents, and I still see some quirky behaviour (mostly not adhering to the first of multiple AT restrictions), but overall the VNAV has become more predictable and more reliable and I am sure we can build on that and improve it further. I am curious what you guys will report when flying the next (1.32) patch. Cheers, Jan
  11. 3 points
    You need to know some new concepts. -True heading (212 shown by the IRS display). This is the TRUE heading the aircraft is following in relation to earth's geographical north (not the magnetic north) the difference between true vs magnetic varies across the globe, you may see isogonic lines/charts -ND heading (244). The NAV display shows the heading the aircraft's nose is pointing in order to maintain the desired magnetic course 236. Since you have a VERY STRONG crosswind coming from the right, AP is pointing the aircraft's nose to 244 in order to compensate those strong winds trying to drift the aircraft out of desired 236 track. if no crosswind components were present ND heading and planned magnetic course should match. -Magnetic course. This is the magnetic course the aircraft should follow as per the flight plan. hope this helps
  12. 3 points
    Just want to say this update together with X-Plane 11.50b12 is super stable for me. Already completed several long flight legs with 0 issues contrary to beta 11. Using SMP latest, RWC, ASXP and alot of heavy scenery. So thank you for the constant updates and support.
  13. 3 points
    Jan is right, we have not touched the AP or VNAV code at all since 1.21, so if something is worse, we need to know exactly what it is that "makes it worse". Debugging is quite tough business, not so much the fix, but the amount of diligence it takes to quantify what the issue is and put it into words. Good VNAV starts with good routes to make calculations from, and that is where we currently are as of this instant, fixing the STAR / APP route building code as these procedures are selected...since they are clearly resulting in 'funny routes' where VNAV calculations make no sense. That '470' bug is a pain for all of us and I'm super sorry about that one, but its fixed for the upcoming update and we are also now trying as many route editing combinations as we reasonbly can to test the robustness of entries. We will have an update in relatively short order with several fixes for sure and I for one, will be interested in seeing how the FMS handles "in air edits on descent" for all the situations folks will try that we did not get to. VNAV complaints are heavily biased toward the descent calcs and revisiting my code, its not hard to see why....which is a good thing...as it paints a clearer path for repairing the code. We are now working on FMS code and VNAV with priority, so any patience / feedback as these updates come out will be appreciated and help us improve. Bug reports regarding VNAV after this next update will be quite valuable as we are focused on that work at this time. -tkyler
  14. 3 points
    This will serve as a formal forum announcement that we have released the version 1.1.0 update for the BN-2 Islander. All customers who have purchased the BN-2 Islander up till now have been sent an e-mail by X-Aviation with complete instructions on how to obtain your update. We have made this a very simple process! For those that purchase the BN-2 Islander from today forward, your purchased download will already be updated to version 1.1.0 for you. This update is a massive revamp of the 3D, textures, sounds, and systems on the Islander! We have integrated customer feedback to perfect the Islander, providing the most realistic X-Plane 11 Islander experience. What if I didn't get the update e-mail? If you did not receive your update e-mail don't fret! X-Aviation has updated our system to allow all customers to update with ease, regardless of whether you received an e-mail for the update! Here's what to do: 1. Login to your X-Aviation account here: https://www.x-aviation.com/catalog/account_history.php 2. Find your original BN-2 Islander download and re-download the file. It will download as the latest version! The following is a list of additions/fixes included: Improvements / New Features: RealityXP GTN 750/GTN 650 Integration Revamped FMOD Sound Pack New engine/prop noises Revamped switch and internal noise Custom “headset” simulation with adjustable noise cancellation [IS-351] - Panel Shake/Vibrations [IS-309] - Mechanical Hobbs meter/tacho in 3D [IS-346] - Placard with flaps speeds [IS-332] - Add ability to open plugin menu from plugins bar at top instead of only side tab [IS-295] - Avitab integration Bug Fixes: [IS-241] - Carb Temperature Gauge animation jumping [IS-264] - Gyro CW/CCW switch motor should play until switch is released [IS-265] - Gyro Slave/Free switch has no sound for 'slave' [IS-282] - Landing light fix [IS-285] - Radio channel selector lights fix [IS-286] - Bose A20 Headset improvements [IS-312] - [AFM-114] VOR and HSI behavior [IS-320] - VOR 2 Glideslope reversed [IS-326] - Mags / Door Interlock [IS-327] - BN-2 VR bugs [IS-329] - Stall alarm not audible when the headset is worn [IS-333] - KFC225 ARM and VS buttons correct order [IS-342] - Exterior lights issues [IS-345] - Autopilot working with avionics off [IS-347] - HDG / NAV flags reversed on HSI [IS-352] - o-540-e4c5.obj reduction [IS-353] - furnishings_2.obj reduction [IS-321] - Brake Lines missing proper normal data [IS-331] - Create .snd file changes for new manipulators [IS-343] - Change annunciator brightness to run from 0-1 rather than 0-2 [IS-350] - Add utility light power commands [IS-354] - animated prop governor control arm [IS-361] - Smoothed datarefs for the sunshades on the overhead panel [IS-291] - Add cockpit utility light (moveable) [IS-294] - Update manual with cruise data, fuel flows, etc [IS-306] - Add brightness switch and test button to annunciator panel [IS-322] - Set flight model CHT min/max [IS-323] - Change cowl flap lock [IS-337] - Add persist to Ammeter knob [IS-338] - Hide-able interior glass to remove reflections [IS-357] - Update GUI [IS-289] - Make custom audio panel datarefs [IS-299] - Optimize 3d vertex counts [IS-300] - Optimize textures [IS-315] - Cabin light can turn on without battery power [IS-316] - Pax notices can turn on without battery power [IS-319] - Utility lights [IS-334] - Add Door Interlock Sound [IS-349] - Make avitab datarefs persist [IS-358] - Switch wording for glass reflections As always, thanks for being a customer with X-Aviation. We appreciate your feedback and support! Enjoy these latest updates, and stay tuned to the forum as we continually announce the latest happenings.
  15. 3 points
    This is really looking good. Great fps, accurate weather and better clouds. Just thought I would share...
  16. 3 points
    When using the nosewheel there is an effect that is similar to a "stall" of a wing. The wheel will put out force corresponding to it´s "slippage" - until you pass the critical angle and it starts "gliding". This effect is real - try driving a car on ice or snow and see how gentle movements of the wheel help in keeping in control - once the car starts sliding, it is very hard to get it back under control. The problem in X-Plane is that the force put out by the wheel under a certain "slippage angle" is way too low. So people tend to naturally increase the steering angle to compensate, entering the range of free gliding (stall) where the actual angle becomes irrevalent. Try to use small movements, like jaguado points out. Try to steer smoothly and deliberately and control your speed to be less than 10kts in turns. I will keep pushing Laminar to make this more realistic. Cheers, Jan
  17. 3 points
    Just did a quick flight on 1.3.1 on 11.5.10 beta. Very very nice and all the controls I used were working nicely. Thank you so much for the entire team. What a good job you have achieved. Highly recommend!
  18. 3 points
  19. 2 points
    Alex Nail it. I reinstalled with the beta gizmo and all is working great. Thanks Alex
  20. 2 points
    Hello All, This will serve as a formal forum announcement that we have released the version 1.31 update for the Take Command! IXEG 737 Classic. All customers who have purchased the IXEG 737 Classic up till now have been sent an e-mail by X-Aviation with complete instructions on how to obtain your update. We have made this a very simple process! For those that purchase the IXEG 737 Classic from today forward, your purchased download will already be updated to version 1.31 for you. It is for X-Plane 11. If you use X-Plane 10, you can still install an old version of the aircraft from the installer, but this update does not otherwise apply to you. Caution: This update is optimized for XP11.41 and newer only! If you run it any previous X-Plane version it will still work, but the aerodynamic model gets changed and will not fly "by the numbers" anymore! Install at your own risk (make a backup of the aircraft folder first, especially if you run XP10)! What if I didn't get the update e-mail? If you did not receive your update e-mail don't fret! X-Aviation has updated our system to allow all customers to update with ease, regardless of whether you received an e-mail for the update! Here's what to do: 1. Login to your X-Aviation account here: https://www.x-aviation.com/catalog/account_history.php 2. Find your original IXEG 737 Classic download and re-download the file. It will download as the latest version! The following is a list of additions/fixes included: Bug fixes: Fixed mousewheel scroll direction for all manipulators Various Gizmo Beta Changes/Fixes Fixed first digit of engine #2 manual N1 setting indicator to bleed over to engine #1 Removed "C x 100" labeling from Fuel Flow gauges Fixed two screws missing (CPTs EHSI frame and overhead panel) Stopped stickshaker assembly from clipping into footrest cover Re-enabled BetterPushback to work with this plane Enabled autothrust to set correct N1 at high-altitude airports for takeoff Fixed texture see-through bug with leather flaps on side of instrument panels Re-enabled lit texture for writing on mode control panel Hooked up right-side N2 and FF carots of electronic instrument version to correct engine again Fixed movement direction for rudder pedals DC meter selector on BAT will now show battery voltage even if BAT switch is off Improvements: Tweaked "fur" texture of pilots seats to avoid "see through" effect near edges Removed further "texture bleed" cases of bad UV mapping (APU fire control box in wheel well) Changed and improvement manipulators for flap and speedbrake handles (more intuitve to use, hits detents better) Tweaked APU fuel use logic (draws from left side fuel manifold when running, according to fuel system setup and pressures) Increased EDG oil temperatures a bit to avoid needle being pegged at left edge of gauge Several improvements to initialization setting of switches and rheostats (lights, TCAS/Transponder, DH, Radar system, etc...) Changed clickspots for sunvisors in eyebrow windows to the actual lanyards Allow use of "ground services" menu while in motion or even in flight for fuel, weight and CG adjustment Various minor texturing/UV tweaks Total makeover of many manipulators in the cockpit for optimal mouse and VR use. Additions: Added option to remove "ghost throttle" symbology Added option to have a mouse manipulator to move both thrust levers simultaneously (for VR or mouse fliers). Added option to use two separate hardware axis for throttles (no locking lever at idle). Added VRconfig.txt for optimal VR compatibility User created PBD (Place / Bearing / Distance) waypoints implemented on LEGS and RTE page As always, thanks for being a customer with X-Aviation. We appreciate your feedback and support! Enjoy these latest updates, and stay tuned to the forum as we continually announce the latest happenings.
  21. 2 points
    Hi, it looks like you have some button or axis assigned to your pitch trim. We are using the default X-Plane trim commands, so you should be able to see/cure this by using the controller setup interface in X-Plane. Another possibility is that you have fly-with-lua or XPUIPC installed and have mapped some function to the "trim nose down" command. PS: (We don´t have MCAS, so thats not it! ) Cheers, Jan
  22. 2 points
    With the power of newest Graphical User Interface (GUI) available on X-Plane, we build what we believe is a clear, simple, easy to use, but also informative way for loading the aircraft. LOADING PAGE LAYOUT The loading page is divided in 2 columns. On the left column is the area of ‘actions’, where you do the loading. On the right column is the area of ‘information’, with a Center of Gravity chart (CG) on the top, displaying the Gross Weight (GW) and Zero Fuel Weight (ZFW). On the bottom is a numerical representation of each weight category, in both kilograms and pounds. PASSENGERS LOADING The passengers section is divided in 3 compartments, B, C, and D. Using the sliders in the top of the seat map, you can adjust the number of passenger, per compartment, as you want. The seat map will display the seat coverage, as you adjust the passenger. Always pay attention to the CG chart! You are the responsible to proper load the aircraft! CARGO LOADING The cargo loading also happens in 3 compartments, 2 in front of the passengers area, and 1 aft. For clarity, the seat are not drawn here. Keep in mind that the aft cargo area (compartment 3) is way back of aircraft’s CG, so adding a lot of cargo there, will move the CG far aft! Load with caution! FUEL LOADING Last (but not least!) is the fuel loading section. On the top of the section is the representation of the 4 tanks (2 main and 2 auxiliary). Left and right of each tank there are buttons to adjust the fuel weight, per tank, in steps of 10 kilograms. Also in the map below, each tank with the relative level of fuel is represented in their actual position on the aircraft. Again, pay special attention on the CG chart! IN CONCLUSION Loading the aircraft is an act of balancing, no pun intended! You have to consider how much fuel you need, the payload (passengers and cargo) you have to carry, and load the aircraft properly within the limits. Act responsible… and before start your engines! After starting the engines, you will not have the ability to alter anything of the above!
  23. 2 points
  24. 2 points
    Thanks JetNoise. I realised that the manual pretty much tells you what to do anyway though. (if the GTN versions don't get activated automatically:) "Simply select them from the Plugins menu, and assign any of the 7xx to GTN1 and any of the 6xx to GTN2." Well, to turn them off (and go back to the default xplane versions) you can just click on the item again in the plugins menu. So I just had the GNS530 with the GTN650 next to it (as I didn't bother changing that during the test). It even lets you make the change mid-flight, although I did lose my flight plan when I tried it (not a complaint, obviously). Thanks.
  25. 2 points
    OK, so I found the bug. It turns out the change we made to try and improve VR in SMP 4.9.4 caused this. As it reportedly didn't actually help VR, I rolled the change back. I've sent X-Aviation a SMP 4.9.5 build that should fix this; hopefully it will be distributed soon and this issue will go away.
  26. 2 points
    Thx a lot guys! I just found the culript, by deactivating the running plugins, one by one. It was OpenVFR´s Iceberg plugin... I always used this plugin, as it also offers a nice fix for the water in XP. But with XP 11.50 b11, it seems to cause some problems. However, the fault wasn´t at your end! ;-) Thx again for this great addon! And yeah, Coop! Good to be back in the saddle (cockpit), again... ;-)
  27. 2 points
    Beautiful, that did the trick - thanks! Would never have occurred to me to try that
  28. 2 points
    Hi I just checked the GTN.ini file the problem is the "nobezel" is set wrong, Backup the original file first RealityXP.GTN.ini search for "nobezal and set to false. Only change the [GTN_750_1.WINDOW] and [ GTN_650_2.WINDOW] section of the file not the Panel one don't alter[GTN_750_1.PANELS] or the [GTN_650_2.PANELS] works fine now
  29. 2 points
    I don't know if this has been reported (haven't seen it), but something I experience often is that VNAV will not engage on departure because the altitude restrictions of the SID are not correct, or just blank with dashes. I don't know if the issue here lies with the AIRAC database, or the IXEG VNAV logic. To fix it I go through LEGS and hit the DELETE key, then right LSK on the "offending" restrictions. Once all are clear, the FMC populates the passing altitudes or flight levels and I can finally engage VNAV.
  30. 2 points
    Real "Impulse 100" (Pocket Rocket) airplane with 450-horsepower Allison turbine has the following performance: - Stall power on: none, climbs with 80° nose up - Stall power off: 39 kts Well, with the "Experimental Flight Model - ON", after some custom Aerodynamic and Prop improvements TorqueSim Pocket Rocket is very close to the above mentioned performance. She is like silk now!
  31. 2 points
    Ok...fixed. here's the deal for the curious. one darn character I have code that evalutes scratchpad entries to see if they're user created. For Lat/Lon types, the format is latitude letter (N or S) followed by number, then a longitude letter (E or W) followed by more numbers. My parser looks like so: [NS]%d*[EW]%d* The problem? using an asterisk allows "no results" to be valid....so this pattern doesn't require any numbers to be between the letters, so SEA for example....the parser is finding the S and the E...and thinks its a Lat/Lon point. Same for CRUSE or ANY waypoint that may have a N or S followed by a E or W. This is what fixes it. [NS]%d+[EW]%d+ Fixed for next patch. Which should be pretty quick. Along with the remaining User Created Waypoints and some much needed love to STAR entries while in descent. -TomK
  32. 2 points
    Thanks for the info Tom, one major issue with the current VNAV profile happens when we have restrictions with below and above altitudes for one fix. It seems to be taking the higher restriction and simply convert it into an above one, ending of course in a very steep descent to catch up. I am sure you are already aware of it. While it forces me to precisely check my fpl against the charts and raises my situation awareness, most users I talk to are not aware and they tend to get frustrated after a while. hope it makes sense cheers Oscar
  33. 2 points
    I'll have a closer look at this. It annoys me in the Saab too. There comes a point where effort for "upgrades and fixes" to the IXEG windows really need to go into the pool for "port to XP11 style windows" though.
  34. 2 points
    So I have recreated it....and will take a stab at it. This one rears its ugly head from time to time and I'd love to get it fixed (as would everyone else I'm sure!) -tkyler
  35. 2 points
    Great job IXEG-TAEM ,flap setting is now so much easier to perform and all the other good new improvements, many thanks for the hard work!
  36. 2 points
    Works perfectly! Thank you all, guys!
  37. 2 points
    I presume there is a confusion here? IXEG_user_prefs.txt is the file updated/modified by IXEG to incorporate new features added B733_prefs.txt is the xplane quick_look feature (numpadkeys). Make a copy of this and place it back after an update hope this helps
  38. 2 points
    I need to organize my error checking messages better and also supress them better for sure. i apologize. I'll be working on this straightaway along with the other user created WPs, which are part of the whole process anyhow. -tkyler
  39. 2 points
    Here you go @ktomais @Morten one more for the list!
  40. 2 points
    As real life engineer working on this plane, i can tell you that if a troubleshooting per manual didn't find the issue, we shoot directly to MEL, i'm pretty sure it is a NO GO item so, flight canceled
  41. 2 points
    working on it, not perfect yet
  42. 2 points
    There are known bugs in Gizmo that are likely responsible for some % of the FPS difference too. Things aren't running 100% as they should. For example: I have the choice between investigating deep system bugs or coming up with a nice soft and gentle reminder system about beta expiries and error log detail. Seemed an obvious choice to me.
  43. 2 points
    Relax, guys. We are providing the Gizmo beta for those willing to help us test it. This comes with some benefits, but also with some burden. It is exactly the same as installing an X-Plane beta version. Now the funny part is - the customers perception of what a beta run is is not the same as the vendors. The customer thinks that a beta is an improvement to the product. Not a regression. Anything not an improvement or at least being equal is considered a HUGE disappointment. The vendor releases the beta to test it against these regressions. Often that includes special "beta" options, such as increased logging of inputs and variables, or has other requirements. So here is the lowdown: If you want us to help make the next version of gizmo stable, smooth and an improvement, please install the beta version and provide feedback. It comes with some benefits, but also some caveat. Install at your own will, we appreciate your help! If you don´t want to, install the stable version. The white writing will stay until the beta run is over, how ever long that may take. You are entitled to a Gizmo version that is stable and has no white writing. You have that one included in your installer. If you guys keep going on about it I can tell you exactly what will happen...There is a LOT of internal discussion at X-Aviation if it is the right thing to include betas with our product, and I think I just about was able to sway the opinion to what we have now. If I won´t succeed in the future, you know why. But at least you won´t have the white writing anymore, then Cheers, Jan
  44. 2 points
    The 733 already has a lot of custom work on top of it and has been credited by pilots of the 733 as very realistic, hell it's even made by one... I'm not sure where you see the flying like a Cessna. Also you should enable the experimental model with the new update.
  45. 2 points
    It will be next week most likely. We are still working on some final FMOD tweaks to get the sounds just perfect. We will be sending it to the store as soon as we are completely happy with it.
  46. 2 points

    Version 1.0.0

    34 downloads

    Do not hesitate if you find some glitches. Interested if you have any better pictures that I found, especially the back of the tail (should the blue band continue ?) and the wings (no immat ?) Enjoy !
  47. 2 points

    Version 1.0.0

    42 downloads

    Do not hesistate if you find some glitches ! Enjoy !
  48. 2 points
    Thanks for asking this, very understandable. The HMB SR22 is a great freeware aircraft, congrats to folks at HMB on that. Our aircraft is being designed with a different set of goals, as is understandable for the differences between payware vs freeware. Our SR22 is poised to be used for training at many different flight schools, as such we aren't making a typical aircraft. The stability and accuracy of what we do is paramount. The TorqueSim SR22 will shine when compared; we have a team of experienced developers working on the many different aspects aircraft. Some of the various points to highlight briefly: - Level of fidelity: we have a fully custom engine model, custom TKS model, custom oxygen, custom electrical, to just scratch the surface. - Our 3D model and textures are some of highest quality ever made for an X-Plane aircraft. - A fully custom-recorded and professionally developed FMOD sound pack. We have spent hundreds of hours recording and mastering the sounds to be perfect in-sim. - Our flight model has been professionally developed and is tuned to perform exactly like the real aircraft. - Maintenance and wear simulation: hundreds of different components are simulated to wear over time, proper care in flying is completely necessary. - Properly tuned for performance. We have many years of combined X-Plane experience, as such we know quite a bit on performance tuning. We are making sure to multithread as much as possible for optimal performance. - Synthetic vision on the G1000 along with numerous other improvements upon the base G1000 - Flight testing and validation, we are working with a team of real pilots and testers to get all the details ironed out and everything to be precise and working. - This and a bunch, bunch more features that we are still working on If these features aren't what you are looking for in X-Plane, the HMB is a fine alternative. We are confident our aircraft will stand its own.
  49. 2 points

    Version 1.0.0

    86 downloads

    Bush missions your thing? Look no further. Installation: Unzip contents into BN-2 liveries folder. N2119V - As seen in the video below.
  50. 2 points

    Version 1.0.0

    81 downloads

    For those pesky Pocket Rocket screens that seem to never stay clean I present you with "No Smudges!" Guaranteed to leave your glass displays as clean as shimmering mermaid. Installation: This download contains new G1000 smudgeless textures. It removes the fingerprints, hand oil and dust from the G1000 screens. Backup your G1kscreenalph.png & G1kscreenalph_NML.png which are located inside your Pocket Rocket's object folder... Once you have those two files saved somewhere else drag and drop the two replacement textures from the zip into the aircraft's object folder and overwrite the old files If it asks you.
×
×
  • Create New...