Jump to content

slgoldberg

Members
  • Posts

    10
  • Joined

  • Last visited

About slgoldberg

  • Birthday 11/18/1963

Profile Information

  • Gender
    Male
  • Location
    KSQL

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

slgoldberg's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hi, folks, First of all, I just wanted to say I think this is an amazingly well-built aircraft with what's very clearly a well thought-out, well-documented collection of plugin functionality as well as commands and datarefs. Well done. However, as the author of A-Better-Camera (ABC, free general-purpose X-Plane plugin for managing the exterior camera), I am having some user reports of compatibility issues, that I'm hoping you'll agree are just bugs, and that can be readily corrected for your next update: (1) Overtaking "sim/general" commands (such as sim/general/{up,down,left,right}, and related): It appears for whatever reason, your systems.xpl plugin is listening on XPLM commands that are normally used for camera control (up, down, left, right, as well as rotating left/right, and hat-switch commands of the same nature). While it's totally fine to do that (I do it, too), you are unfortunately overstepping your bounds in using it even when you're not properly in control of the camera, such as when X-Plane or ABC is controlling the exterior camera. What that means is, you're changing the meaning of ABC's and X-Plane's exterior camera-control keys, and while you seem to be attempting to correctly "wrap" the commands and map them to similar alternatives, you're not doing so in a way that works correctly when another camera is also controlling these commands. So, for example, about 10% of the time, it appears X-Plane never receives the "end" phase of a given command, such as "move up slow". So it'll end up "moving up slow" indefinitely, until someone goes into DRT for example, and hits the "end" phase of the move up slow command. That's kind of a horrible user experience. I am not sure what your intention is, but if you are only trying to take over the "sim/general" commands for the interior (cockpit) camera, then I would beg you to please add code to your handlers for all these commands to completely ignore them (by returning 1 instead of 0) from your command handler, for each phase of each command you listen to -- when the camera is not in the cockpit. Even then, it's kind of weird that you're modifying those commands, I'm not sure what you're doing. But at least if you didn't do it outside the cockpit, it wouldn't have as much chance of colliding with the same command handlers built into X-Plane's camera and into plugins like ABC's. (Note: I'm not positive this is the actual issue; I'm just guessing right now. But I am happy to discuss to figure out what could be causing the runaway camera control behavior with your systems.xpl plugin.) Another thing you should know, if you are trying to use the XPLMCamera API to do something with the exterior camera, there's a known bug in X-Plane that currently incorrectly fails to call your camera control callback with "inIsLosingControl" set to 1 to indicate that another camera has taken over. So, if you are trying to use that to be signaled when another camera has taken control (for collaborative camera control with other plugins), please let me know and I'll tell you a good way to work around this bug so you can be sure whether camera control is owned by you or by another plugin such as ABC. (Thanks.) --- (2) TCAS aircraft position updates: There appears to be something happening (and I have no idea what, so far) with either your bundled X-TCAS plugin, or with your main plugin somehow causing the position updates to be periodically lost (or otherwise altered) for synthetic traffic plugins that are providing aircraft via TCAS. So for example, LiveTraffic and Traffic Global aircraft that are integrated using TCAS override (in XP11.50+) appear to frequently "flicker" (aka "jitter") when viewed through X-Plane's built-in camera, or when viewed by a plugin such as ABC's camera. This doesn't happen when the same plugins are using TCAS override and updating their aircraft positions without the TBM 900 plugins running. So it's definitely something happening that's caused by TBM 900's plugin(s). ABC can also show the non-TCAS version of most traffic's positions, instead of using the TCAS position data, talking directly to the plugins' own APIs -- those never have the flicker/jitter problem, even when TBM 900 is running. So it's specific to TCAS, and likely something that's happening in your plugin(s) that is deferring the update cycle so that periodically TCAS updates aren't properly applied. I'm not sure exactly what I'm saying, I just know it's something like this. :-) Thanks heaps. Steve
  2. Update: I think the VNAV is actually working relatively well on descent under "normal" conditions. What breaks it horribly is when your cruise altitude is less than (or probably equal to) FL100. This is why every time I do a circuit to test this stuff, I run into this problem -- but I don't have it really at all when I'm flying VNAV mode descents from higher (typical) cruise flight levels. For most circuits, I just do the minimum flight level I can fly at with a relatively short flight path around the airport. So normally for a circuit I'll end up with something between FL040 and FL080. Anything higher is usually too hard to achieve unless I add waypoints further away (or fly a STAR with a farther-away transition). So that's why I wasn't really seeing this with some of my longer flights (which I forgot to mention earlier). For longer flights with cruise altitude from FL110 and above, I have only seen it do "normal" things like cut out VNAV once I go to flaps 1, or if I force it to re-engage VNAV mode, and things work great up until a point, maybe I'll have a minor nuisance where it didn't plan the vertical path very well and thus didn't do any better than I could've done with v/s as we agree. :-) So anyway, I just thought I'd throw that extra information in there in case it helps with the development of the full VNAV functionality at some point. If you can't reproduce the problems I'm seeing by simply lowering your cruise altitude to FL080 or so, let me know and maybe I can provide more useful data. To be clear, the problems I'm referring to with flights under FL100 are for example what I show in the linked video above (crazy high speeds in excess of 400 knots when at FL060 and normally the speed should be 230!). I'm hoping we can all agree that 470 knots is never appropriate under FL100. :-) Nor even above since by then it should be in Mach. :-) Thanks again. Hope this is helpful, let me know if I can provide any troubleshooting data but know that I may not have time to really do much because of my "real" job. :-) But happy to at least try to get some basic examples if needed. (Beyond what I uploaded above and what's written here. :-) ) Thanks yet again... Steve
  3. Great idea, thank you! Wow, this is mind-blowing. I don't know how I never understood that about approach speeds. I wonder, do you think that's true for most/all of the planes I might be flying that also have autoland features? For example, I often do this speed varying stuff on landing in the x737, Rotate MD-80, FF Boeing 757, etc., etc. Are you saying I should not be doing that? It seems I have to, in those planes, because they seem to all have a really rough time maintaining stable approach with just Vref+5 as the speed setting in the MCP. They all make me set the speed myself at the end (not sure exactly when) and if I don't change it from whatever's there by default (usually Vref+5) after handoff from VNAV mode during the final phase of landing, I feel the plane might drop out of the sky. For example, with 15 knot headwind, in most planes at least, if I don't manually set the speed to Vref+5+15 (to account for the headwind), the nose goes too high and the longer I wait to add airspeed, the further below the glideslope I end up, which doesn't seem right of course. :-) If this is the only plane to do it "right" and it's not something pilots really have to do, then that's great to know and I'll happily stop doing it because it's quite stressful monitoring the headwind constantly (though I modified a plugin to make it much easier so I can always tell the exact headwind component -- or tailwind if it is the case -- of the current wind hitting the aircraft). But yeah, I guess that wouldn't be how real pilots do it since they don't have the plugin. :-) Regardless, that's really good to know that it should work that way. Yes, I am sure when I have time I'll try that. However, I'm almost positive it's not the case here. My very naive sense is that maybe this plane (blame Nils, I hear?) does custom handling of these basic gesture inputs, and I really wouldn't be surprised if there is a timing bug that only happens to show up in my configuration, or it's more common but most people just don't care or don't use the mouse as much as I do. Note that with the x737, I've used a touchscreen running AIr Manager where I can have a touch-based MCP that allows me to just put my finger on the outside of a dial and spin it either direction to control it. It works great, so maybe I'll either try that with this plane, or hack together something. :-) Not a huge issue, obviously, I was just curious -- since thankfully you do use standard datarefs for the basics which I can't say about everyone else. :-) Finally, just in case it helps you in your VNAV implementation, I wanted to share a very brief video showing one example of how VNAV mode on descents can be extremely difficult to deal with. In this case, I was flying a flight plan with cruise altitude below FL100 (which may be a problem in and of itself; I think these bugs don't show up in higher cruise altitude configurations). Just before passing T/D (in VNAV mode, cruising at FL080 and speed at 250 KIAS), all is good; then I pass T/D and I enter descent mode. Surprisingly, the speed limit bug on the airspeed indicator moves up to 270 knots, instead of going down to 240 or 230 which would be expected (or at least staying where it was since it is below FL100 and thus should not be above 250 anyway). That was confusing enough, but then I did something I probably shouldn't do and edited my FMS route to show speed 230 on my next waypoint. However, immediately after hitting that waypoint (I think), the speed bug rocketed up to *over 400 knots*!! Remember, at this point I was only at FL060-FL070. It was not appropriate under any circumstances to go that fast. Anyway, the video starts right then. I just wanted to show a little bit of the troubleshooting and how frustrating it was :-) and that's that. I don't need to go further on it, I know it's not working, but just in case it helps you think about what might be mucked up. :-) Thanks heaps. Steve
  4. Thanks, Jan -- very useful, in the sense that I wasn't too sure of how much I should expect from VNAV mode on the descent and it sounds like the answer is clear: not much. :-) So, okay, thanks. BTW, I also couldn't find a "DES NOW" button on the FMC and I assume that's something you removed after your demo since I believe your tutorial video actually did show it at one point (though you weren't using it; I thought I saw it there on the descent mode page). Either way, if I am not using VNAV for descents, then I guess I don't need DES NOW. But it would be nice to be able to start a descent a little early in certain cases... but I digress. :-) Re: the manipulators sticking -- no, I'm absolutely not looking away when this happens. I know what you mean, but that's not it! I've had that happen in other places when looking away, and agreed, that's not something people should expect to work correctly. However, in this case I'm not looking away. The most common issue for me comes if I have to frequently adjust my speed when otherwise "stable" during final). I.e., to keep it in the window as the headwinds might be changing radically over the 5 minute period that matters most. To keep the plane stable in that last phase (normally in ILS autoland mode, i.e. with both sides in command mode), I will dial the speed up and down just a few knots, using that speed knob (clicking, dragging, and letting go for each change). Though in fact, the mouse cursor control over the dials such as MCP SPD and HDG is a little frustrating at times. Sometimes it will not let me switch directions (I will switch directions and see the dial spinning the other way, but the numbers will continue to go in the direction I had been going earlier, i.e. speeds may only decrease until I let go and re-click and start a new drag to go the other way -- but that's intermittent as well). But either way, just moving the dial 1-2 knots (for speed for example), can be a little difficult. I often find myself having to make several adjustments before it ends up where I want it. So, this sticking problem just really exacerbates that usability issue, considerably, when it happens. :-( I guess I need to either write a little plugin to just let me have a screen location to adjust the MCP SPD by +/- 1 knot, for those cases -- or else, presumably I can just map that to a separate hardware control or to keys on my keyboard. Because grabbing that dial with the mouse cursor as it is is already pretty risky (things might move much more than I want them to).. But it becomes 10x more risky when the button might stick especially if I forget about it and go on after thinking I've made the adjustment, to then move the mouse unwittingly changing the speed much more radically. Ideas welcome on that -- but it sounds like nobody else has complained of this and you're not seeing it; so I wonder if it could be specific to my mouse (even though I don't see it on any other planes). I definitely see it on many controls within this particular plane, though; I had it happen today on the heading selector (also in the MCP) and while that was easier to notice since the map would also show the heading graphically, it was still a little irksome. :-) Anyway, I'll just try to figure out a way to avoid it for now. I just didn't expect to be the only one to see this problem. And just to be clear re: the first issue with the VNAV descent speed and flap speeds, etc. -- of course, I can readily switch to using the more traditional FL CHG or vertical speed mode, but those of course as you know require more skill than I'm necessarily equipped for today (including having to actually plan my descents whereas in VNAV mode I can focus more on other things). But it's all good. I suppose I should really take this opportunity to practice non-VNAV descents since your plane is much more realistic in most other ways for those. Thanks again. Steve
  5. Thanks, Matthias. (Sorry for the delay but was offline for a couple of weeks.)
  6. Hi, folks. Before I post a detailed bug report (probably two separate ones), I would like to just reconfirm whether these are known issues or really obvious problems, since I scoured this forum and the web in general, but could not find mention of these anywhere. (I also looked in the documentation that came with the plane, but no joy.) First, I have to say this is a really great and realistic implementation of the 737-300 -- great job! I believe you have said that the VNAV implementation is still not 100% robust, so I assume the first problem below is just a symptom of that. But if you haven't seen this, it would be good to make sure: (1) VNAV mode descents, FMC speed versus pilot/MCP speed authority. This really causes VNAV mode to be unusable for descents for me. I watched the very awesome tutorial video several times to be sure I wasn't doing something wrong, but I can't even replicate that functionality; the problem happens in that case for me as well: There does not appear to be a "speed intervention" control like on later versions of the 737, so I assume I can't actually use VNAV at all when the FMS speed is not what I want. But I am not sure if there are cases where I can actually set the speed myself on the MCP while still in VNAV mode. But either way, the problem is in VNAV mode. When flying a flight plan with sensible (and valid) altitudes for every waypoint (best example is no STAR, just the KSFO 28L ARCHI arrival which has altitude restrictions along the path that are all very sensible, all in a straight line, etc.) in VNAV mode, I see the little green circle on the map that shows when it would normally reduce speed. In addition, I've filled out the correct flaps setting and speed reference on the approach page of the FMC, so it supposedly knows what speed I need to be at for each flaps setting, etc. For the problems I'm seeing, I also make sure I'm already past the "T/D" icon and that the DES page is automatically selected on my FO side, so it is in descent mode and it is honoring the changed altitude I've set in the MCP. So as it's descending, and it passes the green circle, it's not behaving as it does in your videos. Despite having the approach reference settings for flaps, I never see that speed in the DES page that you show with the "/FLAPS" tag or whatever it is. I have seen it sometimes, but not in this case when I really need it. In fact, I believe (I need to do a full test to get his all nailed down so you have the facts), I have mostly only seen it stay at 250 knots sometimes faster, on the descent through T/D. It never seems to slow to 230 (or if it does, it still has the following problem). Through several attempted methods, I think I finally get it to set the speed correctly and I get to 230 knots, so I can put down flaps 1. And I thought it was the case that, in VNAV mode, once you're at 230 or below, you can invoke flaps and it will correctly set the FMS speed to be according to the flaps speed schedule (as in your tutorial video). However, at this point, flaps 1 starts a chain of frustration and potentially deadly consequences (if this were the real world :-) ), that makes me have to abandon VNAV mode right when I really want it the most... As soon as I hit flaps 1 (with speed at 230, and FMS in descent mode with descent page configured for flaps 40 reference speed, normal winds just a few knots of headwind), the MCP speed indicator lights up (normally it's blank in VNAV mode). It shows the current speed with a "B" indicator to the left of it (though it's been hard to find, and I'm not a real pilot :-), I can't find what the B actually means, but I believe from experience it means overspeed for the flaps?), but it *doesn't* lower the speed to the official flaps 1 speed, and it doesn't reflect any change in the DES page in the FMC, so I'm very very confused. Why am I not seeing what you see in your tutorial flight? When and how am I supposed to take advantage of the "/FLAPS" automatic settting of the speed in the FMS? Is this a known issue or something I'm doing wrong? In this case, unless I kill VNAV mode (and even then I don't know if it will let me change the speed yet), and no matter what I do, I can't take over and change the speed. I try to move the speed knob and I see it lower a little but then it immediately pops back up to the top number that I don't want, and then I am forced to either flaps-up again or disconnect VNAV mode. To be very clear, I'm not at all stalling nor anywhere near stall speed. So this isn't alpha protection (which I believe is an A, not a B, anyway, right?). I am going quite fast, descending, trying to slow my descent so I can acquire the glideslope for an ILS landing etc. I do all that just fine, but it's very frustrating with the flaps and speed. I know the logic is inverted in VNAV mode, since normally you set the speed you want when you aren't using VNAV, and you either do a speed-limited descent or a rate-limited descent. And when I do those, they work fine. Except for the bug in (2) below, but .. I am always able to land successfully using ILS. It's just really frustrating that the handoff from descent mode after passing top of descent to autoland mode with G/S and both APs engaged, is a real battle while VNAV is engaged, whereas normally it would be quite elegant. (2) MCP speed knob "stickiness". This is a big, actually really big problem for me and I'm wondering if it's also a problem for others. I'm happy to spend some time troubleshooting and trying different test cases to see what causes it to fail, but right now it's really very random (maybe 1 in 15 times I turn the IAS knob in the MCP, regardless of which mode I'm in). In fact, it happens on other dials, as well, but this is the on that really destroys me: Every once in a while (about once every 15 times I use the IAS knob using my mouse cursor on Windows 10, XP11.05), after I've finished setting the speed I want and released my finger from the mouse button, I discover that in fact that speed dial did *not* release from my cursor, and though I'm moving my cursor off to another control, it's actually inadvertently continuing to change the speed setting in the MCP! This is really brutal! There have been times on descent, where I am at flaps 10 and I just want to lower the speed to landing speed, so I dial it down from 190 to let's say 129 knots for example, and after ten seconds of me moving my mouse around getting ready to maybe click another thing with my mouse, I suddenly realize my speed setting has been tracking my mouse unbeknownst to me! And the speed is now set at 250, sometimes higher! Of course, by the time I realize the error, I'm usually very close to if not already over speed for the current flaps. It's horrible. I am really frustrated by how difficult it is to fine-tune the speed anyway, but it's even worse when sometimes the mouse doesn't actually "let go" of the speed dial! I can easily replicate this, but I can't give a simple test case that will guarantee that it happens, I just have to keep using the knob and for certain it will "stick" at some point in the next 10-20 attempts. Has anyone else reported or seen this perhaps? Not just with the speed, but certainly that's the worst case. I have a lot of different planes, and have never seen this with any of them. This is really the first time this has ever happened to me (and I bought this plane only starting with v1.2, so I don't know if it predates this version or not). Thanks!! Steve
  7. I know this thread is a year+ old, but I have scoured the forums and web in general looking for any clarity on this subject, and this is the closest place I've found it. So I'm hoping someone can answer. Cryptically, throughout this thread have been mentions of different versions of XPUIPC, with the "latest" being referred to as 1.0.7. But in fact, as of today (August, 2017) the version is I believe 2.0.4.7 -- but I can't for the life of me find that anywhere. When I go to the official website for XPUIPC (http://www.tosi-online.de/XPUIPC/XPUIPC.html), it doesn't look like that site has been touched since 2013, and it is clearly *not* version 2.0.4.7. At best, it looks like it could be 2.0.2.0 but even that's not clear. The title and the file name and all the other text refers to it simply as 2.0.0.0, but there's one place it mentions 2.0.2.0 (in changelog 2.0.2.0.txt). Maybe this is too off-topic, but .. help? What is the right version today and where do I see it and any information about it? If it's a paid upgrade I'm happy to pay. I just can't figure this out. Thanks.
  8. It's not a request for SSG. It's a request for Ricardo to explain to the good people at Laminar since they obviously do not understand this concept, that the current sound configuration options are useless and that plane designers are ignoring them altogether and that the combination of them ignoring them and poorly implemented third-party sound plugins not working correctly at all is extremely frustrating for those of us who pay for this crap. Thanks anyway. Steve
  9. Perhaps more succinctly: External volume and internal volume are not the same scale, whether I set up XP11's sliders or not (I do, but they're ignored right now by SSG B748-i/f v1.6). So for example, let's say sound volume is a simple scale from 0 to 10, with 0 being silent/muted, and 10 being maximum. Well, here's the crux of my problem: In XP11, external sounds are played at a volume level of somewhere around 3-5x that of internal sounds. So, what would be level 1 inside the cockpit, turns into level 5 outside. That is, a soft sound inside the cockpit turns into a loud sound outside. (This makes sense, since presumably both the plane and the simulator are trying to correctly model how sound really would be, i.e. to attenuate the sound when there are objects in the way, and especially where in a 3-D world the source of the sound is farther away and is directional, and the cockpit being in front of the engines and the bulk of the sound going out the back of the engines, it makes sense it is lower in the cockpit.) However, the whole concept of volume controls -- and the reason people (humans) ask for volume controls -- is to modify the real-world parameters to accommodate something external to the simulator (or at least, something that only a human cares about). In this case, I want to be able to hear the copilot when I'm looking from outside the plane but also hear the engines at all when I'm inside. When I'm narrating a screencast, too, I want my voice to be heard even though I may have shifted the camera to be outside the plane. I just want to hear the engines, and I want to specify that the level of the engines *in* the cockpit needs to be X, and the level of the engines outside should be Y. But the plane in this case, and XP11 though it's ignored by this plane, are both trying to force me to have them both be "X". Which means, if I specify X=5 in the cockpit, that means X=15 (!!) outside! It's so frickin' loud out there, guys, it's ruining the experience. Not only that, but as XP11 tries to change the sound level based on your camera position, if you move the camera toward or away from the plane while it's flying, in exterior view, you get this horrible motion parallax which of course is correct, but still very annoying when the source sounds akin to a chainsaw to begin with. Commensurately, when you set the volume level so it is a reasonable level outside (i.e., X = 2) then it's far too soft to hear inside (really that means X = 0.05 or something). This idea of camera placement and volume control is entirely for the purpose of humans, not the accuracy of the simulation. So, I'm just basically asking for you to make the sound level not be a simple "amplifier" (that also attenuates if the volume is lower etc.) -- because if I say I want level 5 and change sources on my amp between a loud source (outside) and a quiet source (inside), an amp will happily just amplify both the same amount which of course is what is happening here. I want, instead, to express volume in this context as an override, or a maximum, or whatever you want to think of it as. I want to have it be lower level than what you've modeled it here. I.e., "level 5" means, "5/10 after all other amplifications have happened". I.e., as a function of the current model, not just a simple filter. Though it doesn't need to be that complicated; I'm speaking abstractly. In reality since everything in this realm degenerates nicely to "inside" and "outside" the plane, then for all that is right in the universe, please just give me two volume sliders again! (You used to have these, i.e. internal and external. X-Plane has them but they aren't just for engine noise, but everything.) So I guess my request is really simple: please get rid of this "DreamEngine" plugin that does really nothing at all of any value (what does it do? I can't tell anything good about it, sorry), and replace it with the X-Plane built-in volume sliders, at a minimum. In summary, here are my three proposals, unless someone can tell me this is already solved somehow and I just don't understand it yet. :-) : Option 1: Correctly honor the X-Plane internal/external volume settings for the engine sounds. Option 2: (Re-) separate the volume controls for Engine Sound level to be "for inside" and "for outside". Option 3: [preferred, simplest] Automatically scale the engine sound level based on whether the view is inside or outside. So if the user says "level 5", make that really level 5 in both interior and exterior views. That probably means having a simple mapping function, i.e. mapSoundLevel(viewType) where viewType is "internal" or "external", and have the actual volume sent to DreamEngine be the result of that mapping function. I.e., something like (where say userRequestedVolume = 5): actualVolume = mapSoundLevel(userRequestedVolume, viewType) or whatever.. -- OK sorry, I just really needed to get that off my chest. :-) Hope it's useful to get user input here and/or if I'm confused, if you can clear it up, I'm hoping others can benefit from this as well. Thanks. Steve
  10. Hi, @Ricardo Bolognini and anyone else who might have ideas. I recently got back to using the payware SSG Boeing 747-800 (which I'll abbreviate SSG B748 herein) and upgraded to 1.5.2 and then to 1.6 using the updater, etc. since it now seems to better work with XP11. Let me start by saying, I absolutely LOVE the SSG products and especially this version of the 747 (both -i and -f)! I love the fact that you include the full FMC (thanks, Javier? :-) ), .. so many good things here. However, I am really flustered by and frustrated with the engine volume / "DreamEngine" (more like "NightmareEngine" :-) ) situation. In XP11, for better or worse, there are simple global sound knobs in the Settings > Sound screen, though they are not honored by a lot of third-party planes and plugins. That's fine, I can live with that, because I don't really seem to get what I need from those controls anyway. In SSG B748 (both versions), I know there are two separate sound controls: one in the setup screen on the side of the pilots' chairs, and the other in the DreamEngine pop-up that you get if you select it from the Plugins pull-down. In both cases, they give me *exactly the opposite* of what I want/need! Here's my problem: I *want* to hear the engines in the cockpit, and when I switch to the external view, I want to hear the engines at a lower volume (or at least the same volume) but -- more importantly -- I want to be able to *hear* other things I can normally hear but are drowned out by the engine sounds (such as my copilot when using MCE, or an alert, etc.). However, it's exactly backwards: what I *do* hear is extremely loud engine noise when I'm viewing externally; overwhelmingly so that it's shocking when I switch from interior to exterior views. Additionally, I can barely hear anything else while I'm in an exterior view -- especially in flight. But when I switch to the cockpit view, I can hear everything well *except* the engines. If I put the Engine sound at maximum, in *either* or *both* controls (DreamEngine plugin and/or side panel) I get the same result: the volume affects *both* the internal and external sound. So, I can't turn up the volume of the engines inside the cockpit without also turning up the volume of the engines outside. That seems like the absolute wrong result. Backwards, entirely. Because now, if I want to hear the engines in the cockpit at a normal volume, I have to set the engine sound high (or even medium) and it sounds good in the cockpit. However, the instant I go outside (e.g. "Circle" view) I get the loudest cacophony of noise I ever heard. It shocks me every time. I have to dial the PC volume down really far to be able to tolerate it. But if I then go back inside the cockpit, I can't hear a damned thing of course, so I ratchet the volume back up, and .. the nightmare repeats. I can't find anyone else who posted about this but it's been hard to search for this particular thing so I admit I may have missed it somewhere. So am I really the only one with this problem?? Perhaps everyone but me has some other sound plugin that makes X-Plane 11 sound work better?) -- All this stuff about 3D sound and I just get LOUD NOISE when outside and ALMOST NOTHING when inside. Ugh. Sorry to rant, but I'm at my wit's end. I spent so much time just trying to figure this out, and I am at a loss so I'm finally posting here. If you can help, that would be awesome. I read the FCOM, I scoured the internet, I looked int he config files, I even removed my third-party plugins to see if that could be it .. and nothing has solved this. It really feels as if everyone thinks this is the right way for it to be. But I don't see how. Really, does nobody else but me switch views from internal to external all the time and have this volume nightmare to deal with? Sound as everyone knows is super important. Not just because it's an awesome part of the simulated world, but it's something that people really need to get right (for example, when someone has a hearing disability, etc.). So, I just really can't understand this. I know I should rant on the X-Plane 11 forum as well since it's probably at its heart an XP11 problem (all the claims by Laminar Research of XP11's improved sound synthesis, yet in the end there's no way to separately control interior and exterior volume?!) -- but you seem to use your own system anyway, so .. I think it's not going to help in this particular case. Finally, I recognize that many third-party planes use the audio panel inside the cockpit to put things like radio volume and sources to listen to (such as JAR's awesome 330, among many others), but you don't seem to support that in your 747 audio panel. You seem to have just the VHF buttons "hot"; the rest are stubbed out... so unless I just missed it, I don't see how that panel would help me in this case). Thanks so much for your help. Steve
×
×
  • Create New...