nmc

Nice work! I am against surface attachment for these parts, even without knowing about the bug you mentioned. Also, that's quite enough parts for me, thanks!

@ZodiusInfuser I like the hex hub! And for multiple attachments like that I use ReCoupler

I did not have that issue, sorry I only use the basic KK function: adding statics to the game and using some of them as launchsites; I do not use the other features like "aeroplane utilities"

@Ithirahad there are many statics in "KerbinSide Core" (on CKAN) and very cool runways (with numbers that dynamically update based on heading!) in KerbinSide Remastered

@CBase wow this sounds awesome, I cannot wait until you release something stable Currently my experience with precise powered retrograde landing in atmosphere using MechJeb 2.8.4.0 is: Between the deorbit burn and the atmospheric entry, sometimes (maybe depending on starting altitude, or target latitude, but not sure) MechJeb will enter a bad state and start burning full throttle along the normal vector; stopping Landing Guidance, time-warping a few minutes and re-starting Landing Guidance usually "fixes" it Between the deorbit burn and the atmospheric entry, MechJeb seems to be switching between two trajectory models; one undershoots the target and the other overshoots it, so MechJeb is constantly alternating between two opposite course corrections; as a result, the vessel wiggles and does not make any course correction; this can be "fixed" by time-warping to atmospheric entry (EDIT: because, as long as the initial altitude is not too high, any offset can be corrected by RCS during atmospheric descent) Atmospheric descent is mostly unpowered and uses aerobraking (because MechJeb figures the terminal velocity will be low enough?) During atmospheric descent, the "Use RCS for small adjustment" option does a great job at keeping the predicted landing at a few tens of meters from the target However, the braking maneuver just before the Final Descent phase is cut short and does not cancel all horizontal velocity, so I always end up overshooting the target I "work around" this by using parachutes with a carefully-selected deploy altitude (depending on the initial and target altitudes), so that they deploy precisely above the target; it seems that parachute deployment prompts MechJeb to properly cancel horizontal velocity

@ZodiusInfuser I would say that this is too many for my taste (I am pretty sure I will never use the versions with non-90° angles) but I am in no way representative of IR users and it really does not matter that much to me anyway (I can live with a few more parts in my Structural category) And thanks again for working on the hubs in the first place!

Thanks @blowfish for the reply (indeed, I think all my affected vessels had a B9PartSwitch on the root part, so this is possible) Well, your question inspired me to try and reproduce the issue and... I could not I am in the process of creating my own visual pack, taking assets and configs from various mods; I had disabled the Scatterer sunflare to work around the issue So I tried re-enabling the Scatterer sunflare: now the flare (Scatterer default, or other such as Sunflares of Maar) is shown properly with all new and existing vessels, regardless of B9PartSwitch I did not update either KSP, B9PartSwitch or Scatterer in the meantime, so not sure what changed... I will keep tweaking my visual config and post back if the problem resurfaces, but for the moment I am going to take a few screenshots of my Laythe space station!

Thanks @Nightside for confirming the issue! @blowfish I see you already discussed the issue in the Scatterer thread, something related to RenderProceduralDragCubes, did anything come out of that?

Hi! I love this mod and I am looking for a way to detach multiple connectors at once (for a Curiosity-style triple-winch landing) However, the "Detach Connector" option is not available to use in Action Groups, probably because it is a contextual option (it is only available when something is connected) Is there a known solution to this problem?

I am afraid this was already asked more than three years ago: I am looking into the docs and it looks like you can use LoadGame to get back a Game object through which you can then go; however, no idea whether or how this can be called from the Main menu... do you know where I can start learning about the APIs for Unity and KSP?

@ZodiusInfuser Awesome work! I am not sure that 30/45/60° variants are needed, because one can simply add a locked pivotron to obtain any angle; I am afraid that, by not restricting yourself to 90° angles, you are going to create too many seldom-used parts This is just my opinion, because I like having few parts with variants rather than many parts, but maybe some people feel differently

Oh I hope to see that sometimes! Thanks for the measurements! That will make it easier to use Precise Editor and ReCoupler On the grid size choice, I guess Ideally all the parts could be resized to 0.625m, but this would break saves... No idea about what people will more likely want to align with hubs, maybe more stock/structural than rotatrons? So I would prefer 0.625m

@Lisias can you easily check if any savegame contains any of the affected parts? There would be no need for an intermediate release, you could just show a big warning so the user does not open the bad save(s) and link to an explanation about the extra patches

Hi all, I posted in Scatterer thread but did not get any reply so thought I would ask here: does anyone else have issues (for instance with the sunflare) using the latest Scatterer and B9PartSwitch? Cheers

Hi, in case anyone is interested, I suggested a hack to fix the IVA for the Marble cockpit, comments welcome

@Rudolf Meier and one more minor issue: I think the surface sampler does not scale properly It works very well at the default size "Small", but when I tried with size "Small-" it did not work, always saying it was too far from the ground, even though it was pressed so hard against the ground that it tilted the entire spacecraft

Wow this is so exciting! OK, so I am trying to build some gantry cranes (like these, for instance) in order to load crafts into a plane's cargo bay, which requires structural hub parts (with more than 2 attach nodes) I believe there are two possibilities: A single 6-node hub such that unused nodes do not look bad (so you can use only the nodes you need); this can be achieved either with clever design of the model, or with a module that dynamically changes the model when a node is attached (like this module in Planetary Base Systems) A collection of hubs, here are the ones I can think of: 6-way, 5-way, 4-way flat, 4-way non-flat, 3-way flat, 3-way non-flat; this could be packed in a single part using B9PartSwitch (for instance like this) Please let me know if you want more input

@ZodiusInfuser I too would love to make crafts almost only with IR parts, however the main thing I am missing is a hub (like the Stock not-Rockomax micronode), is this planned? @Rudolf Meier I seem to have a bug with 3.0.1 since the KSPField variables were converted to KSPAxisField for use with the new axis groups: [Running KSP 1.7.1.2539 (Windows x64 DirectX3D) with MH+BG] IR is not moving attached parts in Editor in Actions mode: Go to Editor (VAB/SPH) and create/load a craft with: any root part =[attached to]= any IR moving part =[attached to]= any other part Move the IR part (either changing Target Position in PAW or using the IR Editor Window) and notice that the attached part moves accordingly Go to "Actions" mode (instead of "Build") in the top left Move the IR part (either changing Target Position in PAW or using the IR Editor Window) and notice that the attached part does not move Go back to "Build" mode and it works again

One more thing: I cannot find any reference to "&" as an operator The wiki says an operator can be either one of: nothing for insert @ for edit + or $ for copy - or ! for delete % for edit-or-create. What am I missing?

Thanks for the info! To be clear, I did not notice any impact beside the exceptions and the error messages, the HUD seems to be working fine

Wow thanks @zer0Kerbal for all the info! On NEEDS => yes my answer above was badly written, I got confused between you using FOR and not needing FINAL for ordering, sorry about that On re-writing "@name" => I did not know that was a best practice, and I do not understand what you mean by "it acts as an anchor", could you elaborate? On FOR => I agree that using it is a best practice, however I believe the name should correspond to the author: If I write a mod called "MyMod" which contains a TweakScale patch, I should use :FOR[MyMod]:NEEDS[TweakScale], should I not? Does :NEEDS[OrbitalTug]:FOR[OrbitalTug] not defeat itself? It simultaneously defines and requires "OrbitalTug"... I'm confused Cheers

@zer0Kerbal glad you liked it Last points: I was not sure about @PART without a name selector because I have not seen it properly documented, but if it works then it is fine This does not do anything and can be removed: @name = ModuleCommand The FOR clause is reserved for the mod author, it tells ModuleManager that the config is part of the OrbitalTug mod (mainly to be able to use OrbitalTug in BEFORE/AFTER/NEEDS clauses), you should not use it in your custom patches; the NEEDS clause should be enough to make sure that the OrbitalTug parts are loaded before your patch applies; if you want a FOR, it should be using your custom name like "_Me" or "ZZZ_CustomPatches" or something (but it should not be necessary) If your patch works without FINAL then I agree that there is no need for it

Hi every one, There is an issue in the RealPLume config for SXT because SXT's Munar module was renamed when Squad released their own, see this GitHub issue Since I understand that this mod is no longer updated and the fix is as easy as can be, I encourage SXT users to edit their RealPLume config accordingly Cheers

Hi @allista and thanks for all your mods! Just a quick CKAN question: versions 2.4.0 and above are listed as compatible with KSP 1.7.2 only (not 1.7.1 or 1.7.0), is this real or will they work in 1.7.1? Cheers.

Hi @allista and thanks for all your mods! Just a quick CKAN question: versions 2.4.5.1 and above are listed as compatible with KSP 1.7.2 only (not 1.7.1 or 1.7.0), is this real or will they work in 1.7.1? Cheers.