Roman Design

This is already working in my box. At least on GNS530. But the specific things you mentioned work great - push-for-cursor, outer knob for position, inner knob to letters - just like the real thing. GNS 530 works almost fully, with exception of some buttons. What I have mapped is what I decided to be most important and easy to locate by touch in sensible order: MENU, CLR, ENT, DIR, FPL. Left dual encoder works for radios, just like the real thing, button next to it swaps frequencies. G1000, G3000 and a touch screen G3X GPS units are obviously different, and can't be mapped as well. Mapping side panel buttons is not feasible for VR anyway. But same knobs would do all other functions like radios, altimeter, transponder, altitude and VS setting for autopilot, heading bug, course. Zoom also works fine on all units. G3000 in TBM has lower small screen encoders mapped, but they don't do very much unfortunately, it's a touch screen operation. So waiting for VR controller support to operate those without a mouse (which I hate in VR as a badly designed crutch).

I think I'm building somethinf much better, not to mention much cheaper. How does a VR-targeted control box with 6 dual encoders, 8 buttons anda 3-position switch sound? 2 dual enconers and 2 single encodres are already working, waiting fir parts to complete. Garmin gns 530 works almost entirely via the encoder box, for example. Heading bug, course, altimeter, COM/NAV radio tuning, transponder etc, work too. 3D-pronted knobs are different shapes to make sure you're touching the right one. Parts cost around $25. 3D printer is required though... I'll publish all files when it's complete. https://forums.flightsimulator.com/t/wip-cheap-diy-vr-control-box-6-dual-encoder-8-button-1-3-pos-switch-project/401374

It will probably take a while. Generally, their approach is quite genius, and generates very convincing snow almost everywhere, without any extra data needed to the sim. They did a great job. But they should have thought more about the aprons, taxiways and runways. Either give us, developers, more control over the snow via a texture channel or something, but even better - just tweak the procedural snow algorithm to account for runways, taxiways and aprons and have them gently covered with snow at the edges with just some traces in the center, and disable the texture color-based coverage for those. Same would work well for large roads. And that should work well everywhere and look fairly convincing. But there are so many things wrong with it yet, so that will take a long while I think...

There's a nice video review if CYOW by FilbertFlies channel:

Thanks for a great review! Due to video limited time, there are many parts that didn't make it to the review, so for those interested, I would recommend taking a look at the photos on the CYOW page (link in the sig) or on this forum's CYOW topic as they show all interesting parts. There's a bridge you can taxi on, wind tunnel complex, cargo hangar and 2 hotels with parallax windows, firehall, and other interesting locations, buildings, billboards, sculptures etc. If you set airport traffic and planes in the sim, you will have a number of airliners and GA aircraft randomly parked at gates and parking starts, and moving around the airport. So I felt there is no need for static plane models, as dynamic AI planes are more realistic. Here's a few notes, similar to what I posted as a comment on the video, for those interested in details: the double concrete seams are visible because the underlying aerial photo textures are blending and bleeding through the MSFS Apron textures. There is no control over that. All apron textures are blending with the ground below. Usually it's good, because it gives some variation to the texture, but when there are slabs like that it becomes weird. Some kinds of ground textures can be opaque, but they are not aprons, and can't be rotated and aligned, for example. There are 3 other open hangars, and other areas that weren't in the review, just in case someone is interested. There are some weird bug in MSFS: the glass is tinted from inside in every building with interior, but one, where I've done it in the same way, but for some reason it doesn't work. Snow is a huge problem: I as a developer have absolutely no control over the snow. It depends on the underlying aerial photo texture color and intensity, and when using different ground textures it's a complete lottery about how the snow will appear. Runways are using one of the Asobo runway textures that is closest to the real airport, and possibly because it's not too dark it's covered in snow. Custom paint textures are on top of that. And custom paint lines on Aprons seem to be painted over the snow for some reason, and again, I have no control over that whatsoever. So there are many quirks like that. Some are possible to work around, some are not. My guess is that I could use different much darker runway textures that may be snow-free if I'm lucky, but they would look very different from a real-life textures. It's a lottery.

Any progress on that? I want to modify or add some sounds to send more low-end to my DIY shakers on touchdown etc. but can't find a way to do that...

I like your optimism 🙂 Yes, once you download the file, there is nothing preventing you from using it forever thereafter. No registration or unlock code that can expire or stop working etc. if that's what you mean.

Of course, I understand the convenience, that's why it's there 🙂 That's why I notified here about it. I know some people only buy from the marketplace, and I understand the appeal. I thought so too: last time with CYKZ it took more than 1.5 months since my release to get to the marketplace, and I was lucky enough not to be needing to to any modifications based on QA feedback. I submitted CYOW around April 14th. It's much more complicated project, so I expected QA issues and resubmitting, maybe more than once. This time I wasn't given any ETAs and then when I released 1.2 I re-uploaded the image to MS and I asked for ETA again, it was like "Oh, yes, it's targeted for release in 3 days, barring any stopping QA issues. We'll try to patch in 1.2 version quickly". And then they re-ingested 1.2 and QA cleared it and released literally within 3 days from my 1.2 release. Totally unexpected. Lightning fast release, great job MS/Asobo! Still it's about 3 weeks from uploading the initial release for the queue. So even if I'm very lucky with any future updates, they will realistically be 3-4 weeks behind in the marketplace. Which could be a big deal, if MSFS update breaks something seriously and something needs to be changed ASAP.

My CYOW Ottawa International 1.2 is has been released in MSFS in-game Marketplace. If you were holding out until you can conveniently buy it right inside the sim - wait no more, you can do it now. You would still get updates earlier if you buy it on my website, and I would not have to pay sales commission 🙂 But of course I understand people that prefer the convenience of keeping everything under one roof.

I don't know what you just said LOL

I think there is a much better method that should work: 1. In recent Windows 10 you can specify audio device PER APP. Like this. 2. You can use free Voicemeeter Banana mixer to create/use a separate virtual audio device for P2ATC app. It has built-in EQ. Just cut lows and highs to the max and boost mids and it should emulate radio spectrum. It won't affect main sound or FSFS sound then, coming out on default audio device. 3. I believe Pilot2ATC has a setting for "Radio background sound" for a suitable static file. Together EQ and static should be enough for very convincing radio sound. No need for any VST plugins. Needs to be tested as latency can become an issue, if it slows down the main audio output, but latency should be lower than using VST plugins anyway. Also, if using chatter files, EQ should not affect them much, as those frequencies are already absent. If it does - you cut too much!

Thanks. I haven't made a decision about what to do next. Depends on CYOW sales and what other developers are doing...

Thanks! Not that I know of. Look at the topic, watch there for any fixes reported. This can happen randomly everywhere, where the airport is in a photogrammetry region. But it only happens to some rare people. Most are just fine. Thanks. I'm taking requests and creating a list to consider when I get to that...

Thanks! LOL, I know that of course, I was so tired finalizing and testing the update that I made the stupid typo... 🤦‍♂️ That sounds like you're suffering from a known issue that can happen in the runways in a photogrammetry areas. That's not connected to my scenery or the update actually. see this topic: https://forums.flightsimulator.com/t/runway-tears-terrain-issues-in-photogrammetry-areas/324479 I have one other person having this issue, and you may also have it in default CYOW. Maybe try deleting and clearing your cache, disabling photogrammetry, reloading, and then enabling it again. Sometimes MSFS has those misaligned terrain issues. See the topic.

[UPDATE RELEASE v1.2] I’ve just released an update, including these new features: Ottawa Flying Club - detailed building models, including 2 open hangars with starting points “Ornge” medical hangar and area Updated signs and taxiway lighting Full fencing around the airport for increased realism Bridge over the highway that you can taxi on (a bit bumpy, so go slow) Express Air hangar Updated OFC starting points, run up area Deicing pad update with glowing matrix displays and 3 new buildings Sander Geophysics building Several other new buildings around the airport 2 Spherical radar structures at the edges of the airport Added ILS antenna with antenna building, DME antenna, several antenna masts Redefined ILS to work with aircrafts that support automated tuning, placed ILS and DME locations precisely at their real world visual coordinates Several new roadside lighted advertising billboards at their true locations (see if you can spot an Easter Egg) Fixed scaling problem with the steel bird sculptures appearing too near before this update Planted/extended some forest to mask unfixable ugly aerial photo edges near runway ends Many additional small adjustments in object placement, aprons, painted lines, parking areas, models etc. I’m sure I forgot something, there is too much to list. Here are some screenshots highlighting the new features: If you already bought this scenery on my website, then to update, log in and go to “My orders”.

You're welcome. And thank you for bringing this issue to my attention, despite the unpleasantness 🙂 Everyone is better off with things working properly. Let's hope that either Asobo fixes the bug or all developers learn to work around it. Thsnks, I truly appreciate your support!

Yes, the next update I'm releasing will have this fix.

Let me unpack this: Yes, it's the MSFS bug, in terms of that the expected behavior is whatever is not erased and redefined in the custom scenery, should remain working. In terms of ILS it's not behaving this way, as we all know now. It should be fixed by Asobo, but it's in the long line of other bugs... Yes, I have an inside track to Asobo, of sorts: a closed Third Party Developer's forum which I have access to because of an approved Microsoft Flight Simulator Partner status. I posted about this issue there yesterday with all details I had at that point. 3 hours ago I got a reply from one of the Asobo developers, saying "Thanks for the report, I’ll talk to my colleagues in charge of cockpits/instruments to see where the issue could be coming from." Now that I figured out the issue I posted the update with details - basically the same text I posted above. I would not get my hopes up, because there are literally hundreds of bugs and issues that are more urgent and have not been fixed yet. They have a lot on their plate and doing a great job, but there's a lot to do yet. You can see the developer snapshot to see what they are working on. But they do fix a lot of bugs as well, so let's hope for the best. CYOW is released through my website, and will also be released through the MSFS Marketplace, it's already in the queue since I released the first version. But it takes quite a long time until an airport clears the queue and goes through QA, and then if any changes are requested goes through the second time. It hasn't been ingested for testing yet, and I don't have any ETAs, but I know it's going to take a while. So everybody can get my scenery on my website the moment it's ready, possibly a couple of months before MSFS Marketplace release. Same applies for any updates: whoever buys at my website gets email notification of an update immediately, but it may again take a couple of months for MSFS Marketplace. I will be releasing the second update soon, while MSFS Marketplace doesn't have the initial release yet, and won't have for a while.

Good news everybody! I'm happy to report that the ILS database issue is now fixed! So, from what I can understand, this is what the issue is: 1. If in my airport I chose NOT to delete/override default ILS, but chose to delete and redefine the default runways, the ILSs work in manual mode but are not in the airplane database and auto-tuning doesn't work. 2. The utility from FSDeveloper.com I used to extract default airport XML to build on, gave me ILS in separate XML tags. I don't know if it's the correct representation of the default data or the utility has a bug, but ILS are defined separately from runways. I used this code to try to fix the bug, and enabled the flag to erase default ILS. It opened in Scenery Editor and complied fine, without errors and ILS worked in manual mode, but not with auto-tuning. <Ils lon="-75.64169" lat="45.32659" alt="112.776" frequency="109.500" magvar="13.600" range="50017.000" backCourse="TRUE" heading="70.996" width="4.4" ident="IOW" name="ILS RW07"> <GlideSlope lon="-75.66687" lat="45.31388" alt="112.776" range="50017.000" pitch="3.000" /> </Ils> <Ils lon="-75.69139" lat="45.3297" alt="111.861" frequency="110.300" magvar="13.600" range="50017.000" backCourse="TRUE" heading="319.984" width="3.7" ident="IRP" name="ILS RW32"> <GlideSlope lon="-75.65884" lat="45.31116" alt="111.861" range="50017.000" pitch="3.000" /> </Ils> 2. Searching for the source of the problem, I decided to define ILS within runway definition in Scenery Editor. I copied the values from the ILS tags above. If failed to compiled with XML errors at first, but after I manually edited XML and removed the original XML ILS tags, it compiled OK and looks like it has solved the issue. So the runway code now has ILS definition, instead of separate ILS tags. <Runway groupIndex="1889" lat="45.31890000000000" lon="-75.67055999999999" alt="108.25400000000000" heading="126.38400268554688" length="3052.65502929687500" width="62.42399978637695" patternAltitude="304.79998779296875" surface="{2E0DE83F-B79A-4435-905C-DCBBEAC55C59}" transparent="FALSE" number="14" designator="NONE" primaryLanding="TRUE" primaryTakeoff="TRUE" primaryPattern="LEFT" secondaryLanding="TRUE" secondaryTakeoff="TRUE" secondaryPattern="LEFT" primaryMarkingBias="40.00000000000000" secondaryMarkingBias="40.00000000000000" groundMerging="TRUE" excludeVegetationAround="TRUE"> <RunwayDeformation alt="106.985001" ratio="0.000000"/> <RunwayDeformation alt="111.862000" ratio="1.000000"/> <Coloration red="150" green="150" blue="150" alpha="255" override="TRUE"/> <Markings edges="FALSE" threshold="FALSE" alternateThreshold="FALSE" fixedDistance="FALSE" alternateFixedDistance="FALSE" touchdown="FALSE" alternateTouchdown="FALSE" dashes="FALSE" ident="TRUE" leadingZeroIdent="TRUE" precision="FALSE" alternatePrecision="FALSE" edgePavement="FALSE" singleEnd="FALSE" primaryClosed="FALSE" secondaryClosed="FALSE" primaryStol="FALSE" secondaryStol="FALSE" noThresholdEndArrows="TRUE"/> <Lights center="NONE" edge="HIGH"/> <BlastPad end="PRIMARY" surface="{00000000-0000-0000-0000-000000000000}" length="42.000000"/> <BlastPad end="SECONDARY" surface="{00000000-0000-0000-0000-000000000000}" length="42.000000"/> <ApproachLights end="PRIMARY" system="MALSF" strobes="215" endLights="TRUE" touchdown="FALSE" snapToGround="FALSE" reil="FALSE" offset="30.480000" spacing="30.400000" slope="0.000000"/> <ApproachLights end="SECONDARY" system="MALSF" strobes="215" endLights="TRUE" touchdown="FALSE" snapToGround="FALSE" reil="FALSE" offset="30.480000" spacing="30.400000" slope="0.000000"/> <Vasi end="PRIMARY" side="RIGHT" type="PAPI4" biasX="43.974037" biasZ="1138.949829" spacing="0.000000" pitch="3.000000"/> <Vasi end="SECONDARY" side="LEFT" type="PAPI4" biasX="43.316002" biasZ="1111.322998" spacing="0.000000" pitch="3.000000"/> <Ils lat="45.32988748830926" lon="-75.69175727173698" alt="108.63101788237691" end="SECONDARY" range="50017.00000000000000" ident="IRP" magvar="13.600000" heading="319.98400878906250" frequency="110.30000000000000" width="3.700000" name="ILS RW32" backCourse="TRUE"> <Dme lat="45.31300583464861" lon="-75.65916143891083" alt="108.29135638941079" range="50017.00000000000000"/> <GlideSlope lat="45.31300974285141" lon="-75.65914499311610" alt="108.29490873403847" pitch="3.000000" range="50017.00000000000000"/> </Ils> <RunwayStart end="PRIMARY" lat="45.32686996459960" lon="-75.68593597412109" alt="108.25400000000000" heading="126.38400268554688"/> <RunwayStart end="SECONDARY" lat="45.31092834472660" lon="-75.65517425537109" alt="108.25400000000000" heading="306.38400268554688"/> </Runway> Conclusion: One would assume that not erasing the default ILS would leave it functional, but it would not. Manual tuning functionality is retained, while it disappears from airplane databases and auto-tune doesn't work. The workaround is to erase default ILS and redefine it in Runway definitions (and not as a separate ILS tags! That was the tricky part in my case.) - apparently then it works both in manual and auto-tune mode. I will test further, but that's what it looks like so far. This should wither be reflected in documentation, or fixed in the SDK.

Thank you. Just to add about the issue, I have not just tried (and read the linked post thoroughly, of course), I'm actively pursuing it. The issue is there and there should be a way to work around that bug. I found one more thing that could affect it, and I almost got to the testing phase, but Scenery Editor crashed on me again. So will have to redo and test again. I don't know why you would recite your whole original post again. Contrary to what you think of me, I did read not only your all posts in this topic, but all of the sources you quoted. And if I had specific questions, it means that those sources were not specific enough for me, i.e. on the basis of what was there I seem to be doing everything properly, and the issue is still there. Eventually I read all of those topic, beginning to end, and still no clarification on why it doesn't work in my case. Perhaps because you are not a scenery developer yourself, you assume that reading those would immediately solve the issue, which is easy to fix, and I somehow just arrogantly refuse to read. Not so. I genuinely had questions as this is is decidedly weird and contrary to SDK documentation. I wasn't sure what else could I possibly try that can fix this MSFS bug. But I'm still working on it, and hope to fix it soon. I found one more thing I can try.

Thanks. I'll watch both and will contact Aerosoft with questions. I appreciate your input. Even if the video doesn't answer my questions, from what I see on it right away, it's nice to see the workflow of other developers, such videos didn't exist apparently, just the basic tutorials which are not useful to me really. This is more in-depth.

Thanks, I truly intend to!

Here's a freshly done deicing area:

Thank you, sincerely. And I'm actually very responsive to healthy criticism, as long as it's polite - many of the update features are due to that. The moment someone said to me that the bridge is missing, I found a way to implement that 🙂 When someone said that default MSFS runways do not look like Canadian runways due to lack of striped markings - guess what? They now do in my scenery, due to many hours of trial and error. When someone said GA area (Ottawa Flying Club) was not detailed, I got in touch with them and three members had sent me detailed photos, some of which were done specifically at my request. So now it starting to look like the photos below. I'm actually quite humble, as I'm trying to compete with some giants - a companies that have many people working full-time for months on their sceneries. I'm trying to produce something that rivals that quality, and sometimes even surpasses it. It's not a small thing to attempt, and I have to be humble about it, considering who are the other players. And I haven't forgotten about the area around it either:

OK, I guess I will have to write about this again. I'm sorry, but what's the way "I treated Noel"? You must have missed something. He was demanding things of me, accusing me that I and others like me don't put ILS because "I don't care" when I had no idea about this bug - and didn't refuse to check the issue at all. I did say I will check into it, asked him about specific XML lines and what do I have to do - but instead of factual discussion he accused me that I haven't immediately read and digested 3 long forum topics on a Saturday morning, and preferred personal insults to polite discussion. And as you see I'm trying to find a workaround for the MSFS bug, which is not actually my responsibility at all - because I didn't do anything wrong, as other developers with this issue - it's a MSFS bug, plain and simple. Really. I did check into it. He repeated "I refuse to buy" in a threatening and aggressive tone three times in a row in three separate replies within an hour. Does that seem polite conversation to you? I did say immediately that I will check the issue, said I have no problem with factual side of what he's saying, but I only have a problem with his tone and accusations. It's possible I could have misread his tone I guess, these things happen, but about 4 people here has agreed about his aggressive tone, so nope, he was impolite. As a matter of fact I have addressed every single person who suggested a feature or noticed an issue or said anything else to me. Every single one through all channels. I solved CTD issues (due to another scenery) for 3 people. There was absolutely nothing bad I said to him, except that if I would talk to someone in person like he talked to me, I would feel I needed to to apologize. He didn't of course, but that's his choice, I'm not the one to demand anything of others - he's more into that I think 🙂 I have absolutely nothing to apologize for. I never said he's factually wrong. He actually was partially - in the fact that he accuses developers of this bug, when it's not connected to developers at all. It's an undocumented MSFS bug even according to his sources, so his accusations were comically misplaced. I was polite, and if he was not as aggressive and pushy, I would have thanked him for pointing out the issue. Instead it was personal insults from him, but hey - it's the Internet, things happen. Now, I don't even say that he owes me an apology - this is too trivial matter to demand apologies and make a large scene about it. But neither do I, as I was perfectly polite in response to his accusations. It's actually very strange that you can read my words and say about "bad treatment". I'm puzzled. Anyway, please let's all try to discuss the scenery issues here, not personal issues. As for the bug - if there is a workaround I can implement, I will. But I actually did everything that is supposedly a workaround, and it did not fix the problem. I defined runways, and redefined ILS, and freqs are still not there. It's a MSFS bug, not my scenery. I posted in Asobo's closed developer forum, let's see if they can respond.