kentwerickson
-
Posts
88 -
Joined
-
Last visited
Content Type
Profiles
Forums
Latest X-Plane & Community News
Calendar
Downloads
Store
Posts posted by kentwerickson
-
-
I am not seeing any engine exhaust heat effect in v1.61. Running XP11.51+, Vulkan. Tested with all 3rd party plugins disabled.
(Please forgive me if this issue has been reported elsewhere -- I've had a look and did not see it).EDIT: I'm not seeing the effect running OpenGL either.
-
2 hours ago, nicotum said:
You may want to have a look at my plugin for "differential and progressive brakes".
Oh my goodness this is even better! Thanks very much!
-
On 2/27/2021 at 8:04 AM, Ch.Cole said:
Try this. I assume you have flywithlua installed? The command is FlyWithLua/SF34/Hold_Brakes_reg .
That did the trick; thanks very much!
EDIT: For others who may be interested, I just discovered that the plugin below also works (a bit better in my opinion because the brakes are applied more smoothly using the "gradual" option.
https://forums.x-plane.org/index.php?/files/file/9487-progressive-braking-plugin/
-
On 2/27/2021 at 9:00 AM, JGregory said:
The "hold" brake issue has nothing to do with Gizmo. We simply didn't include the commands in the 1.6.0 release. This will be fixed for the next release. The "v" and "b" keys (commands) work for braking in 1.6.0.
Got it, thanks for clarifying.
-
1 hour ago, Ch.Cole said:
Would a lua-script help you, that holds the brakes while a button is pressed help you?
This would be the next best option if you know how (I lack such skills), and so long as it doesn't interfere with other functionality. Yet I'd much prefer to have this functionality native to the 340A logic -- doesn't seem to be problem for other aircraft developers. But maybe it's a Gizmo constraint introduced by changes in XP11?
-
4 hours ago, jgniewkowski said:
you can assign the toggle brake commands to a joystick button...
Thanks for the feedback. This I know, because the joystick button I have mapped for the parking brake (Toggle brakes max effort) still works with the newly updated 340A.
Quote... but can no longer assign the HOLD brake command.
This is the unfortunate/unexpected news, especially for me also being unable to control the power levers with my joystick; e.g., I cannot conveniently control my speed during taxi by easing the power levers into the beta/reverser range. I can still perform this action with keyboard assignments, but then it becomes difficult to track the exact position of the levers without constantly watching them -- just not conducive to a sim environment.
But thanks for confirming.
-
Thanks Goran, for your reply.
QuoteThe Power levers should work with a regular axis.
The triggers on my Xbox controller are treated by XP the same as (regular) joystick axes. They can be reversed, response curves set, etc. There are several throttle control options available from the pulldown menu, including "Backup Throttle," "Throttle Vertical," "Throttle Horizontal," and then individual controls for Throttles 1-8. I have tried each of these options with the 340A but no luck -- no throttle movement at all. As I recall from the XP10 version of the 340A, I had to first move the levers with my mouse just a bit forward of ground idle before the Xbox triggers would work (I think maybe to overcome a detent). But once I'd done this I could then control their full range of motion using the triggers. I've also tried this with the v1.61 update but still no joy.
Now, I am still relatively new to XP11 and do not fully understand the difference between the pulldown options mentioned above. But I have been using "Throttle Horizontal" for all of my other twin engine aircraft, which again works fine -- I use one trigger to simultaneously move both the left and right throttle/power levers forward, and the other trigger to move them both backward. And so it seems clear that the 340A is "unique" in this respect.
I can control the 340A levers with the mouse, and via keyboard mappings (using XP's default throttle commands). But both of these options are pretty awkward when trying to fly the plane by hand (e.g., during takeoff and landing, and even while taxiing). I also have a pair of spare joystick buttons that I can use to control the condition/fuel levers (forward and backward) -- these work fine with the 340A. But I don't have any spare buttons for the power levers; just the triggers which again until now I have been using without issues since XP10.QuoteBraking is now down to just using datarefs, which means V key for Park brakes and B key for foot brakes. We're looking into commands.
It would be really nice if we could map the toe brake function (at least) to a joystick button (if this is possible via "commands"). Otherwise, it's again super awkward to apply brakes, say during taxi and upon landing, using the keyboard.
As for the sound issue, I plan to do some more testing because this could quite possibly be a problem on my end.
Thanks again for your help.
-
Firstly, thanks very much for the update! A few things I've noticed immediately (tested with all third-party plugins disabled):
1. It is possible to close the main cabin door with the stairs deployed (don't recall if this was possible in the XP10 version, or even whether this should not be possible in the real world - I'm guessing not). But either way, not a big deal -- just an FYI.
2. More critically, I can no longer control either the power/thrust levers or the brakes (hold brakes regular effort) with my Xbox 360 controller. In XP10, I used the left and right triggers for power control (forward and back, both engines simultaneously), and pushed down on the left joystick to apply momentary braking. My 360 controller works fine for these purposes with other sophisticated XP11 aircraft; e.g., the AFL King Air, the Zibo 737, X-Crafts E Series, etc.3. All aircraft/systems sounds are often completely muted upon sim startup. My Gizmo sound settings/sliders are all maxed out (and I've reset the widget a few times), and nothing wrong with my XP system sounds -- when I load a different plane, the sounds work just fine again. This seems to be an intermittent problem, as on some loads the 340A sounds work, at least initially. For on one trial I paused the sim for a few minutes. But when I resumed the sounds were gone.
Any help/advice would be greatly appreciated.
-
8 hours ago, Yorkshire said:
Hi
I purchased the Skymaxx pro v5 upgrade from ver 4 and installed with no issues. Soon there as an update, 5.04, installed with no issues. Then I downloaded another update 5.0.5 and get the following message at the end of the install process “Unable to download component SkyMaxx Pro; Component file version does not match.”
I have no idea what this means! All I know is that it doesn’t seem to install and I am left with nothing. Please tell me what is going on and what needs to be done to rectify this situation.
Thanks
I had roughly the same problem. When I first downloaded the SMP v5.05 installer, SMP installed fine. On first launch, I then checked the configuration box for volumetric clouds -- nothing happened/changed, and afterward I was unable to clear this setting; i.e., the checkbox was "stuck" on.
So I tried to re-install v5.05 (several times) using the same installer and began receiving the error above. After reading this post, I re-downloaded the v5.05 installer and this fixed the installation problem, but not the stuck checkbox problem.
EDIT: I now see that the volumetric setting is mutually exclusive with other cloud type settings -- you apparently can't have both checked at the same time. The volumetric clouds definitely don't help my FPS.
-
13 hours ago, sundog said:
I actually don't receive any of the installers myself, but if you contact X-Aviation support they may be able to help.
In other words I'm SOL. Well, I certainly don't blame Sundog -- you guys have been among the few notable exceptions over the years of standing by your products and offering timely fixes/updates, and I applaud you for that (as for the others, just one more reason I am still on XP10).
-
8 hours ago, sundog said:
I just reviewed all the changes between 4.9.4 and 4.9.6 and I don't see anything that might explain a change in how propellers appear in X-Plane 10. Most of the changes involved support for X-Plane 11.50, so if 4.9.4 is working well for you you're probably best advised to stick with it for now.
Can you then post a link here, or send to me by PM, the v4.9.5 installer so I can try that?
Thanks.
-
On 8/31/2020 at 6:03 AM, sundog said:
Does it make a difference if your landing lights are on or off?
No. This is among the first things I checked -- turned off all external aircraft lights (they are turned on in the images here because in order to save time while testing I had XP set to load the plane with the engines already running and ready for takeoff). Also tested to see if time of day matters -- e.g., day/dusk/night. No difference.
On 8/31/2020 at 6:03 AM, sundog said:And out of curiosity, why are you still on X-Plane 10.51?
Variety of reasons, including that I could not afford to repurchase all of my payware for XP11 (plus, I was not initially all that impressed with what I considered to be mostly incremental improvements in XP11). The Dash 8 is payware by FlyJSim, and from what I understand was eventually updated for XP11 (but not in early versions). The problem I am experiencing appears related, maybe, to the normal maps of the prop objects. Not sure that this has changed from XP10 to XP11, but perhaps someone else out there knows...
I should add that the props on the Dash 8 with SMP v4.9.6.2 look normal when not wound up -- it's only when the engines are running and the props are spinning. I just now tested with my LES Saab 340A and the weird effect occurs with this plane as well.
Follow-on question: I still have the installer for SMP v4.9.4. If I run this installer, will I get the older version or does X-Aviation always push the latest version? This way I can test to verify whether or not the problem is related to something that has changed between these two versions.
UPDATE: I just tested my Dash 8 in the latest XP11 Demo version with SMP v4.9.6.2 installed, and as the image below shows the weird effect does not occur here. So it seems that you are right that this appears to be an XP10-specific problem.
UPDATE 2: I re-ran the SMP v4.9.4 installer (in my XP10 installation), and the problem disappears in this version as depicted below (I've lost the v4.9.5 installer). So it appears that this problem was introduced by changes either in SMP v4.9.5 or 4.9.6.
-
I've just discovered a strange anomaly with SMP v4.9.6.2. Compare the lighting on the prop blades in the two attached screenshots; the first is with SMP enabled, and the second with SMP disabled (no other changes). The second image is how the props should look.
I only now just noticed this issue because I haven't flown the Dash 8 for quite awhile, and it took me quite awhile to narrow down the culprit to SMP -- or so I believe, and who'd have guessed??? (at first I had no idea what could be causing this issue, and tried lots of other things before realizing that the last SMP update was the last change I'd made to my XP installation in quite some time).I am running SMP with XP v10.51 (with HDR enabled) on a Windows 10 machine (Intel Core i7 7700HQ) and Nvidia GTX 1060 graphics card.
-
Thanks very much! View from Half Moon Bay (CA) with evening fog rolling in is close to sublime! (XP10)
-
1
-
-
Thank you!!!
-
7 minutes ago, diamonddriller said:
Thanks Frank. That has clarified things. I was well aware of the https problem, virtually as soon as it happened! I had some correspondence with LR, and thought that they were looking at this, but nothing has happened for XP10. I suppose, as XP11 has this fixed, they are no longer bothering with XP10. As they have already written the code for this in XP11, I am surprised that they couldn't port this to XP10.
kentwerickson has a point about bypassing Gizmo, but Cameron has said that Gizmo was being altered, and that it was not a simple fix.
I can confirm that LR will not be retrograding XP10, which while disappointing is somewhat understandable. Yet by the same token, since LR is still selling XP10, which is advertised as supporting real-world weather, you'd think they might have just bitten the bullet on this one; if even as an unsupported patch. Alas, not to be.
-
3 hours ago, sundog said:
Since I don't know when that will happen, we implemented a "plan B" in SMP 4.8 that will go get that data itself if Gizmo fails to get it - but this comes at the cost of a performance stutter.
While perhaps not an ideal solution, I for one am grateful that you gave us the next best option. Better yet if RWC could just download in the background and then inject/update at regular intervals. In other words, since RWC is reportedly capable of downloading the data itself, is it not possible to just bypass Gizmo altogether?
-
12 minutes ago, sundog said:
Just to clarify - in our forthcoming 4.8.1 release I'm issuing a fix so that new weather is only downloaded once per hour when "always" mode is on, and Gizmo is not getting it for us successfully.
This should at least reduce the stutters to once per hour while we wait for that fix, if you must run with "always" enabled.
That's great. I could even live with a momentary delay as often as once every 5-10 minutes. Seems unlikely that real weather would change dramatically between this interval, but once per hour might be pushing it. Of course others might have a different take on this. But generally speaking, what I find most important is that my injected/simulated weather match the real weather (or near enough), particularly in regard to wind conditions, during takeoff and landing; e.g., so that active runway selection is more or less accurate.
-
13 hours ago, diamonddriller said:
@kentwericksonHmm. RWC in "Never" mode for XPGFS. I still don't get this (although XPGFS will certainly work properly without RWC, as it was designed to do so! ). However, I would have thought that the "external injector" might work, as one of the points of RWC was (I thought) to smooth out transitions from one area to another, and I presume XPGFS is an external injector.
Yes, I understand that XPGFS will work without RWC -- this is what I've been stuck with for the past several months. But as I understand, RWC draws clouds with greater precision and fidelity along with certain other features that justify its additional cost (including more recently smoother transitions). But I agree that the relationships between all of these weather-related plugins is pretty confusing, and I am not certain that I have it right.
CORRECTION: It appears that I misremembered -- according to the RWC manual I should be using "Always" with XPGFS, which again causes stutters. I assume that I must await an update to Gizmo to fix this problem (or anyhow hopefully).
In the meantime, and in high praise to the good folks at Sundog, I am very happy to report that this (see images below) looks more like a thunderstorm in my neck of the woods:
-
1
-
-
9 hours ago, Jakob Ludwig said:
It might be that you're maxing out your GPU VRAM. Try to reduce the cloud draw distance and/or change overcast cloud textures and monitor the loading stutters. Could be that the new textures need a bit more memory in certain wx conditions.
Thanks for the suggestion Jakob. I have tried lowering the settings. But as mentioned, SMP with my current settings runs fine by itself and reports that I have plenty of RAM and VRAM.
-
3 hours ago, sundog said:
SMP 4.8 just contains a backup means to download weather data if Gizmo fails to download it for us, when you have RWC in "always" mode. It does create a stutter I'm afraid, since we aren't using an external plugin (Gizmo) to download it in the background.
We do still need HTTPS support in Gizmo to get "always" mode working the way it used to. But that's in X-Aviation's hands.
If you are using RWC in any mode other than "Always" however, things should be working as they always have.
Thanks Frank. I neglected to mention that I run RWC in "Never" mode, which as I understand is the appropriate mode for XPGFS, yet am still experiencing stutters. Or, is it the case that I still need to await a Gizmo update to fix this particular problem?
-
I am ecstatic about the recent update -- thanks very much! But (FYI) I am now experiencing fairly dramatic FPS stutters/freezes with RWC enabled -- about every 30-60 seconds (which I assume corresponds with XPGFS weather updates). This occurs even when sitting stationary on the ground; i.e., not caused by flying into new weather patterns.
I've verified this, first by disabling all other third party addons, and then running both with and without RWC enabled. SMP + XPGFS consistently runs like butter on my system, but the stutters return with RWC enabled. I also don't recall this ever occurring prior to the recent RWC/Gizmo outage.
-
3 hours ago, Cameron said:
Yes, I am saying exactly that. X-Plane 11 gets its data from the same source as default X-Plane. Simply placing Real Weather Connector to the "automatic" setting with X-Plane 11 real weather turned on will produce the same result as if our data were working.
Not sure I follow your distinction here between "X-Plane 11" and "default X-Plane." But as things stand, I can still run RWC in "Automatic" mode in XP10 together with XPGFS (Joan's NOAA weather plugin) as my surrogate weather engine; i.e., XPGFS still injects accurate real-world weather data in XP10, and SMP still draws clouds that are relatively consistent with this data. However it seems that RWC in this configuration (in "Automatic" mode) is not really doing anything other than not causing problems (i.e., not causing XP to crash). For I get the same results with RWC disabled; i.e., when running only XPGFS + SMP.
Rather the problem arises when I have RWC enabled and set to "Always," as I did prior to the NOAA server issue. In this configuration SMP stops drawing clouds. In other words, it seems that while the weather data interface between XP10, XPGFS, and SMP all still work fine, the interface somewhere between XP10, XPGFS, and RWC does not. Perhaps I am missing something. But otherwise, I don't understand how RWC/Gizmo, in its current form, can interpret the native real-world weather data generated by XP11?
-
40 minutes ago, Cameron said:
You don't have to bother checking this thread for updates because you'll get an email anyhow.
I don't know of any plugin that works in native X-Plane that required an update for this. NOAA doesn't even count. You're way back in the realm of X-Plane 10, and Laminar didn't even update it for you. Be thankful we're willing to do it instead.
I'm not going to argue this out. It's being actively worked on. If you were using X-Plane 11 this wouldn't even be a concern since X-Plane fixed it there.Thanks. Reassurance is at least partly what I am seeking, and in my view not unreasonably so. But just to be clear, are you saying that if I simply upgrade to XP11 this will immediately solve my issue with respect to RWC (i.e., without having to invest in a new weather injector such as FSGRW)? For as I understand, the issue with RWC (via Gizmo) is not XP version-specific. Ben Russell writes above:
Gizmo handles the data download function for RWC.
Gizmo does not currently support HTTPS.
This will affect XP10 and XP11.
Saab 340A v1.6 Issues/Questions
in Saab 340A
Posted
For the benefit of anyone else having the throttle control issue I reported above, I finally figured out a work-around by assigning custom commands to my trigger axes -- "throttle up a bit" and "throttle down a bit."