Alewx

Sorry for the dump question just testing it out, would have made it clear, thanks for the quick repsonses.

Thanks, is the atmosphere also applied in the compact mode?

That can be done without any problem. This might be a bit tricky, but I think I have an idea after reproducing it. Hmm also quite tricky, maybe a check for the rootpart would already help. But massless parts were always a cheat, not sure that I can really solve that to 100%. EDIT: hmm the second INPUT_RESOURCE part is just ignored and not merged, that is why the value is wrong.

Hey there, I noticed a difference in the TWR of crafts from Editor to Flight. In the Editor the TWR is higher as in the Flight Scene; I made this with stock parts. it was without any staging. My testcraft is a RC001S an FL-T100 and a Reliant Engine. TWR in Editor is 11.46 and in Flgiht it is 10.71 KSP 1.1.2 32bit / 64bit

That is quite a massive request; editing modules on the fly and that generic is really few, that will need some planning. Does this happen also with "processed massless parts"? This octo strut is really a pain, that is not a problem of the selected partbranch just of this damn strut.

Update to UbioWeld Continued 2.3.1 Recompile for KSP 1.1.2 New weldedFlagDecal Module, works like stock one but with welded parts Adapted for B9PartSwitch partbranches are now centered at Z and X before weldment is done Download version 2.3.1 for KSP 1.1.2

Great, I just made my MM file to handle no longer FSFuelswitch but InterstellarFuelswitch.

With an IDE is is pretty readable. A new release will be possible quite soon.

@blowfish Thanks for the info, I give it a testrun and report back. Update: Tested your suggestion and it works flawless so far, big thank you.

To smooth out welding a bit more I want to add a new partmodule that will replace an existing one at runetime. public void clearDecalModule() { PartModuleList modules = part.Modules; PartModule pm; for(int i =0; i < part.Modules.Count; i++) { pm = part.Modules[i]; if (pm is FlagDecal) { if (((FlagDecal)pm).textureQuadName == textureQuadName) { part.Modules.Remove(pm); Destroy(pm); break; } } } if(HighLogic.LoadedSceneIsEditor) { GameEvents.onEditorPartEvent.Fire(ConstructionEventType.PartTweaked, part); GameEvents.onEditorShipModified.Fire(EditorLogic.fetch.ship); } else if(HighLogic.LoadedSceneIsFlight) { GameEvents.onVesselWasModified.Fire(vessel); } } Everything happens in the "public override void OnStart(StartState state)" and it runs very fine for itself, but just in the next frame I get an exception: It indicates that the list of partmodules does not get updated, is there a workaround for fix this problem or an alternative route? I appreciate every Adivce.

The CKAN guys handle that.

After reviewing the code of this snippet, I finally know what you were reffering to as the problem. First of all because Unity is working with floats it is not very common to get really precise values, especially with the positions of gameobjects. But depending on the tools that KSP provides maybe it is possible to relocate the whole part tree of the weldment to the origin and then get atlast the root at vector3.zero. EDIT: Implemented a repositioning of the weldment before the part is welded. Now there is just one last thing that is causing some trouble for me; a runtime removal of a module.

I test it as soon as I'm back home.

The model positions are the point where it begins. They are the root for everything else.

I will need to view that in VS when I'm back home, nodepad is not really making things clear.

Isn't that the usual case BTW I noticed that the new version for 1.1 does not contain CIT, did you change nodehelper to be standalone?

But maybe it could write a MM patch file that will provide the made changed with the next Startup of the game.

@PART[Kosmos_*]:HAS[!~node_stack_bottom[],!~node_stack_top[]]:NEEDS[KOSMOS]:FINAL { %bottom = #$node_stack_bottom$ @node_stack_bottom$ = #$../bottom @node_stack_bottom[5,] = -1 %top = #$node_stack_top$ @node_stack_top$ = #$../top } Seems to not work; I checked the testpart just to make sure It would work at all.

That is more something for a custom mod, as the colliders are part of the model, and not a module in the cfg file. It would require a new module that is connected to a mod that disables all the colliders in the part.

Thanks.

I want to edit the attach nodes of the KOMSOS parts so that they are properly useable. @PART[Kosmos_*]:HAS[!~node_stack_bottom[],!~node_stack_top[]]:NEEDS[KOSMOS]:FINAL { %bottom = #$node_stack_bottom$ @node_stack_bottom = #$../bottom @node_stack_bottom[5,] = -1 %top = #$node_stack_top$ @node_stack_top = #$../top } This is my patch to modify the nodes, but I'm not so sure about the index of the bottom node. Can anyone give me an advice?

Thanks for the info. That looks like, there is a problem with the loading of the button. Hmm strange, but I look into it.

This pack is truly beautiful and amazing, but the ring parts do not really align properly, the ring is not really closed when you attach the parts to ech other, even with the doubled dockingports. Is there any Chance of Fixing that?

I tried to remove a flagDecal module at runtime, and it will bug out the whole game to a point where physics are going nutts. I just can't find any way to remove this module at runtime, so you are not alone with this problem.

I fiddled around with source for a weekend, and so far it was not working. Getting this back to work seems to be a tougher task.