Black-Talon

Just wanted to chime in to say that this is perfect. Match's exactly what stock should be. I've been thinking something like this should be made for quite awhile (and apparently missed yours previously). Don't get me wrong, NavyFish's Docking Port Alignment Indicator is fantastic, but not stock enough in comparison. And I love the feel of Kitoban's Enhanced NavBall, this adds to that perfectly. In fact, I would absolutely love seeing the two together as a single mod. It's a perfect fit for each other and for the stock game.

This ... the plane geekery in here .. I'm in awe. ...and drooling a little. Well done. Excited to try it soon!

You seem upset - I meant no ill will. I did mention in my post. Sorry.

@ferram - thanks for the thoughts. I agree, I've come to terms with the "FAR (and probably NEAR as well) are balanced, but different from the stock game" and really enjoy it, but I wanted to understand more. @rynak - thank you for the suggestion. PS - I think you read a little too quickly - I've used KIDS quite a bit ;-) <edited to add the following> I particularly agree with your argument (that I read regularly) that if NEAR/FAR were stock, we never would've complained. The stock physics ARE hard. Man...the number of rockets I've had sideways and then into the ground...we learned to build and fly in that world and loved it. Realistic aerodynamics wouldn't make that learning curve harder...if anything it would make a lot of things more understandable (and planes feel less ridiculous - note again that no one can make a plane until they figure out the right way to use the center of lift and center of mass markers...but the forum isn't overwhelmed with rage on that).

As always, impressed with your work. I'm confident you've thought about this, so I'm curious to hear more about it... What if drag was increased (artificially) across the board but this model was used? I ask because: 1 - The stock atmosphere is so draggy, but the feel of flight is sooo wrong - it isn't the drag that's messing up the feel 2 - There is always this concern about how this becomes "cheaty" because of the lowered Delta-V requirements (is an alternative/combination option to extend the thickness of the atmosphere?) 3 - The stock engines are so overpowered for a real atmosphere that this cheaty feel is exaggerated (particularly with the jet engines) I mean, I've gotten over it, it'd be neat (as long as we're already bending the rules of reality) if we could get real air dynamics and feel of flight without the feel of cheaty (in a single Mod - and to be honest KIDS never felt quite right to me). I realize that this still becomes a judgement call ... but a shift towards more drag, or thicker atmosphere, to compensate doesn't seem too crazy in my own head (isn't this what RSS does?). What have your thoughts been in this area?

Well done Chris. Many times I've tried to come up with my own rebalancing tweaks. From what I've seen so far you've done a good job of what I always strived for... not making it easier (I always errored on making it harder) to achieve, fixing little mistakes, diversifying the part options, and standardizing the available parts to at least make sense when compared to all the options to do the same task. I've learned the hard way how hard it is to do, nice work. My only suggestion (and I'm saying this without having tried it yet), would be that you consider breaking up the updates into categories or type such that it's easier for someone to remove the type of changes they don't appreciate. Something like a separate config file which groups up all the changes of a particular type: 1. Cosmetic - improves look 2. Tweaks - changes functionality but arguably doesn't change game play 3. Balance I - changes balance of parts (without exceeding limits of stock parts) - would mostly contain nerfs to out of balance parts 4. Balance II - changes balance of parts to make sense but may exceed stock limits - increased mass but also increased ISP to values above any similar stock engine might go here

I haven't tried any gullwings, but I have had trouble with a few firespitter parts in the past that caused a "pulls to one side as soon as it is airborne" issue. Two things ended up making a difference for me... 1. I discovered that some parts caused my CoL to be off-center for unknown reasons. I narrowed this down to specific parts and in the end removed their lift characteristics. 2. Firespitters control surfaces and special lift cases were good potential problems from my perspective when using FAR, so in my install I removed those modules with ModuleManager. While this might not be your problem at all (I wasn't quite following about your CoL being ahead of your CoM ... but you may have mean Trust vector), and I didn't do sufficient testing of my changes, I can say that my instant rolling condition was fixed when I made the above changes. Perhaps this will give you some clues or ideas to try. -Talon

Sorry for the off-topic comment, but I'm similarly anticipating this. I love seeing the mods exciting people to create, and the creations driving new ideas in the mods. My giddy-engineer gets a triple dose as I create my world in KSP, debug and dream mods, and read and watch the rest of you. Thanks for the excitement!

Ferram, I've wondered for a long time if there is a way to draw the lift vector and center of gravity while in flight. Knew you'd know, do you do anything like that for debugging? Or is this one of those things mentioned too many times?

Your work still looks amazing! I was giving the Sopwith Camel a spin with FAR (and using the FAR version of the example plane in 6.1.1) and couldn't seem to manage a level take-off. Eventually realized that the lift wasn't centered causing a roll as soon as enough lift was generated. Narrowed it down to the FS4WC Biplane Wing Center. In stock the lift on that part is correctly centered. With FAR, something seems to cause the lift to be very off-center. Thought you'd like to know. Let me know if you'd like any pictures, video, logs, or a tester for this, or other FAR + FS, issue(s). Thanks again for the great planes! They're a ton of fun! -Talon

Right, I knew that. That helps you find out what a particular part's loaded settings are. And that's nice. But in order to understand what all the changes being made by module manager are you'd need to know ahead of time what parts were being modified and what their stock values were in order to look them up in game. This is possible to do but requires opening up all the config files. That's A LOT of config files and A LOT of manually comparing files in order to understand all the changes being made. What I'm thinking about making is something that allows you to quickly see all the changes ModuleManager has made to your parts. Ideally this would point out places where multiple changes are being made to the same part (potentially by separate mods, potentially conflicting). But much more importantly, answering the question, "What changes have been made to the stock parts anyway!?" Without loading up all the MM Configs AND all the part configs to see what was changed to what.

I've been thinking for awhile that it would be really nice if there was a utility that worked with Module Manager to do a few things with MM configs: Creates a list/csv of changes applied by MM: [PartName][Key][stockValue][NewValue] - ideally this would use a shared parsing engine so it could be used to test if your configs are working without loading the game An "export configs from the in game database" in game - I don't have a great reason "why" anyone would want this - but the idea is that actual part configs could be written out to disk that include all loaded ModuleManager config tweaks - perhaps then someone who doesn't want to run ModuleManager DLL could go back to the old days of overwriting stock config files - or at least an easy diff between files could show you the changes (getting you a poor man's version of #1) (bonus)Once I dream of a world with these things it feels obvious that there should be a reverse option to take a modified-from-stock config file and create a ModuleManager config that would correctly modify a stock config to the modified config (used in order to easily create/distribute your config changes to others). OR of course an easy part editor, spreadsheet driven, part editor that drives the creation of MM configs for distribution would be fun. So #1 at least has always seemed super useful. Especially now that so many modders are in fact using the awesomeness of ModuleManager but without a lot of work you're never quite sure what has been changed (I always used to diff files to see updates, now I can't as easily). Does something like that already exist by chance? Tempted to make something myself but I know my time limits will likely prevent me.

Awesome! And so quickly! Thank you!Could I get some clarification on what to expect with Jet engines? And SRBs? Based on your commentary earlier in the thread I was a little confused by the results I was having with the TurboJet. I haven't tested SRB but would like to.

Ok, a couple tests in and I've confirmed my other point of confusion. I don't think I understand what "Extend Curve to Zero Isp" means, perhaps you could help me see where/when this would fit. My assumption is that ISP already scales based on atmospheric pressure and that an engine that had 300 ISP at sea level would have less than 300 at higher pressures if this option was on. And would hold steady at 300 for higher pressures when the option is off. I'd then presume that behavior between 0 and 1 atmospheric pressure would remain the same. And lastly I presume (perhaps wrongly) that atmospheric pressure is 1 at kerbin sea level and goes down to zero as you climb in altitude. I don't know any places on Kerbin where I could experience pressure greater than 1? Thus on Kerbin this setting wouldn't effect my ISP? My flight with LV-T30's shows my ISP falling as I take off from KSP...I'd assume it would raise? At 2,500 m my LV-T30's have an ISP of ~15 and since I'm not currently using the thrust scaling that means my fuel just blows out of the engine. Kinda neat to see it happen in a "wow, isp actually works the way I'd think in a very dramatic fashion!" sorta way. But unfortunately I'm very confused on why this is the case. Since I actually have no idea what is going on with pressure I'm attaching a barometer and running another test... data points are best effort... On the pad - LV-T30 is at 121.4 isp - Pressure is 0.982 1,000 m - 84 isp - 0.8154 2,000 m - 27 isp - 0.643 When I don't have the "Extend to Zero" setting on I get the following approximate data points pad - 122.2 - 0.9818 1,000 m - 146.2 - 0.8154 2,000 m - 189.7 - 0.6641 So, I'm clearly not understanding something. Or ... does an atmospheric rated engine perform worse in vacuum and this setting is enforcing that? Or bug?

I might be missing some things but I'm experiencing some odd behavior on my first try of this mod (downloaded a few hours ago). I'm shooting for an experience where I use FAR (and deadly re-entry) but difficulty is equivalent (or marginally harder) than stock. With this goal I've chosen FAR to Stock KSP, Atmosphere Only. I like the idea of thrust scaling as well, but I see your thoughts on how this doesn't make much sense for atmosphere only. For now I'm trying to sort out what I actually would expect from that aspect. I just updated to 1.3.1 after the initial oddness and will continue to explore. Thus far I'm fairly certain this is impacting Jet Engines by mistake? Meanwhile, I think Jet Engines were overpowered in stock from my perspective? And FAR only makes them more overpowered? So ideally there should be a way to increase their difficulty to stock levels as well. I assume this problem will exist with the RAPIER engines if nothing else. Anyway, back to 1.3.1 to see if it fixes my other confusion points. I'm optimistic and excited that this is perfect for using FAR full time instead of only when I want to play with planes!

EXCITED! I finished writing this long post and then headed over to listen to some KerbalKon and the plans for .23. As you saw from my post I'm of course hoping that they'll announce a Joystick improvement...but on the inside I'm knowing they won't. So impressed and surprised to hear HarvesteR at 20:36 http://www.twitch.tv/ksptv/b/486870322 - "Good news on Joystick Axises as well! ..." I nearly fist pumped. =) But super excited!

Good catch. You are correct, that was a typo. Data from the 8th should have matched my notes that I posted a few days ago. When I changed the formatting of the text I made a mistake. I'm fixing the post now such that it matches the data in my original notes. Details below... Yes, in UJR I pull stick and throttle from the Thrustmaster Virtual Game Controller and assign it to vJoy. Once configured this works wonderfully! On the 9th I posted this about my experiences on the 8th: On the 13th I posted about my experiences on the 12th and compared it to the 8th in a new format. Doing so again without the typo would look like this: 12/12/2013 WinId#1 vJoy joy1 WinId#2 [none] WinId#3 [none] WinId#4 Pedals joy2 WinId#5 vThurst joy0 12/08/2013 WinId#1 vJoy joy2 WinId#2 [none] WinId#3 [none] WinId#4 Pedals joy1 WinId#5 vThrust joy0 With regard to "vJoy is not moving from one ID to another," in Windows this definitely has been proven to be the case. The Windows Joystick ID for vJoy does not change. However, "KSP may decide one day that vJoy is one ID[in my case, on the 8th it was ID 2], and one day that it is another[on the 12th it was ID 1]" is exactly what I am bothered so much about. With this being the case the following occurs almost every time I play KSP: Plug in joysticks to use in KSP Launch Joystick stoftware (UJR, TARGET) and quick test controls Launch KSP and get a ship to the launch pad Realize that the controls don't work Back out to the main menu and rebind the axises in setup (sometimes) Realize that KSP won't detect vJoy input for unknown reason and restart UJR, KSP, Windows until it works Once sticks are bound correctly, get back to playing and dread the next time I want to launch the game Steps 4-6 are what I've been describing as "frustrating," "annoying," a "nuisance," and an "inconvenience." And you are correct, these issues can be worked around. That's what I'm doing now and why I find so much value in UJR. UJR has made so many things possible for me with KSP. I'm really loving it! However, doing a find and replace in the config, or swapping out configs once I figure out what the new ID in KSP is (and restarting KSP to reload the config) is still just as frustrating, annoying, and inconvenient as my current method. I've been venting my frustration on this in your thread. :-/ And hoping someone might have determined a method to make the process of "make sure all references to sticks in the KSP config file are to the vjoy stick" more convenient. *fingers crossed* This is really encouraging to know. Perhaps Squad can get KSP working like those other setups! I did not know this. Agreed, I can do this easily if you think it'll help. Your bug report looks great though. It describes the issue I'm having well. I may add to it the "Why is this really annoying for Joystick users" to assist Squad in setting the priority of the bug. And I'll stay optimistic that this can be fixed in KSP by Squad.Thanks for the awesome utility and hearing out my pain points! -Talon PS - Yes, vJoy has been the "preferred device" the entire time I've been using vJoy. When I was originally setting it I wasn't sure what it did but hoped it might help with this ID changing stuff in KSP.

I wanted to quickly reply that 6.1 does fix my merge confusion. I was confused why the slider (and output) inverted when I set "Rests H." It no longer does this. Sadly, I had a frustrating day with the rest of it today. I don't have enough consistent information to be truly valuable (my software testing/dev background haunts me perhaps - I expect much more concrete conclusions than this). But if you want to hear my experiences and gut feelings thus far read on... 1. I currently don't believe that Target isn't making anything worse. I recently added it to the equation (when we were discussing all this a week or two ago I wasn't using it) and nothing new showed up. Only the old problems. I have regardless disabled it and continue to see the inconsistent KSP Joystick IDs. I also have always had problems with joystick recognition. 2. Today the Windows Joystick IDs correlated with the KSP/Unity IDs in a completely new way. I didn't really get to do the tests I wanted (or that you suggested). That said, today's notes on that seem to suggest that it isn't consistent: 12/12/2013 (Without TARGET) WinId#1 vJoy joy1 WinId#2 Joystick joy0 WinId#3 Throttle (KSP Can't Find this Joystick? Windows shows it working.) WinId#4 Pedals joy2 (With TARGET) - BTW, this got me to a place where I could play, but as you can see it's different than the other day. WinId#1 vJoy joy1 WinId#2 [none] WinId#3 [none] WinId#4 Pedals joy2 WinId#5 vThurst joy0 12/08/2013 WinId#1 vJoy joy2 WinId#2 [none] WinId#3 [none] WinId#4 Pedals joy1 WinId#5 vThrust joy0 3. A problem I haven't mentioned before plagued me to death today. Sometimes KSP just doesn't know about my Joystick. Today it couldn't find my physical throttle even though everything worked well in Windows. So eventually I enabled TARGET and it couldn't find vJoy. Rebooting didn't solve this. Uninstalling/Re-installing vJoy did. FWIW - the problem exhibits itself when I go to bind an axis in KSP, while KSP is waiting for stick movement I can move the stick (sometimes this means virtually moving the stick with QuickBind in UJR) and KSP detects nothing (the same movement shows correct axis movement in the Windows Controller properties). Even stranger: typically when this is happening, KSP will then recognize my mouse movement as a joystick axis and bind it (this put joy3 in the config, but was referencing my mouse for that axis). I know some of this sounds crazy but the part about the mouse binding as a Joystick Axis is something I am certain of. As is the changing KSP Joystick IDs. I've spent a stupid amount of time trying to figure out what the heck is wrong only to discover that moving my mouse throttles the craft up and down but nothing else does. The time spent and painfulness of this issue was new today. But the issues themselves I have seen many times. I usually just fiddle with it (restart KSP, restart UJR, reboot, etc) until it starts working. Today my typical fiddling didn't help and I became sad. :-p So that was today. It sure doesn't look like a UJR problem. But thanks for hearing out my frustrations. :-) -Talon - *begging for better Unity support of joysticks*

I've been using your recent update of UJR to 6.0 and ADHD (2.1 I think) tonight, you've been busy! Some nice goodies in there! I'm a little thrown off by a couple of the changes (or perhaps bugs) with the new merge and "rests high/low" option. But the concepts are solid and I'll details of my confusion once I've got a handle on it. In the mean time, nice work as always!

Yes, I tab out (or run in Windowed mode when I'm testing) to switch profiles. And for KSP this isn't a big deal at all. I can see this being a problem for other games if profile switches are needed for them. Rarely am I switching from an atmospheric plane to a rocket, but when I do, tabbing out to switch flight profiles is easy enough for me. After further testing I completely agree that my earlier suggestions to handle Joystick ID changes would not help my issue. The root problem seems to be exactly what you've said, "KSP IDs jump around, but as I said I think that is because it labels sticks not as "stick number" but as "connected stick number" (ie it only counts connected sticks)." I've updated my previous posts with this new information. Unfortunately this creates a nuisance for me that I have to manually avoid by rebinding vJoy in KSP each time I launch. So far, I haven't found any predictability to the KSP/Unity IDs. And when they change, bindings will be wrong. I currently don't see any way that UJR, AHK, or vJoy could solve this for me. My primary case where I've seen this is where I have all controllers unplugged but vJoy installed. vJoy is WinJoystick ID#1 in this case. In KSP, vJoy can be bound to the proper axis controls and the config will show us that the KSPJoystick ID is 0. All axis IDs match up to those used in UJR. This all sounds very nice and makes sense. Unfortunately, when I plug in my stick, throttle, and pedals (and technically I then install a 2nd virtual Joystick which is done by Thrustmaster's TARGET software which unloads the Stick & Throttle controllers), I am left with: WinJoyID1 = vJoy (doesn't change) WinJoyID2 = none (was the stick but TARGET eliminates it from showing up in Windows and replaces it with a virtual joystick) WinJoyID3 = none (was the throttle) WinJoyID4 = Clubsport Pedals WinJoyID5 = Thrustmaster Virtual Game Controller With this setup in Windows, KSP considers vJoy to be Joystick ID 2. I can't make sense of this change from ID#0 to ID#2. Perhaps (and I have not tested this) the Unity/KSP joystick list is alphabetical? Which is the only way I can imagine that JoyID2 would relate to vJoy... KSP JoyID0 = Clubsport (did not confirm this is accurate) KSP JoyID1 = Thrustmaster (did not confirm this is accurate) KSP JoyID2 = vJoy (vJoy is definitely KSP JoyID 2) But whatever it is, I don't trust it and it seems to change depending on what I have plugged in when I play. I'm hoping for a Unity/KSP change in this area. I'll keep updating as I learn more! -Talon UPDATE: I quickly bound my Thustmaster and Clubsport controllers to an unused axis and after exiting the game I examined the config. The KSP/Unity Joystick IDs, in relation to the Windows Joystick IDs (in this exact specific setup) are: KSP JoyID0 = Thrustmaster Virtual Game Controller (WinJoyID5 - last installed, also last in Windows list) KSP JoyID1 = Clubsport Pedals (WinJoyID4) KSP JoyID2 = vJoy (WinJoyID1 - first installed, also first in Windows list) So now I'd speculate that perhaps the KSP/Unity Joystick IDs are a reversed list of Windows IDs?? Still untested, and still don't trust it.

Donated! I would LOVE to be able to do all this without the frustration of Test Mode. Plus I think that would make the likeliness that others would use it so much greater!! Thanks!

Soda, I think you're doing it just right! And I agree with evilC, despite the joystick axis binding reporting that it's bound to "Wingman Force 3D" it probably isn't. It's a very erratic behavior and never seems to be right. Did you try getting a plane on the runway and seeing if the controls were in fact bound correctly? Following exactly the method you're describing my setup works perfectly. As for manually putting the ID into the config, I did exactly that months ago but had to guess each ID before I found the right one. Now that evilC has pointed out JoyIDs it *should* be so much easier. [uPDATE: While this *should* allow manually setting the ID to be easier, the IDs shown in JoyID and those used by KSP/Unity are not related. This means I don't know which ID I would put in the config.] However, I seem to recall the same changing ID issues I describe in a previous post. And I wonder if the IDs even correlate in a predicable way? KSP is obviously using a zero based index of Joysticks (joy0) vs. what's shown in JoyIDs (starts with Id#1). And it just so happens that my settings.cfg shows the configured JoyID as 2 when JoyIDs shows vJoy as #1 and #3 ID is currently empty. Seems potentially misleading...I'd go with the binding plan you described. Now that I'm explaining this I'm wondering if perhaps part of the problem in KSP is that the IDs it's using are something it made up and that don't relate to windows joystick IDs correctly. This would cause the behavior of "changing joystick IDs" I described before EVEN when the Windows ID never changes...hmmm. I'll keep an eye on this and see what I can find out. UPDATE: Answers to questions above that reveal that there are in fact real issues - "And I wonder if the IDs even correlate in a predicable way?" - Windows Joystick IDs and KSP/Unity Joystick IDs do not correlate in a way I've determined. "I'm wondering if perhaps part of the problem in KSP is that the IDs it's using are something it made up and that don't relate to windows joystick IDs correctly." - This is indeed the situation, Windows Joystick IDs and KSP/Unity Joystick IDs do not correlate. KSP/Unity Joystick IDs change. This causes uncertain joystick axis bindings. "This would cause the behavior of 'changing joystick IDs' I described before EVEN when the Windows ID never changes...hmmm." - This speculation was correct. KSP/Unity Joystick IDs change when different joysticks are plugged in (even when the Windows Joystick IDs stay the same). This causes my previous bindings and mappings to be wrong and annoying to discover and correct. And thus, currently, I have no idea how to get rid of the inconvenience of discovering my bindings are wrong. I just double check my bindings before playing each time. In addition, this means that I don't know any reliable way to manually set they Joystick ID in the config since there is no way to know which ID should be used.

I finally had a chance to play with this further. You're right, the IDs rarely change. Much less than I thought. The problems I'd previously had basically had me not trusting it. Testing I see that it typically keeps the IDs the same. That said, they do change. I can't quite nail down the case where they change...but sometimes I plug in a controller and it'll bump one of the existing controllers down further in the list (as seen in JoyID). Luckily, with this utility it is much easier to figure out the new ID and correct my mappings. It would still be amazing for KSP and other games if UJR did something like Nuke describes by using the name or GUID to help follow a joystick when it happens to change IDs. It would be one less thing I'd have to double check. Update: Given that I've now learned that KSP does it's own ID mix'n'match I now doubt that this would help my issue. :-( Secondly, is there anyway UJR could assign the ID of vJoy so you knew it was also consistent? As you've discovered and leveraged yourself in your KSP config, as long as Windows Joystick ID stays the same, KSP will use virtual stick associated with the ID denoted in KSP's config (this is of course despite the name it displays in game). But my testing and experience shows this ID just doesn't always stay the same. Again, this is something I have to double check every time I play. Otherwise I rediscover how the joystick mapping menu is annoying to get to once you're already in game and your controls aren't mapped correctly. It makes for a sad first flight. :-( Update: Given that I've now learned that KSP does it's own ID mix'n'match I now doubt that this would help my issue. :-( That said, especially with JoyIDs everything is so much easier to get right if I take a peek before starting. Life is so much better now! I just have to use 3 or 4 utilities to get what I need. :-) Sharing one more great thing about this... now with a quick switch of the profile in UJR I can switch from flying rockets to flying planes and EASILY switch the rudder pedals from controlling roll (as preferred when in a rocket) to controlling yaw (which is obviously what you'd expect in a plane). This whole thread really just takes the Joystick + Throttle + Rudder situation in KSP to a usable level for me. And it's so gratifying to be taking off with a real joystick, using the throttle for a moon landing, and flipping toggle switches to raise or lower my landing struts!! I can't thank you enough! Update: After more testing I've discovered that Windows rarely changes the Joystick IDs. KSP/Unity on the other hand does not use Joystick IDs that correspond to the Windows IDs. And these Unity Joystick IDs DO change when joysticks are plugged in differently. I don't know of anything that could stop this from being annoying.

Everything is still working wonderfully! I am however curious what others have found as their preferred solutions to the Changing Joystick ID issue? To be clear I'm talking about... 1) KSP/Unity maps an axis by noting it's Joystick and Axis ID in the config. This would be fine except those Joystick IDs change depending on ... who knows ... but most likely order they were plugged in or initiated in a system boot. 2) UJR basically does this same thing by keeping note of the Joystick and Axis ID. So when I reboot I have to reconfigure UJR and then KSP before I can play. I've read a few ways to solve the various problems but thus far have stuck to *trying* to keep vJoy as ID 1 and getting KSP mappings tied to that. Then this makes it easy to just shift things around in UJR and I'm off and running. But it's pretty frustrating when it gets out of whack. I'm currently trying to get a setup working that has anywhere from 3 to 6 joysticks plugged in at any given time. It's semi-frequent that I'll unplug one which will throw off UJR. Thanks for your ideas, Talon

I was all geared up to do some serious debugging and data reporting BUT, far better, the 5.3 beta patch works awesome! I'll report more as I get using it (a little distracted at the moment) but, extremely grateful for the great utility and extremely responsive fix! Thank you!