tkyler

No worries...if developers gracefully accept that we're all probably equally capable and creative, but only differ in what we get around to implementing for all sorts of diverse reasons.....time, market, resources, our own limited experiences....who knows... and not some kind of measure of who's smarter, then we all win. Your 'snapping' flap controls with FLAP axis are in place for the next update -TomK

For the early-birds https://forums.x-pilot.com/forums/topic/24825-toga-simulations-mu2-version-20-paint-kit-rc1/

RC1: Paint Kit includes 4 Photoshop files and *.fbx file of "paintable surfaces" for import into 3D programs for painting purposes only. 3D mesh is property of TOGA Sim and not to be used for anything other than personal livery painting and is not to be distributed or used for any other purpose. While the docs section for liveries are sparse at the moment, there is a brief graphical of what each exterior object contains. RC2: Fixed UVs for tip tank Fasteners. new *.fbx. All other files same as RC1. http://togasim.com/mu2docs/supplements/paint_kit.html TOGAsimMU-2_Paint_Kit_RC2.zip

FYI, This is a tougher geometry to paint than most are used to, especially the tip tanks. The 3D was optimized for UV space, not ease of painting. If you look at the C-FRWK exterior_5_ALB tip tank stripes...you'll see what I mean. Its for this reason I provide the *.FBX file for import in to Blender/Substance. My preferred technique is to use Blender (import the FBX) and use "projected closed bezier curves" via the "knife project" tool to cut the stripes and patterns into the 3D mesh itself mesh. These resultant 'graphics meshes' are then rapidly baked into "graphics masks" that you can overlay on the UV for tracing with a pen tool.. or bring into Substance as a mask.

The paint kit is not officially posted...because I want to add more instructions; however, paint kits are "extra" and come with no guarantee of quality :P.....so I can post it the way it is if you like.....because most livery painters are used to the "mess" of layers, and assets and can usually make sense out of it anyhow. Anybody interested? Once I get all the initial bugs and hardware settled, I'll also get that paint kit cleaned up a bit for future folks. If anybody is willing to take it as it is now, let me know and I'll get it uploaded as a "beta" version of the paint kit The paint kit is 4 photoshop files, plus 5 additional "mask image" pngs and a *.fbx file of all the paintable surfaces that can be imported into blender of Substance.

baro command implemnted, plus NEG flag

Thx. its already been implemented and indeed I use my "lift levers" command as the "command" to jump the gate. -TomK

You are definitely not doing anything wrong. The TPE-331 sim in XPlane is relatively generic. Getting accurate numbers out of the engine for X-Plane is easily a multi-month affair of nothing but flight testing and wrangling with X-Plane to hopefully get close. Once we get the interface and operational kinks worked out, we will look at improving performance numbers. I suspect before its all over, I will have completely overriden X-Plane's engine model.

right. in the new setup, EXT will basically be ON. "EXTended and illuminated" OFF (as labled...not the datarefs sense) is extended by not-illuminated. and OFF (in the dataref sense) will align with RET (RETracted and OFF).

so with the relabeling....and now that Im' testing it. I find it a bit awkward to have an "extension" command. I'm inclined to use the default commands to "extend and illuminate" and "extinguish and retract"...and just use the mouse manipulator to move the switches to the OFF position, as in my experiences in the Moo..its a pretty rare position to use. any objections or thoughts?

I would agree with that. no telling where I got that..probably a photo from someone else's "remodled Moo"....but its that way in the manual for sure. I'll adjust. Good catch! But I do find it a bit weird to pull the switches "back" to make the lights "extend forward" Gonna get some comments on this I think...but we do have the documentation. -TomK

So looking at these:

So I'm thinking the default commands for the OFF and ON..and custom for the extension. Executing the commmands will "move the switches" and the code will run based on switch position (and power states)

The default commands don't account for the extension...only the off/on states. so I'm inclined to go custom all the way, however, I could use the default commands for the OFF/ON and provide custom for the extension? thoughts?

I actually tried early on, but wasn't happy with either the sound samples I had....nor the hardware handling till last night The new throttle mappings will come out at the next update. With the implementation of the "TBM-style" throttle option, this will make implementing those sound much easier across differing configurations. So really its a matter of getting just the right samples...and once I have those, putting those sounds in is a 30 minute affair...at which point we can get it out to you guys. So yes...definitely on a short todo list. -TomK

I'll probalby do a performance pass at some point after "casual operation" stabilizes. The acf model and airfoils, while refined, still has some old roots and needs to be "flight tested" proper at some point. I've learned quite a bit about performance since the early days of my XP work. -Tomk

There were a lot of holes in the landing light controls....I wired them up to their respective busses, including the extension motor..so the whole external lighting just got revamped. I'm putting in commands for those landing lights now.

Convenient...just finished up the landing lights even as I type. I'll create the commands for those right now. Regarding the hardware mapping to throttles 1/2.....agree this is fraught with potential pitfalls atm, the next update will map to throttles 3/4 and hopefully solve all your problems. There has been some "kickback" from some folks about reassigning throttles, but X-Plane (for those unawares) has a great joystick profile mangagement capability for this very reason. So, you should just be able to assign the throttles once for the MU2 and it will load with the MU2 when you set it up that way.

I do like that idea...worth a try for sure.

I'm posting this all over so folks know. Major hardware binding change coming in the next update. should simplify things greatly. Bindings will be to throttle 3/4 for dual throttles, no response curves needed... which fixes a ton of issues because 1/2 are hardwired to internal Laminar code that I previously had to fight with and users usually got caught in the middle. -TomK

Understood...I'm the oddball here with my trackball.....for those who remember the "inverted mouse" issue of the IXEG. While I don't officially sanction it...you can adjust this Ok..you didn't hear this from me...because X-Aviation installers are picky about modified files...but less so about OBJ files. *cough *cough. If you happen to poke around the objects/cockpit_3D folder... _OEM and _GNS suffix files (2 files cause )_GLASS doesn't have it)..and maybe search for "alt_set_knob"...and maybe change a 5 to something higher...it might get you by until TOGAsim grows a brain... I'd welcome a "practical number" consensus -TomK

FYI XST, I am changing the hardware configuration for the next update......no reponse curves needed....BUT it will operate exactly the same as it does for you now with the response curves. FYI.. So easier setup, same operation.

This is understandable. and from your perspective it may make sense; however, we have many users who are quite into accurate simulation and its very common to have X-Plane's systems simulations, datarefs and functions "break down" as we begin to simulate more obscure and fringe operating modes. Unless you've tried to simulate an aircraft as deep, its hard to convey and I won't try. Trust me, we want to use standard functions...we really do. I'm very keen on cockpit building thorugh and worked with Rob Archer to build his 737 sim so I'm on your side. https://www.pjrc.com/737-300-flightsim/ Please pardon me if it takes some back and forth between us for me to fully understand your needs and undestand exactly what it is your trying to do and go about it. For example, while I can't recall what the flap ratio dataref does in V2...I know that the flap deflection angles are provided....so depending on how you go about building your cockpit, you may take a different approach. For example, if I'm programming my own Arduino, then I don't need the ratio datarefs, I have other day I could use. So the trick for you and I is to make sure I get you the data you need for your approach. So are you asking for 'sim/cockpit2/controls/flap_ratio' to work? I can look into that, but unsure because I had to override the flaps to get realistic behavior for Version 2. Version 1 was simplified greatly. If that doesn't work for you, perhaps I can implement another option. -TomK

should be in next update. Just got it working last night. -TomK