darthgently

On the other hand, modders could agree to use a common API to a mod that is a window manager outside KSP2. But that seems a bit like a goat rodeo trying to get that to work socially

I'm not a KSP modder, but it seems fairly clear that a built in window manager for mods would be great where the mod could be aware of where other mod and KSP windows were on the screen and which window was clicked in was centrally managed. Every time I open a window or PAW I cringe just knowing that it will likely open underneath the only other window open on the screen. The same for input management in general. Many mods seem to read the keyboard raw so even when typing into a very specific textbox in a window, hitting certain keys toggle unrelated mod behavior (Smokescreen, Hullcam...)

I can't remember if this mod requires Contract Configurator, but if you have that installed make sure you have "SCANSat Contracts" enabled in the CC settings. I think, as I recall, but that is the gist

Maybe what is needed is to treat the SpaceX parts and models the way SpaceX does. Instead of entire craft, perhaps have landing legs, gridfins, etc. be separate parts and the tanks sections be tweakscalable ring sections.

I know this has been addressed in the past, but things may have changed. I have many KIS EVA propellant tanks in various inventories and am wondering if they have functionality now or should I ditch them?

Why would it replace mod+click? I assumed they'd both be there. Ask anyone who uses a 3d design/cad/modeling program that has select boxes, they work great once you get the idea. You obviously wouldn't use it in situation where it wouldn't work well, but something tells me that you would be surprised at how often it is easy to just select what you want. But you bring up an excellent idea on its own: being able to add/subtract from a select whether via mod+click or otherwise. Is there a way to do this with mod+click? I'd love that.

Being able to select a group of items by click-dragging a selection box around the parts is very common in modeling software, CAD, etc. It would be great to be able to do this in the KSP2 editor for copy and other operations. With this functionality one could replicate a group of parts without detaching lower sections for example. In flight, one could turn on a cluster of radiators without turning on all radiators, or powering them up one by one or select a group of tanks in prep for a fuel transfer. One could select a target in orbit that is in view without having to double click on a tiny dot on the screen; merely capture it in a generous, easily dragged box. The selection would be followed by a keystroke or popup in the case where multiple options were possible

I'm trying to run a minimal mod game, but am caving in to the need for the "service airlock" part I found very useful in previous games. Are the "Scatter" service airlocks in this mod? Sorry if wrong mod forum. If there is a streamlined way to find what mod a given part is in, without installing said mod, I'd appreciate the education (in a PM is fine) I was directed to KerbalX site where a fairly complete search for parts can be done

KSP 1.12.2, debian linux. Quite a few mods. I'm mod-clicking/copying a subsection of the craft, pressing "4" to reroute the subsection still held by the mouse curse, selecting a surface mounted dock port on the subsection as the new root part for the subection. Up to this point all goes fine. But when I pick up the re-rooted subsection by the root part (dock port) and attempt to attach it to a dock port on the main craft, the EditorLogic errors flow in the log, sometimes the subsection starts creating "trails" where copies of itself spread across the editor screen and sometimes the only way out of the loop of infinitely spawning copies is to reload the craft file. My question is this: is re-rooting to a surface mounted part the soft ground here? I want a way to avoid this problem. sample from logs: [EXC 12:34:04.348] NullReferenceException EditorLogicBase.AssignAttachIcon (Part part, AttachNode node, System.Boolean stackNodes, System.Boolean srfNodes, System.Boolean dockNodes) (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) EditorLogicBase.handleAttachNodeIcons (Part part, System.Boolean stackNodes, System.Boolean srfNodes, System.Boolean dockNodes) (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) EditorLogicBase.displayAttachNodeIcons (System.Collections.Generic.List`1[T] parts, Part selectedPart, System.Boolean stackNodes, System.Boolean srfNodes, System.Boolean dockNodes) (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) EditorLogic.<SetupFSM>b__189_51 () (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) KerbalFSM.UpdateFSM () (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) EditorLogic.Update () (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 12:34:04.381] NullReferenceException EditorLogicBase.AssignAttachIcon (Part part, AttachNode node, System.Boolean stackNodes, System.Boolean srfNodes, System.Boolean dockNodes) (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) EditorLogicBase.handleAttachNodeIcons (Part part, System.Boolean stackNodes, System.Boolean srfNodes, System.Boolean dockNodes) (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) EditorLogicBase.displayAttachNodeIcons (System.Collections.Generic.List`1[T] parts, Part selectedPart, System.Boolean stackNodes, System.Boolean srfNodes, System.Boolean dockNodes) (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) EditorLogic.<SetupFSM>b__189_51 () (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) KerbalFSM.UpdateFSM () (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) EditorLogic.Update () (at <4a4632fe4eb0471fa0f9f87bb7432bc2>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Leaf on the Wind - first time landing on Eve

Pusher plate repair: 100 repair kits.

I tried that one and it also disappeared the DockRotate (the mod, not the stock rotation) options from the PAW and too many of the craft in my current game require dock rotate (dock port mounted engine pods etc) where alignment is critical. I also tend to lean to solution that are hosted on CKAN for maintenance sanity reasons. But how does DockRotate avoid the magic accelerations? Or sure seems to avoid them in my game

Nvrmnd, further searching led me to the mod that fixes a lot of this. Trying it now. If I'm behind the curve and this mod doesn't work I won't be offended if you delete this post with the link to it. Thanks for all the work, very much appreciated. https://github.com/KSPModdingLibs/KSPCommunityFixes

Is there a setting to turn off 1.12 stock rotation functionality? It seems to be interfering even if I don't touch it in the PAW

Is "rotate to snap" supposed to always achieve perfect alignment? It mostly does for me, but often doesn't and instead gets somewhere below 0.2 degrees, but not zero. Also, does the stock dock rotation in 1.12.x play well with DR? I'm having an issue where ports that were aligned, are misaligning somewhere < 0.2d within the same scene (no leaving scene and coming back etc)

This would be cool. Using ground based telescopes to discover the planets and stuff using parallax in imagery. Maybe a mod could do this and even generate differences in the system for each game to some degree via a Kopernicus like mechanism

There could be rare but possible micrometeorite/debris damage to craft. Any damage would appear as a report in messages so it wouldn't sneak up on the player. Maybe settings could limit it to active craft only, or even possible to craft on rails. Damage could be repaired with repair kits. I'm imagining this as a very rare occurence, perhaps slightly less rare if in a high asteroid count area (Dres orbit) on the theory that many asteroids close together would eventually collide and create debris now and then. Also perhaps a higher chance when in orbit around a body with a lot of player debris floating around that hasn't been cleaned up. Finally, leaving service bay doors open would expose the equipment inside getting damaged, but typically only parts composing the outside layer of the collision mesh could get strike damage (PVs, tanks, antennas, science instruments outside of closed service bays, etc). For the purposes of simplicity any Kerbal inside a craft or items in inventory would be immune to this rare damage. But woe unto the Kerbal who spends too many orbits around the Sun in a command chair. He's toast eventually as the odds are not in his favor. I'm not picturing this as a major game challenge but more as a tedium breaker that adds some grit to the game. Like maybe even a damaged tank would lose a tiny fraction of fuel over time until repaired, but the fraction would not typically be mission threatening. And an engineer with enough experience could roll the dice to temporarily solve the issue without a repair kit even, but might have to repeat this until a repair kit is applied (add Duct Tape as default Sr. Engineer inventory item?) On the other hand, maybe the "challenge level" of damage would best be left as a user setting. Dialed up to the highest setting a player could get a message once in a blue moon that an entire craft and crew went down from an meteorite strike. Ouch.

Kerbals with neckbeards. ha

I think I've seen something along these lines in that when I rescale a part, sometimes the nodes are off. But if I remove it from the craft, drop it in the "air", and copy it, the nodes fix and I can reattach the copy correctly. I think this mostly occurs with parts I've previously changed the variant on; but I nearly always change the variant from default so hard to say from memory. But I have seen some fairly direct oddities while changing the variant of a scaled part. Like the part going transparent will still attached to the craft; but only once in a while. Also, I've had trouble attaching some multipart sections after removing them unless I first drop it then copy it *and* I have to be fast when attaching the copy. If I take more than a second to complete the attach the NULL REF errors flow like anti-manna from hell and only clicking in the inventory area to delete the held parts or ctrl-Z will end that loop typically. But if I'm fast, it will attach fine. Completely reeks of some kind of race condition in which if I attach quick enough, I beat the branch that sends it all the hell

This is a good idea. Of course there a lot of resources on the web but it would be great if some it were integrated into the game such that a settings option could make it more visible. I mean imagine if KSP2 cracked the education market and school districts were ordering it 100 packs the way they used to order Oregon Trail. Educators could even create add on missions that taught specific vector math concepts and such in-line with the game

To clarify, upon reload the parts are still overlapping and wonky, but now one can click on them and they will attach normally instead of overlapping and spacing out. So the save/reload doesn't completely rectify the thing, but is definitely fixes some oddball "offset" issue or something. My gut tells me that some interaction between KSP and mods and TS isn't properly scaling the offsets on copy, or a scaling is being interpreted as an offset or something like that. Which originally looked like an attachment node issue, but I think that is a side effect Could it be that TS is acting too soon? Like KSP is still in the process of copying the object or something? I imagine that KSP offers no obvious way to know when "too soon" is, but maybe there is something the code could look for if some kind of race condition is happening

Well, saving/retrieving works. Whatever the reason

That is it exactly. I did find a workaround until a patch. Just make sure all the parts you want are attached to the craft in some way, save the file, reopen the file, then click the odd parts and reattach them. There is something about either the save process or the retrieval process that makes attaching work properly. I am the black box king, lol

I'm about to give up on TweakScale, which is pretty much giving up on KSP as I can't imagine having much enjoyment dealing with the clunky part size options. Clean 1.12.2 install with the latest TS and stock parts and I'm having severe issues in the editor. It seems that the attachment nodes don't always scale with the parts, especially when <modkey>-copying a part or assembly. For multi-part assemblies with TS'd parts, if one <modkey>-clicks the assembly to copy it, more often than not all the attachment nodes revert to their pre-scaled geometry making a complete mess of of the assembly. I've had similar things happen in flight, but much more rarely. There are corner cases that the code is missing apparently. Important corner cases. No errors show in the log when performing these operations at the time of the operation. Sorry to be whinging but obviously this isn't the only issue when dealing with KSP. Add all those issues together and I spend more time dealing with these kinsds issues than learning more about orbital mechanics. If it weren't for kOS and my self-educational goals I'd have been long gone awhile ago. But to be quite frank, TS and many other mods need to a full regression test and a bug fix *only* release in my opinion. I'm really ust trying to be helpful here. When new functionality is mixed in with fixes it always seems to cascade into more chaos. Looking more at it, the attachment nodes aren't reverting to the pre-scaled points. It is more like the scaling is being applied twice, or incorrectly. See image at link. Let me know if link doesn't work https://imgur.com/a/UAD1jnW

It was a CKAN error, as I recall. I couldn't successfully install KAS until I selected KSPDevUtils in CKAN