zer0Kerbal

love it.use it. thank you. feature request - either in separate or same window - the relative x/y/z velocities to target. can do this with a special window with MJ - but no where else.

if it is what I think it is, I have a use for it - maybe.

so glorious that I had to make sure to see them again!

@linuxgurugamer PR done for: v0.16 v0.17 v0.18 v0.19 nodes and B9 node switcher should be 99% done. Someone try to break them, and still am soliciting comments and suggestions. Broke the nodes up for each part into one or more B9 switches. Nodes, glorious nodes! there seems to be an issue with DronePod texture switcher - white only. my eyes are bleeding OT-Yellow.

SCANSat is done. InterKosmos is done. Maybe should rotate 1-3 parts to make them all same base orientation? TrackingLights is done DM sent. Also on my github. these patches are all written in a manner that should prevent conflicts any issues as is happening with TweakScale now.

stumbled across this image... https://imgur.com/a/GyXl3

Thank you! I'll use. Feature request: have MADLAD create a .log (fresh every run) file in \Logs\MODLAD\ like MM does? would be a stretch goal of having either a command line switch (like MM does) or setting to turn that feature on/off. This log would parse KSP.log for all WRN/ERR etc and store in its own with related messages.

for a change of pace - tested the demolitionDrones - they make Jeb proud! will publish once I finish manually welding the meshes together. impactDrone will take longer.

MK2 Landing Can is slated for tomorrow in order to prevent my eyes from bleeding OT yellow. SCANSat is done. InterKosmos is done. Tracking Lights is done. KAS might be done. (old and new) low priority for the weekend. KIS (just the core Ma'am) (no fun) probably will be done. Maybe TACSelf Destruct.... I will PM when they are done. will probably post on my GITHUB under a new repository just to make it simple for me. OrbitalTug has been NodeDazzled. lots and lots and lots. sorry - don't think so - but what you can do is use EditorExtensionRedux and place them, then strip symmetry then rotate as needed.

v0.18 now on github. should have all the nodes done end of day Sunday. *knocking on space* tested the helperDrone - it decouples like it should CONTROLPOINT working in all except grapplerJR. lots more in the changelog. am wondering out loud if the built in cameras in the two pods could be tied into hullcam or another mod... stretch goal. images from testing (mods include Breaking Ground, IR-Next, Tracking Lights, and Interkosmos)

I'm BACK! Want to add the new ControlPoint functionality to parts that don't have it, the patch I have so far is below. a fresh set of eyes would be appreciated!

can't resist - have you tried saying 'Beetlejuice' three times really fast? I've never seen this behaviors, never heard of it.

Okay , last invasion of this thread. Yes, it has been most enlightening and entertaining. we are on the same track. No Kerbal Left behind! Just Gremlins.... don't feed them after midnight, and don't get them wet! Agree on marking the patches somehow - maybe a dummy statement in the MODULE[TweakScale]{ motto = don't panic}. So I plan on uploading the updated patches to a fork on github for your perusal at your leisure wearing a lime green leisure suit. Only about 20,000 changes. If you like, just inform me of what other changes you desire and I shall try to make them. Maybe for now just put them out for 'new save games only'? PS your English is better than most native English speakers. I am used to ESL speakers as my day career has me mingling with dozens of nationalities (usually 70+). Spell check and Grammerly helps mucho. ps - forked and uploaded something like: Showing with 7,185 additions and 7,185 deletions.

Moving thread now: So what you are saying is that rather than making the problem evident let it be hidden? I don't want peoples save games destroyed, but as I believe you have said - they are on already on a path to unavoidable, unmitigated doom; that it is not a matter of if but when their save games will crash in a way that would make Jeb feebleminded. Unless I am mistaken, none of this is TweakScales fault, rather on slip-shod ad hoc patches. so two paths: for existing savegames: keep on trucking. for new saves: new and improved patches that preemptively correct the inherent problems. If both TweakScale and AllTweak make those changes - then neither can or will (should) be able to ever cause this problem again. (bad patch! go to your corner!) SO for existing saves - don't update the patches. For new saves (and those brave foolhearted fools) install the updated, stricter patches. The idea is that with the patches following best practices, that no matter how patches apply the same module, there will always only be ever one module; and the :FOR makes it possible to do :AFTER or :BEFORE (if I am understanding correctly). I am unable to fix existing savegames, but this might help prevent Krakens from invading new save games, at least that is my goal. If I am wrong, I will wander off and go back to rescuing Kerbals and dealing with a spaghetti wobble in my LKO Station.

remember to click 'save' after pressing that fixing button.

so this *might* also address the scaling factor you are talking about and @Lisias

moved: thank you for the free parking.

moved to correct (TweakScale) thread. apologies for the attempted jacking.

yep - that's the point.

and another possible way is to make sure things don't go wrong: % means 'add or edit' or could be "&MODULE[TweakScale]" for add only

well, all three FILTER: (all, locked, missing) - would help to find things faster if only showing .crafts that can be built at this moment.

@Lisias here is a sample of what I am proposing, I can upload all these fixes to github in one shot if you wish for all the TweakScale providing patches. They still need to be tested beyond my capabilities. have changed all the patches on my test installation to try this, so far works perfectly.

Totally Understood, and until 1 minute ago I wan't using your mod. After I read the part.cfgs I installed it. I am thinking that part of this issue as a whole is 'lazy' MM programming - not meaning to offend, is just an industry term. There has never been (a known) issue that made many MM patches need to be specific - just quick and dirty. Now, what I am thinking is that we need to do better with the MM patches, to make them 'tighter'; hence the use of % and & in the patches I am writing and updating. Just thoughts.

instead of deleting - how about a suggested change to the z_TweakScale.cfg? @Lisias - would this fix the issue? @nmc would you kindly try this adjusted patch? see if the TS parts are still duplicated. Not saying who is doing what, just saying this might fix it. @OhioBob I saw a couple of things when I was researching this - and have (hope you don't mind) put in two issues on your Github.

thank you. saved me a spell of time. I have written part upgrades in the past, and have really wanted (low priority) to do a more expansive set. this will make a great tool to start/continue that toolbox.