zer0Kerbal

didn't know that - could have saved ~3.5 gb. installed now, and yes have VS. thank you.

haven't recompiled it yet - need to update unity(just trying to remember where I put the download link) next then will recompile. Tried it with the version recompiled for 1.3.1

What is the priority to be updated (part code not modeling/texturing)? Fuel tanks or engines? or?

that is what I am thinking; loaded both - only one working. Changes to UI probably have crashed this one while TrimIndicator seems to be functioning perfectly. UI work, iirc, is considerable work.

@linuxgurugamer this would be so symbiotic to merge into TrimIndicator. just saying.

I think I have solution to the KAS :NEEDS issue. Will try when I get back later today. Normally this (:NEEDS[KAS/Legacy]) would work, except that every update will scrub the directory and am expecting most (like me) to just move the directory somewhere, and probably rename it. So the answer is either :NEEDS[@PART[]) or as I remembered :NEEDS[@MODULE[KASModuleWinch,!KASLinkWinch]] (think that is correct syntax) since KAS changed it's module names for 1.2, then that is a great indicator / method of solving my dilemma elegantly. And with KIS2.0 coming sooner (maybe) rather than later (Breaking Ground seems to have put pressure on @IgorZ) - can expect that this method should also work then for that as well.

Normally this (:NEEDS[KAS/Legacy]) would work, except that every update will scrub the directory and am expecting most (like me) to just move the directory somewhere, and probably rename it. So the answer is either :NEEDS[@PART[]) or as I remembered :NEEDS[@MODULE[KASModuleWinch,!KASLinkWinch]] (think that is correct syntax) since KAS changed it's module names for 1.2, then that is a great indicator / method of solving my dilemma elegantly. And with KIS2.0 coming sooner (maybe) rather than later (Breaking Ground seems to have put pressure on @IgorZ) - can expect that this method should also work then for that as well.

slapped a promo image together.* oscar fuel tank included for size reference. *lights not included, they belong to tracking lights.

public domain, which is appreciated. If you have others you would like to see this same done to - just kindly tell me. Parts only. If I find time - will try to take some pics and post them of the parts.

*drat* thank you. won't be as good as needs[part]

Thank you @Nuke. Would like that. Glad you pushed. Until you return to working on it: source - release Spacedock (when done uploading) - also on CKAN as Nuke Refueled.

am still shaking head about the missing re_scale.dll....

@Tonka Crash yep. hence the ask for your opinion on each. seems that way - been afk and just back. will have to look further into it. the larger ones then will try to split into KIS/SereneStorage combo. I thought you could put out several, just not one per biome. exact number yet to be determined. If what you are saying is right, changes thoughts. Still I like the really big ones, as you said more realistic.

new to dropbox. this should fix it. also corrected post above. actual patch above.

so - finished the start of my idea. Thank you. KIS_Containers.cfg two issues - seems the GUI maxes out at 30, and how many should each type have? included the thought process pseudo-math as comments. The larger ones might see if can split the volume into Serenity Storage and KIS storage. thoughts? All these 'new' containers :NEED[KIS] and will show up in the new Cargo category in the editor.

agree, knot going to tie myself up; however am still going to ask. If possible, not a big hassle. I love problem solving and learning. This is recreational for me. They do seem to work (am testing later today) with both versions of the KAS.dll installed. Also IR-Next has a magnetic grappler that can either be used or the code added to say the harpoon or magnet. IR-Next also (if the Kerbalvine speaks truthfully) has similar additional parts coming Soon™er™ish™. Still - want to hear back on what is working, been too busy updating to actually do anything more than a mechanic's test drive. IMHO, no to both of these Now I remember why - I don't believe can add navball orientation switching without having module[command] - don't think it works on kerbalseats.

Yes, I believe so.

The parts are supposed to be in the /LEGACY/ folder, but I know that since that folder disappears every time KAS is updated that many (including myself) just move it elsewhere. I do believe it is possible to use the existence of a part in a HAS or NEEDS statement - I vaguely remember reading that it could be done - so will try. @Lisias is asking to have MM include a %version% statement - would be great if @IgorZ could/would add a :FOR[OLDKAS]; just if MM can do what I ask of it - great. Eventually am planning on adding (end of year maybe) all the patches to Patch Manager format - but only after everything else is settled and released, but patch manager only addresses the issue for a small fraction of users. I don't use Patch Manager myself due to it is way too easy to multiply patches being applied*. thought about that, going to try first. the harpoon, the magnet (IR-Next has), the grapplinghook... otherwise what is the point of the winch on the Pod? The GrapplerJr is an EVA tether - so ... yes, there is that for the Pod as well. * not Patch Manager's fault, I just like packing everything including the kitchen sink, the basement faucet, the garage's mop sink, and even the pet's favourite bowls.... for me Patch Manager means 100K patches... or more. never again...

This. if KAS-CPORT1 is installed/present then old KAS is installed, if it isn't then new KAS is installed. Need to install the appropriate modules for the winches on the Orbital Tug. Could just leave it up to the user to switch on/off patches, but rather prefer if possible an elegant, simpler approach such as this.

Those are meant to blow up. this is the 'elegant' solution to the KAS issue - if the part CPort is present, then old KAS is installed, if it isn't, then new KAS is installed.

thank you. very nice. was considering this very issue earlier, glad you were too.

@blowfish the rounding code seems to work. Will test it further. Thank you. Next query: I want to write a NEED[partname] statement and am unsure about the syntax: Thank you in advance!

yes - the TAC and TWSA both :NEED[TAC] and use the code. KIS will use the KIS code. Done. RT patch converts the antenna into RT antenna, :NEEDS[RemoteTech] - will include. Done. What about the rest of the parts? The new demolitionHelpers should be set at 0.5 or ? Thank you. I should be in attendance. Agree. It is, as far as I can tell, currently at a very solid place. Agree. Mid to late July. KAS will take a good couple hours to get working. .I also want to go through the FS patches, then the B9 patches, then finally the Interstellar engine, finish the demolitionHelperKIS, the impactHelper (stretch). My opinion is now is all about QBB (QoL, Balance, and Bugs). Am also pondering merging the TAC/TWSA demolitionHelper into one - same code, just different models - just merge the models so instead of 4 TAC or 4 TWSA models on the helper it would be 3 TAC + 1 TWSA model on the helper model. Am pleased, but not satisfied with current state. Query: (I will ask over at the MM thread): how to :NEED[partname]? watch you later.

@linuxgurugamer [NEW] v 0.23 being pushed. changelog; Current Status: Some more development pics: v 0.24 will be held until enough βeta testing done.

Astrogator is another MechJeb also has one in it's maneuver planner