OliverPA

Indeed I did! Removed the --force.. parameter and the issue is gone. I was certain it would be mod-related... Thanks a million!

Can't figure out and didn't find any posts that would explain what could cause all parts icons to look like below but it sure kills the fun of building crafts... Any ideas?

removed.... just read the note above

This mod is simply awesome. There are so many lovely fuel tanks that unfortunately store the wrong type of fuel and finally with this mod they become usable. I wonder though if it is possible to edit the title of a fuel tank so that the "Xenon tank" can be renamed to properly reflect that it holds water or oxygen or whatever.

Regarding the MJ issues - I submitted a simple code change to the MJ project on git that makes MJ only enter warp once the rotation is below a certain minimum, ie. once the vessel has settled on the target. It works quite beautifully in my dev build. Of course changing towards the target takes a bit longer now, somewhat dependent on the vessel. Then, once settled, MJ enters warp. If there was a little rotational momentum left and the warp is very long, then MJ might drop out of warp once the deviation is too large and resettle on the target. But this happens fairly rarely on in my game. Let's hope it is included in the next MJ release.

Alright, thanks for the clarification. Unfortunately when I compile the dll it crashes on load so I can't do terribly much However I have noticed that the dry mass in the right click menu of the tanks scales correctly whereas the actual part mass doesn't! So ModuleFuelTanks.cs line 1007 produces a good result of >0 even when the actual part weight is <0. Maybe it's worth looking at the if() starting line 970 which has only one code flow that does not lead to part.mass = mass, ie. line 985. Also there always seems to be a difference between the dry mass in the right click menu and the part mass. Take a Mk1 pod -> total mass of 850kg according to Engineer Report. Add a FL-T100 tank with dry mass of 9.3kg -> total 860kg which is fine. Scale the tank to 2.5m (= 2x) with a dry mass of 74kg (= 9.3*2^3) -> total vessel mass of 1362kg so +502kg instead of +74.

Oooh, that's a bit embarrassing, I totally missed that there's a TS interface in the plugin But that raises the question - is TweakScale_RealFuels.dll supposed to be distributed? Because it's not in the RF release... I can compile the solution but get exceptions upon loading the compiled dlls.

@NathanKell I've not seen this TweakScale-related issue mentioned anywhere other than @ferram4's FAR mod where the error description is that vessels start floating at launch and in some cases the game even crashes. But it seems ferram's mods are involved but not the root cause. Now the floating at launch only occurs when parts are re-sized with TweakScale and it is actually introduced by KerbalJointReinforcement during physics easing. But I've tracked the root cause down to these parts having a negative part mass and a rigid body mass of 0 which only occurs when RF is enabled! The same vessel without RF but with TS/FAR/KJR works fine. I've reduced my ksp install to bare-bones (RF, RF-stockalike, TweakScale, KerbalEngineer) and every tank or engine that is sufficiently down-scaled has a dry mass <0 sooner or later. It's taken a couple of hours to get to this point but now I'm quite stuck. I can't figure out how the RF mod influences TweakScale behaviour and/or dry mass calculations Any ideas where to go from here?

Tried to find the answer in the documentation but I'm not 100% certain... Is it still necessary to load the programs at launch time? I love the mod idea and tried it a while ago but loading it every time at launch got so annoying. Would very much prefer to be able to define which program is run in VAB.

Same here: TweakScale + FAR = floating vessel at start and a crash soon after. Rescale to 100% = no issues log

If you want to have a look at the hotkey for the fine adjust window: https://github.com/linuxgurugamer/EditorExtensionsRedux/compare/master...OliverPA77:hotkeyFAW?expand=1 There's also a binary as draft release to try it out real quick. I put "None" as default for the new hotkey so if a user wanted to assign it they'd have to do it consciously without the mod spamming the keyboard with unwanted shortcuts. It's a good compromise, no? Have a look, if you like it I'd create a PR... The auto opening/closing of the window actually works quite nicely regarding the key-controlled adjustments. You open translate/rotate gizmo and the window opens. You switch to another gizmo and it closes: // automatically show fine adjust window when offset or rotate gizmo are active if ((GizmoEvents.offsetGizmoActive || GizmoEvents.rotateGizmoActive) && cfg.AutoFineAdjustWindow && !_fineAdjustWindow.isEnabled()) { _fineAdjustWindow.Show(); } // automatically hide fine adjust window when offset or rotate gizmo are inactive if (!GizmoEvents.offsetGizmoActive && !GizmoEvents.rotateGizmoActive && cfg.AutoFineAdjustWindow && _fineAdjustWindow.isEnabled()) { _fineAdjustWindow.CloseWindow(); } But currently the fine adjust window also removes the snapping feature when using the mouse and this would need to go to be useful altogether. Btw. any particular reason why the fine adjustments are triggered by GetKey and not GetKeyDown? It happens quite regularly that the part is moved too far...

Yes I think hat did the trick, thanks for the tip!

It's this one: https://github.com/OliverPA77/EditorExtensionsRedux/pull/1/files I created a fork, then a branch and a pull request but apparently the PR is now within my fork and not visible to you? Before this I tried to create the PR in your project site but it didn't let me. Btw. I've also implemented a shortcut to open the fine adjust window (including setting in settings window) and am now going to have another new setting that opens and closes it automatically whenever the translate/rotate gizmos are activated. The shortcut is definitely convenient but I'm not sure yet how the auto-thing is going to be like...

@linuxgurugamer I'm new to the Github stuff so I'm not sure if my pull request worked as expected. Basically I found myself wishing for a possibility to use the H hotkey to horizontally align along the other horizontal axis (z-axis). Only a very minor change was needed to extend EditorExtensionsRedux.cs to use the H hotkey (or whatever the user has set) for x and Shift+H for z axis. I would have preferred to use the mod-key but mod+H is already taken by HyperEdit

Indeed they don't - it was like that before the last update as well. Fortunately it's just a visual issue.

Thanks @Phineas Freak. I opened an issue... The pull requests are weird

Alright, so line 481 in TankContentSwitcher.cs is the problem - it references part.mass instead of mass. I changed that line, recompiled the dll and the issue is gone. I thought about putting the change into Github but not sure how. Pull request? Just an issue report? Anyways, here's the change: TankContentSwitcher.cs, line 481 currently: return Math.Round((res.unitsConst + tankVolume * res.unitsPerKL + part.mass * res.unitsPerT) * shapeMultiplier, 2); fixed: return Math.Round((res.unitsConst + tankVolume * res.unitsPerKL + mass * res.unitsPerT) * shapeMultiplier, 2);

Since I'm constantly looking for the right antenna in terms of range, size, looks, etc. I missed the ability to scale the available antennas. This MM patch changes all RT-activated antennas by setting them up with TweakScale. Mass is scaled by the power of two since most antennas are surface-like. Cost is scaled linearly (simply feels right). Now the important bit - antenna range: Seems to me this should scale linearly as well since e.g. doubling a dish antenna quadruples the surface area but shouldn't doubling the range quadruple the area/energy requirements as well? I'm not an engineer so if someone knows better I'm happy to be educated So currently dish antenna ranges scale linearly, omnis a bit less and energy requirements stay the same regardless of scale. As do the data transmission parameters. All of that could be changed though if someone provides good arguments as to why... Range scaling - should be stock if you ask me Samples scaled 50% - 100% - 200%:

While I love the procedural fairings both as aerodynamic and structural parts, I've always been annoyed by the height the fairing bases add to the rocket. Especially when using them as interstage parts their use quickly becomes limited as they add so much height with so much obvious emptiness inside them. And offsetting other parts into them comes with other issues like unrecoverable probe cores stuck inside, etc. So I created a little MM patch that makes slim-copies of the original parts by shamelessly scaling them along the y-axis. To my surprise it seems to work perfectly, ie. the fairing still attach as they should and I don't notice any weird aerodynamic behavior TweakScale works nicely as well... Because these parts are copies, they don't break existing ships in flight. I really like how these new 0.2x scaled bases allow for sleek command module parts (probe core, reaction wheel, batteries, mono-tanks, rcs attached to outside) that rival custom made parts. Notice how in the first screenshot both bottom interstage bases are set to 0.7m height but the slim version offers so much more space to do something useful with. To add a bit of a challenge in career mode, the slim bases have +1 tech level requirement than the regular versions. I hope you guys find them to be useful and fun as well. MM patch:

Same here - procedural tanks are empty to half empty upon loading in VAB even though their are full in the craft file. Simply replacing the 1.2.3 ProceduralParts.dll with 1.2.2 was enough for this terribly annoying issue to disappear. Looking at the source code there are a few changes where the part mass used to be saved in 1.2.2 and now in 1.2.3 just an event is triggered...

So first of all thank you so much -ctn- for these lovely cubes! I've been using them for a while and they are truly awesome. I did notice though, that they seem hugely overpowered compared to stock parts to the extent that using them feels like cheating: They weigh and cost next to nothing, yet have SAS, on-board reaction wheels and a huge battery. But where is all this equipment supposed to be? They cubes are clearly hollow. So I've tried to make a few changes and am interested in everyone's thoughts if these changes integrate them better within the world of ksp. Removed reaction wheels and reduced huge batteries because these parts are definitely larger than the clearly hollow cubesat models. In line with similar stock probes they now have an on-board electric charge of 5 (was: small 400, tiny 200). Aligned cost to 75% of comparable stock parts because while I get that Cubesats are supposed to be cheap alternatives, they seem to be by far too cheap considering their capabilities and size in ksp. The small cube is comparable to OKTO2 in terms of features and now set to 1100 (was 200) and tiny is comparable to HECS - 100 for reaction wheels and now set to 500 (was 160). Tried to align weight with stock parts because the current weight was set to small = 20kg and tiny = 10kg which makes the tiny cube 1/4th the weight of OKTO2 (= 40kg) which has similar features and is much smaller (= far less metal parts). Set the weight to 40kg for tiny and 120kg for small which still gives the cubes a clear weight advantage compared to similarly sized stock probes which could be explained by not having solid side panels. Changed TweakScale settings because they scaled mass (and cost and resources...) by the power of 3 which shouldn't be due to the hollow nature of the cubes. Power 2 would seem right if the side panels were solid, so I used 1.25 which gives sensible values for the various sizes in my opinion. Also changed TweakScale settings to not scale the battery size. Added a second bottom attachment node so that the bottom can be closed or used for another solar panel, etc. It even allows for cube stacking Added RemoteTech support. Also the solar panels are not aligned at with stock (weigh far too little, cost nothing, generate clearly less than stock panels). New values are based on OX-STAT panel. Changed TweakScale settings to use power 2 instead of 3. These changes are written as a MM patch to the original mod, so put them into a new cfg file: