tkyler

I will add that I myself prefer a bit longer startup as I enjoy the sights/sounds of the start process myself. Right now its hard coded and I can lower the 'starter strength' to slow it down a bit, which I probably will when I get back to the Moo engine tweaking...to make it more of an "average" start time of 40 - 50s, etc. -tk

The friction ratio mostly affects "free-spinning" unpowered behavior. Setting this value to chase some specific start time, may make the shutdown time unrealistic. Its been set to match shutdown times. I have noticed the faster start times; however, I have seen TPE engines start up fully in 20s, but also have seen them taken over a minute. I selected somewhere in the middle in 2.0.4, just because I felt like it. So while it may be faster in 2.1.0 than in 2.0.4, it doesn't mean its wrong or "more or less" realistic. It depends on battery level, temperature, engine state, age, etc....so the start up times are reasonable as is...for a good and fresh TPE engine. -tkyler

http://www.togasim.com/mu2docs_offline.zip the link you gave above....is that posted somewhere? if so (and its one of mine)...I need to correct it. -tkler

Nothing on my end, but XP12 is a different beast and could have changed "starter strength" effect. Note that I haven't gotten deep into the engine changes yet for XP12 and there have been some changes for sure........so there is still an "engine performance" pass yet to be made and that's when it will get addressed. All that said, start times are affected by battery type, temp and engine condition etc...but more than likely XP12 has changed some engine perf I have yet to evaluate. -tk

To those who have watched the livery demonstration video above. I've made some small changes to the paint kit FBX 3D model. You can download the changed kit via the link from the first post of this thread. I'm splitting the "Ext 3" object (with the tail) into 3 objects. Two "tail halves" and the rest of OBJ 3. So you'll see 3 "Ext 3" objects total in the outliner after importing the *.fbx model. Towards the end of the demo video, I show how the 'number 5' of the tail number did not come out as desired... and the reason the 'number 5' did not come out right was because of the way "cut through" works. When we unchecked the 'cut thru' option, those polygons on the leading edge of the rudder are occluded slightly and so were not cut. Now...by separating the tail into two halves, you can select each half independently and use the "cut thru" option, which will result in a much cleaner look of tail graphics. So...heads up / FYI -tkyler

@JohnyMcFace Liveries will be getting some love soon. I hope this helps others.

The manip placebo is not part of any vrconfig file "syntax specification", its part of the user-defined dataref name, which can be anything we want. Some manipulator types require two datarefs to complete their definition for two axes; however, in some cases, we only choose to use one of the axes and therefore the other axis is a 'placebo' and not used. In the early days of manipulators, a drag in a single direction was accomplished using world coordinates, but this created not so good side-effects for some camera angles. Laminar then introduced 'screen based' or pixel based drag manipulators, but these required X/Y coordinate information. So if you wanted to use a single axis "screen based" manipulator (for reliability), you had to supply two dataref values where one was essentially doing nothing (again..the placebo). That explains the placebo name, but not a solution. I too cannot exactly recall what the particulars of the VR config file are; however, I have noted this post and as we get closer to release, will review the settings with regards to VR. -tkyler

I've uploaded a demonstration video of some of my livery painting techniques, to show how you can use Blender to help create UV layouts for the livery painting. Hopefully this will make the process a bit less intimidating for some. -tkyler https://www.youtube.com/watch?v=kir6KFz8cg4

Yes....as far as I can tell. There's use of the phraseology in the maintenance manual of "turn battery key on (or connect external power)". The key essentially "connects the batteries to the busses", whereas the external power receptable also engergizes a relay that can connect the GPU power to the main busses also. Indeed there is a troubleshooting step in the maintenance manual for when connecting external power does not power the main busses, and the battery key switch does not factor in to those troubleshooting steps. As far as the torque gauges goes, they indicate 100% when unpowered. When connecting the GPU, which energizes the DC busses, they spring to life and 'indicate' I'm going to do a deeper dive into the electrical system at some point to try and get it as accurate as i can. These older analog wiring diagrams can be a challenge to interpret and take some time. Regarding the GPU toggle, I'll add that command (though I have no idea why I didn't when making the on/off commands. mind-blank apparently) -tk

thx for reporting. I concur that the illuminated indicators aren't there.....I don't recall touching those polygons at all, but they are clearly missing. It seems only the illuminated indicators are missing, but the button functionality is indeed intact, I can verify that. Again, thx for reporting. Already fixed. will report back asap on updating. -tkyler

This still smells of a shader issue to me. What is your graphics hardware and OS? The "reflector" object is intended to allow the rain effect to be see through transparent objects that are interior in nature, specifically the sunshades....so that is a good data point that changing that changes the output for you. I'm going to hit up Laminar to see if this has been reported elsewhere or are any known issues...but it would be nice to have your OS and graphics hardware info. Thx for reporting! -tk

Thx Manolo. We'd like that too when the time is right...and we do appreciate your feedback on it, that's exactly whats needed. We want it to be in the wild a little while longer to get a broad spectrum of use cases over a variety of flights/types and are working though some logistics on getting that out eventually. Thx again. TK

Doesn't really tell me everything. These objects specified for rain, are also the same ones specified for ice. The 172 has neither wiper effects or ice effects....and I can't speak to if the Q4XP does. It could be these shader for those effects, with your video card could be a strange combo. If you want to open the Q4XP....find out which object is set to "Rain Glass", then open that OBJ text file and look for the words "WIPER" and "THERMAL_source" at the top of that OBJ file....that would be a data point for debugging we would work with. TK

and your 4B_GNS and 5B_OEM also? I need to know if its all variants for you, or only specific ones. That's definitnely not a rendering order bug, thats something else. All variants work fine here on my end, I can't reproduce it. May have to punt this to Laminar. I'll shoot the screenshots up the chain.

I haven't see that myself yet. What variant are you using? and does it happen consistently (every time) and also across variants? -tk

I'll definitely be putting in something for sure. Again, step 1 is get my IXEG customers in the air in V12 and then the "fun stuff" will begin...like this ice and wing flex for the MU2. Note that not all product's ice effects may be the same though. Laminar's icing effect can only be applied to four channels. The MU2, having independent heating on the left/right windshields takes up two of those channels. I elected to use the 3rd channel for the 'minor accumulation' of ice on the side window, leaving only one channel left for whatever I may use it for (if at all) The thing about Laminar's icing effect is it has a "fading animation" effect, which is great for ice accumulation / slow melting animations. I'll probably have to go the tried and true "show/hide" route for the other exterior surfaces that can ice up. This method (depending on how its implemented) cannot fade in effects, so its a bit harsher, appearing / disappearing instantly for the most part. There are ways to mitigate that, but its not the same as Laminar's smooth fading effect. So the Diamond there, probably only having one icing channel for the windshield icing, leaves the other channels for the wings, whereas I don't on the MU2. So just be aware that because one product has the icing effect implemented in 'X' way, doesn't mean that others may. As devs, we're always trying to bend X-Plane's available tech to our projects. All that said, its important that you be able to look at the window and see ice accumulation...and I'll definitely strive to come up with something as best I can. -tkyler

I apologize I couldn't get to the engine stuff just yet....but there's lots of pressure to at least get these guys flying in XP12. Once that's done and folks can get a fix on some level at least....then I'm actually looking very forward to taking a breath...and start the refinement process...and indeed some fun stuffs. I'm really enjoying the work. -tk

Hey guys. Something came up about 10 days ago where I switched my focus to the MU2 very agressively (to the tune of multiple 12+ hour days). The result of this is the MU2 for V12 release is imminent. The time frame was aggressive enough that I could not get all of the outstanding items on my issues list into this V12 port, but did get about 80% of them done. That list of fixes and changes are now online here. These issues are in addition to the XP12 specific features like the rain and ice effects and all the new lighting. What did not yet get addressed are the engine stuffs, the EGT and FFs yet, those are the same as now for the moment. In addition XP12.05 has mismodeled the BETA reverse IMO......it can take up to several seconds to get reverse pitch after moving the levers into reverse. Laminar has said this is fixed in 12.06, but I haven't got that version in my hands yet so I can't verify if that is the case. If not, I will work with Laminar again to rectify this. So the plan now is to go back to the IXEG and get those customers flying in V12 asap. Going forward, I'll start looking to fine tune the engine model and performance, as well as add liveries and more fun items. If anybody is interested in making liveries, but wary of the paint kit complexity, let me know. I'm thinking about doing a video showing some advanced techniques for making liveries with Blender....but if there's no real demand, I probably won't. With the MU2 in V12...I can start to pace myself a bit more regularly and start adding more luxury features. ....and for those who are excited to see the ice effects on the windshield....good luck! I had trouble getting ice to form and spoke with Laminar about it and found its a pretty complex system. If the temp is too cold, then wet drops won't hit the window and freeze...if the wind is 'warm" that affects it also...and wind speed of course...and precip levels. X-plane, fortunately has a tool for simulating the ice for developers because getting ice to form takes just the right conditions and a fair amount of time, but the effect is in there -tkyler

I have a confession. I was approached about 10 days ago to participate in a short-notice endeavor (X-Plane related) that was tough to refuse and had me put the IXEG work on hold for this time frame....so this short delay in our original time estimate is squarely on my shoulders.....but I feel was the wiser decision for my continued work in X-Plane. I'm back on to the IXEG tomorrow. This side endeavor will become known sometime today I suspect. The good news (hint) is that completion of this endeavor will allow me to continue on the IXEG development right after the V12 port version comes out, and not have to detour back onto any other work....and there is a bit of an 'Easter Egg' in this endeavor that reveals the two projects we plan on working on in 2024. So we'll roll out the V12 port and I'll jump right back onto the FMS and other improvements planned for the remainder of the year. So this endeavor delays the V12 port, but moves forward the follow-on work. Those improvments (FMS, new nav data, beginnings of new 3D exterior) will take the better part of 2023 I'm sure, but we'll start that immedately after the V12 port release. As far as time frame for the V12 port now.... I can't say exactly. we always feel "close" because all the big stuff is out of the way. My todo list largely consists of finishing the interior texturing (rear galley), putting in the wing flex and squashing Jan's list of 'mostly small' issues, that's the list. I am dealing with 3 graduations of my kids this weekend (and family get-togethers).... and they will get my time to celebrate their achievements. I'd like to be done within 3 weeks, that's all I'll say. Will we be done in 3 weeks? I don't know. If not, I'll certainly be closer than I am today and still moving! -tkyler

yea, time for an avatar update, that's one's 14 years old....still into my early 40s at the time. Shows you how much I pay attention to that stuff...but don't want to be misleading -tk

well...you know what its SUPPOSED to stand for. I'm going to let out a bit of a secret here. The whole idea of "dated" will definitely apply as I continue..... I've mentioned wanting to do some additional projects...and no, I'm not going to spill any beans yet...not till the XP12 versions of the IXEG and MU2 are done. BUT....in doing additional projects, I'm collaborating with some other folks....and just so happens in one case, I'm collaborating with one other person....and in the other case, I'll be collaboration with TWO other people. ...and we're all over 50......SO...TOGA stands for: in case 1: Two Old Guys Aviation (simulation) in case 2: Three Old Guys Aviation (simulation) So that's the back story of where TOGA came from. It just so happens (lucky for us) to be associated with aviation TOGA, TOGA, TOGA..... -tkyler

I believe (speculating) the CSI knob employs a "light friction clutch". See the following video: Keep on eye on the copilot HSI in the very bottom right corner of the video when he connects bus power. You'll note both the CSI knob AND compass card move together when initially powered, but once the compass card synchronizes and stabilizes with the flux compass signal , the CSI knob then will not turn the compass card, only the CSI needle. This is the reason you use the +/- switch to adjust the HSI compass card when not operating in 'slaved' mode. There is no servo mechanism to adjust the CSI needle that I'm aware of on this HSI, it has to be moved with manual input.

Update.....apparently the latest XP12 will have new facilites for "bus tie" modeling....but since I've already custom coded my own, I have to figure out of Laminar's default will be sufficient...and if so, I'll have to carefully cut out my own bus code without breaking anything. I'm going to wait and see what XP12 bus tie feature holds before addressing this one.

@Graeme_77 Got this fixed! Also I noticed the manual fuel pump wasn't working either. That's been corrected also. -tkyler