kcs123

Slightly offtopic, but each time I purchase CPU,motherboard or RAM, I put PC on stress test. Most simple and broadly available free test is 7zip archiver. It have benchmark function with ability to choose size of dictionary (iinfluence RAM usage) and number of CPU cores used. CPU usage is hammered to 100% most of time and I aim to use whole RAM as well, as much as I can (some need to be used by OS itself). And I leave PC to run like that for 1-2 hours. Not that it allows me to test hardware, if there is fault somewhere, but also to check if cooling works properly. Only for GPU if necessary I use some gaming benchmark, to test any faults in VRAM or overheating issues. After that, each PC worked for years with no issues at all.

It is hard to tell, SpinkAkron is busy lately, haven't be even able to visit forum in last week or two. Proposed changes may or may not be adopted in next mod update. I'm using those in my personal game and I provided those patches to help development when mod authors are able to make such changes. And to provide help for others, to customize their game if they want it until official mod update. That gave me inspiration for new part propsal. Thanks, @Steven Mading. When I was playing a bit more, I have created smaller versions of 2,3 and 4 way adapters. Basicaly, just scaled down of existing in game adapters. Those comes with trade-off, though, not ultimate solution. It will cost slightly more than if you use cubic truss to attach engines, weight is also increased, so you will end up with lower overall dV. But, it can help a lot with level one SPH/VAB building when you need to worry a lot about part count limits. TVR-200Ls Stack Bi-Adapter: TVR-300Ls Stack Tri-Adapter: TVR-400Ls Stack Quad-Adapter: And localization file with description for all parts:

I'm not sure if I understand question. What do you mean by "offset greater than 10" ? If you attach root of wing to the nose, it is quite possible to offset wing tip to be on tail (depending on wigspan). Is that what you wanted to ask or something else ?

@whale_2, with correct value for "isSwitchable = true", issue with PAW in SPH/VAB is solved too. It happen only with wrong set of variable values. strange thing is that with "isSwitchable" set to false it was also allowed to change settings, but with the PAW bug mentioned above. Not much of big issue if MM patches were properly made.

Correct, I was having several pieces of code opened and pasted wrong one. Filter is correct, though .

So, I come up with following patch that enable InnerLock module on all structural parts from IR next mod: Only for collision, there is separate parts already that enables connecting two parts of same craft. By default, collision is not enabled, but it is switchable in SPH/VAB, to allow you collision when you want one. So far, I didn't notice any performance degradation at all. But, there is small glitch with GUI in SPH/VAB. Whatever is chosen in SPH/VAB for collision to be turned ON or OFF, when you reload craft or when you revert in SPH/VAB from flight, you always have both options in PAW, to enable or disable collision, while only one option should be shown, to enable or disable, depending on whatever is current set on part. I'm leaving patch here for anyone else who want to try it and leave feedback about it.

I have yet to test everything a bit more to be able to give better answer. So far I didn't found much of misbehaviour. Probably plenty of mentioned bugs are already fixed. I can't tell yet if there is any major issue left and is it urgent to fix or not. There is several possible workarounds of this. Probably not worth to hold release if it require more time to fix it. It will be good if other people who have encountered issue tell more about it. So far, test with uncontroled joints does not show anything wrong.

No worries, no big deal, such small mistakes is not unusual to happen, especialy while maintain such large number of mods. CKAN bot is not picked up new files, have to wait a bit longer and then test everything again.

CKAN say that I have installed version "1.2.10.3" and latest available version is "1.2.10.3". And also say that max supported KSP is "any". That is correct. However, in directory "PreciseNode" when I open file "PreciseNode.version", inside I have this content: { "NAME": "Precise Node", "URL": "http://ksp.spacetux.net/avc/PreciseNode", "DOWNLOAD": "https://github.com/linuxgurugamer/ksp-precisenode/releases", "GITHUB": { "USERNAME": "linuxgurugamer", "REPOSITORY": "ksp-precisenode" }, "VERSION": { "MAJOR": 1, "MINOR": 2, "PATCH": 10, "BUILD": 3 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 4, "PATCH": 5 } } TimeStamp of file is 06.06.2019 02:20 if it helps. It is listed as max supported version is for KSP 1.4.5. And when you start game, miniAVC complain about it and pop up warning message. I know that is nothing to worry about, but other users might complain about it. Just to be sure I have checked archive that CKAN is downloaded "B03E3A6D-PreciseNode-1.2.10.3.zip" and unpacked by myself and content in version file is same as shown. Am I missing something ? EDIT: On github, you have it properly: https://github.com/linuxgurugamer/ksp-precisenode/blob/master/PreciseNode.version { "NAME": "Precise Node", "URL": "http://ksp.spacetux.net/avc/PreciseNode", "DOWNLOAD": "https://github.com/linuxgurugamer/ksp-precisenode/releases", "GITHUB": { "USERNAME": "linuxgurugamer", "REPOSITORY": "ksp-precisenode" }, "VERSION": { "MAJOR": 1, "MINOR": 2, "PATCH": 10, "BUILD": 3 }, "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 5, "PATCH": 1 } } @linuxgurugamer, only archive file seems to be unproperly packed somehow.

Please, take some rest, you will overburn yourslef with moding. You already have slight oversight. Latest release, installed trough CKAN complain that I use unsuported version on KSP 1.7.1. Probably just silly mistake in version file.

Not bad at all at first sight. It is reasonably good looking, but is is not good 3D mesh model when you look more closerly facing topology. You will soon encountered issues when you need to create UV maps, normal maps and create textures. When comes to Blender I'm noob too, but I learned thing or two and it is not easy task to merge cylinder and sphere in Blender and to maintain proper facing topology. Now, that was a bit off-topic, but to elaborate it better, send me PM or open new topic in more apropriate place. I really don't want to discourage you, but rather to give you some tips to do it even better.

You might want to check this post, unfortunately in main thread: Keep note that symmetry can work different in SPH with default mirror mode vs VAB and default radial symmetry mode. You would want to check both. I didn't investigated much part placement in latest release, but old IR plugin and few beta IR releases were having issues that when you place part on left side, rotatron, bearings and such, rotating one side in one direction and oposite part will rotate in different direction. That can be solved by inversing movement on oposite part only. IIRC, in KSP 1.3.x, it was necesary to use always positive numbers. For example, part on left side have rotation for 60 degree and on oposite side you can't set "-60" degreee, you need to set for 300 degree, otherwise it will throw exception. That was one issue. Another one was, when you rotate some part placed in symmetry and grab parent part (non IR part stil in symmetry, some truss for example) and afrer that reattach it on craft, mirrored part can rotate to 60 degree instead of 300. Or it can be set to "-60" that was also not suitable for IR GUI. Now, take mentioned with grain of salt, that was issue from the past releases as much as I can recall. Some of those might be solved by now, I didn't have time to recreate some of crafts used in past. Foldable rocker-bogie rover is good example: Ups, wrong, that one is not foldable, just ordinary rocker-bogie. Following was just prototype from the past when joints were not strong enough: Not super comlicated stuff compared to other crafts around, but good enough as example for issues that might arise from symmetry.

Yep, I missed that upper filter, it is wrong too.

Have you tried with this: @PART[*]:NEEDS[DecouplerShroud]:AFTER[FerramAerospaceResearch]:HAS[@MODULE[ModuleDecouplerShroud]] { %MODULE[GeometryPartModule] { %forceUseMeshes = true %ignoreIfNoRenderer = true } } Using "%" instead of "@" would insert new module if same does not exist for part. Your example would only edit existing module. In other words, if part does not already have "GeometryPartModule" included in config file, using "@" will not create new one and it would behave like you didn't wrote anything at all.

Visible ones that you attach in SPH/VAB are not so bad. Issue is with invisible struts that were placed without your knowladge that were placed there. And, yes with KAS when you create/place parts it is always some new force involved, so have to be careful how and when you place parts.

Yep, I would probably not need more than 8-10 per craft, so I think it is probably fine performance wise. But, question is if some part have such switch to turn on/off collision and it is turned off, that should not affect performance at all, right ? Meaning, if I put that module on some structural parts, like truss or similar and using those to create craft without collision, it should behave the same as before without performance hit. And if I need to have collision on strategic places for 8-10 parts on craft performance should not decrease.

@whale_2, does MM patch from alpha to add inner lock module on any desired part still work ? Example: @PART[MyDesiredPArt] { %MODULE[InnerLock] { isPermaLock = false isSwitchable = false } } IIRC, above should add InnerLock module to part with collision switched off by default and it would allow you to turn on/off collision in SPH/VAB as needed for such part. Other concern is does such additional switch may cause performance issue if it is turned off ? I guess it will not or it would not be noticable impact on performance at all, but have to ask, just to be sure.

Can somone try IR Rail genty parts with KJRn ? Try to move them in both directions, positive and negative one.

APP mod might have more parts with same issue. Some are cockpits, but IIRC long time ago, I think that I found some tail part or fuselage part that was having same issue. I'm no longer sure, but could be worthwile to check other APP parts too.

And, try to rotate in oposite direction (I have some hunch about it).

Yeah, I noticed possible solution in last few posts, but I was not having time to test it and find exact part names for APP parts. I'm glad that you were able to find solution and provide help for others.

That question is more apropriate for FAR thread. APP does not support FAR directly, but other community members that use both, APP and FAR have made configuration files to support it. I assume it is something with either, mesh configuration or colliders, but can't tell more about it.

I would not put my bets on it. Status is changed to confirmed and "%done" from 0 to 10%. Since it took more than whole year to confirm bug, I'm not sure how long it will take to write down 20 lines of code. But, we can hope that it will be moved from idle to crawling or something.

Try to use wheels from Kerbals Foundry mod. Those have much less issues.

Thanks for clarification. It does not hapen so often, so logs should be able to hold additional spamm, I hope.