Quiana

I figure I'll ask and see if any Win 10 folks have tried this. I know we had discussions before about issues between this application, Saitek, and Win 10. I can try it later when I get home but I've got a busy day today so I may not be able to verify if the bugs pre-1.1 are gone now.

TMS, they've already confirmed that consoles actually have a REQUIREMENT for achievements. They never wanted to put achievements in as they do also cause the exact opposite, causing a completionist to do them to get them done. The best rewards sometimes in a game like this is not the game patting you on the back, but your own sensation of joy when you complete something you've struggled at or thought 'I can do that too.' when you see someone else's work.

Also the CKAN database is actually built right off kerbalstuff, so, it only parses what's on that site. It won't do any other external links, either. The protection from a bad thing on there is the requirement for source code to be published and with the program, so you can do a comparison or virus scan it beforehand.

If not, then I'm sure a quick MM patch can add those swaps into the tanks, based on their dry volume and the mass of the appropriate fuels. If you need some aid, I can read up a bit and give some sample configs for the IS fuel swap module.

If I recall right, the reason it is this way is due to the wealth of information required to setup the parachutes. They are highly configurable, with good reason and need the extra space from a dedicated place to be displayed. Not only that, but you certainly do not want to accidently open all that information with a right-click on your chutes, or have to open the UI Window through each chute (though there is a symmetry toggle inside the GUI to setup symmetry partners).

Also you may want to actually update your MM to 2.6.5, rather than 2.6.3. It doesn't hurt to ensure it is up to date.

There is not enough reputation on the forum to really describe how wonderful your texturing on those models has gotten to. I remember when it first came out, they were impressive then, now they're just incredible. Looking forward to the 2.0 concepts as well, unless you're keeping those preview ideas to the development thread for the most part.

Quick question, call me a bit dense but if one wanted to remove the extra tag for Kerbal count in the editor but retain the mass changes in flight, what would I need to do in customizing the MM provided file for this? I like the concept of adding the weight and having to mentally adjust for it, but I also don't want to clutter up my editor windows with an additional slider as I have a fair few of those with my mod list.

Well my sash must be at my folks' place. I have all the badges from camps, cub scout activities and the like, including my eagle sash and dress pin (the one for lapels on suits) but not the sash itself. I'll find it eventually.

I noticed this from your signature. I too am an Eagle Scout. I started in Cub Scouts. I'll get a merit badge count when I get home and find my old sash, it's in storage someplace. Nice to see that we do have a few eagles on the forums.

The license allows you to adapt and share as long as it is under the same license (IE anyone who receives is under the license, cannot use commercially, and must give credit to the original source). Did you check if they seat alright after the changes with no gaps? I know a few parts had to have minor shifts in some mods besides the +/- indicators on nodes.

Just a side-note from looking at this again, you may want to investigate the shared module between DRE/nuFAR. I cannot recall the name of it, but there were issues with mods that adjust a certain stock module competing with each other, which prompted both mods to share-write that custom module to integrate with the flight director. You may want to look into that, seeing as this is likely going to interact with that same director. Could be a potential issue with compatibility in the future.

A little helpful support on asymmetric flameout here: http://forum.kerbalspaceprogram.com/threads/119607-Airbreather-fuel-flow-logic?p=1909169&viewfull=1#post1909169 As indicated, Intake spam certainly does not work, engines perform much in the same manner as the RL versions do (albeit significantly higher thrust values). Just check your intake placement order to ensure each engine is fed correctly and you won't have issues with flameouts in anything but a symmetrical/staged pattern. If anything, the drag from additional intakes will significantly hurt you compared to actually gunning for a little under the max height to air ratio.

I'm with Enceos on this one. The Ablator resource in stock has the same density/etc as your own AblativeShielding resource. I think the question isn't making/altering the stock resource (unless you feel the resource values need to change) but in using the existing one instead of having a separate resource tracked by just your use (or others tying into DRE) since it would be assumed most other heat shields/etc are tying into Ablator. Since the values are the same right now for both resources and I do not think the heat shield weight/cost has ever been an issue, it makes good sense to go ahead and tie into the stock one and drop the extra resource.

That's great to hear Taniwha. Please let us know if you need a Windows 8.1 test subject. I'm still having issues with my Saitek Cyborg X stick and need a replacement for stock joystick detection. However, the older AFBW had issues with 8.1 that were never resolved. As it is, a friend is shipping me two older Logitech sticks just in case but I'd love to be able to use my X properly for KSP.

We could give them a little credit, as it is the heating method itself is relatively what we wanted. What they forgot to accommodate (or purposely left out) is the very reason heat-shields exist. Skin heating. Their model accurately depicts how general heating would work, distributing through the mass of the craft. It's only during the re-entry phases that this model fails to work as it applies heat until the entire mass is heated to failure, rather than what Star is working on where it will calculate the failure of the outer skin which would in turn more than often destroy the parts during reheating. This is why we still need DRE, but we can use the stock model for the most part in general heating applications. I'm sure there will be others who hook into the radiator concepts for heat management to a much better degree than Squad foresaw.

Set them up like this, placing in the same order: AIR1 AIR2 ENG1 AIR3 AIR4 ENG2 If at X height each AIR produces 1 unit, and the ENG consumes 2 units, then they're evenly matched and you have no 'waste'. Beyond X height (which is now the maximum height of flight for this example setup) you'd flame out because both engines would starve within the same second and thrust would be cut evenly. The concept scales up the same way, so if you wanted to have a four-engine you could setup this way and still have symmetric flame-out: AIR1 ENG1 AIR2 ENG2 AIR3 ENG3 AIR4 ENG4 Now as a complex example of four engines, we have this which LOOKS like it would be okay, but doing an example shows the problem: AIR1 - 1.5 AIR2 - 1.5 ENG1 - 2 ENG2 - 2 AIR3 - 1.5 AIR4 - 1.5 ENG3 - 2 ENG4 - 2 This would be just a bit above X height (maximum sustainable flight) for all engines. ENG2 would immediately flameout, BUT, the leftover 1 air from AIR1/2 would be passed on to AIR3/4 making a total of 4 air, which would leave ENG3/4 running. This would cause asymmetric flameout and rotation.

Incorrect. If you did that, it would look like this: AIR1 - 1 AIR2 - 1 AIR3 - 1 ENG1 - 2 ENG2 - 2 The air for 1-3 goes into ENG1, pushing the necessary 2 air. The leftover 1 unit of air is pushed into ENG2, which is not enough to sustain it and it flames out. Also check my last post, I edited because the formatting threw it off. order is top down, and it wraps back up to the top at the end of the cycle.

Unless they've changed the behavior for air intakes, this is somewhat correct. I am not sure if the old behavior is still valid, but it would be an artifact of the order of attachment for intakes to engines. The pool of intakes to engines would look like this if you attached two intakes, an engine, another intake, and an engine: AIR1 > AIR2 > ENG1 > AIR 3 > ENG2 So in effect, air collected by 1/2 intakes is first pushed to ENG1, then past and pools leftover with AIR 3 which goes into ENG2. What would traditionally happen is that as you went higher up, ENG2 would flameout first as AIR3 would be exhausted and only the scraps of AIR1/2 get pushed into ENG two, whereas ENG1 is consuming two intakes entirely by itself. Excess air from AIR3 that ENG2 isn't using also does wrap around back to AIR1/2 pool. A math example of this: (AIR produces, ENG consumes) AIR1 - 5 AIR2 - 5 ENG1 - 3 AIR3 - 5 ENG2 - 3 This would result in 10 air going to ENG1 with 7 leftover air going to ENG 2 (total of 8 to ENG 2) leaving a total of 9 air in the pool. As you went up in altitude, the intakes produce less, so the next model: AIR1 - 1.5 AIR2 - 1.5 ENG1 - 3 AIR3 - 1.5 ENG2 - 3 Here we can see that while ENG1 still has just enough to continue to operate, ENG2 is receiving no 'spare' from AIR1/2 and thus ENG2 starves and flames out. In order to balance this, it was always a factor of putting an even number of intakes before each engine to ensure that the pool fed correctly into each engine. Please note my math examples aren't actual figures, they were made up. The new model does help in terms of starvation, so it's rare that you will need more than one intake her jet as mentioned by Arq, but these rules still apply if you are using more than one intake. Never place your engines and intakes in symmetry mode on planes without remembering this as it can cause asymmetric flameout.

Hi Avera9eJoe, just to let you know your link is directing to the older 0.06 download, rather than your 0.07 one.

May be a bit late to the party, but it depends on the gear you're using. One of the landing gears has, for some reason, more drag when it is put away rather than when deployed. It's a stock bug, I believe it's mentioned more precisely in the Stock Bug Fix sticky. Take a look at that and see if it's the offending gear, it probably is not nuFAR at fault in that case.

Thanks a ton Pizza, this is an excellent mod. Just a warning though, you may want to update the first post to reflect the new version (as I didn't realize you'd updated it to fix the landing gear bug).

I also have the same issue, as it isn't just a particular set of the Saitek family. My Cyborg-X has tendencies to lag behind and have some 'stutter' on inputs when used for KSP. Controls seem abnormally behind my input with current KSP. Unfortunately, even the AFBW was unable to assist me as it did not support the Windows 8.1 OS with all sticks and would only register a gamepad I owned. Mind you, using the joystick in any other game has prompt response times and windows reports full use of the joystick and immediate updates when testing.

Would the wearing out thing be much better tracked with a mod designed for failures? A Dang-it link might be a better use than that, rather than making something like its own wear-out resource. It tracks the MTBF, so you could have it feed in 'damage' events over time from particularly rough incidents that decrease the MTBF, with maintenance increasing MTBF. A complete break would probably need a small event for replacement rather than spare-parts repairs, but it might be doable in that method with a lot less hassle than tracking your own resource in the plugin. EDIT: Also, it would give the option to leave it non-breaking for more casual use, or have something like Dang-it to add that functionality in rather than having to handle it yourself. A few simple MM checks can make it function either way and leave it outside of your wheel/track plugin.

I'm having the same issue, the before-ground impact isn't working, but the time-change before deployment of chutes does work (real chutes for me).