Starwaster

inflatable hab or lab space? Going to say NOT airlock since there is a hatch on the other side as in the LK.

It's a matter of creating a set of ROC_DEFINITION configs with appropriate Frequency values so that they spawn in appropriate numbers that won't tank your CPU or FPS. There is an issue which aggravates performance issues when on oceanless bodies that Kopernicus will address in a later update. (note actually related to the ROC issue but the issues compound each other) Also, RSS would require a set of terrain quality settings appropriate for each planet; I think there was talk about that happening. Finally, there's a value in each player's settings.cfg which would probably have to be modified to an appropriate value to further inhibit unwanted ROC spawning but it's not patchable by ModuleManager so would have to be set by the player or possibly by plugin... I've thought of proposing such a change for Kopernicus but haven't had a chance to put together the request. (I'd want to be able to suggest a precise course of action) So, TL;DR it's totally doable and a player could probably even do it on their own but in the absence of an official solution (which is doable) would have to deal with performance issues on their own as well.

You can do that if you want. I'll see about making a .version file. As I said earlier, there are probably NOT going to be a lot of updates to this. It's not going to be a constant 'in development thing' though it will be maintained if some KSP update breaks it. It's got config files now to handle USI MKS and can be easily extended to handle new classes for any mods that add them. The only other thing I'm wanting to do is add a button in its menu to force all currently employed KSP Kerbonauts to conform to the 'new dress code' as it were, in case they were already employed when the player installed the mod. Other than that it's finished product.

New SSTU release which fixes a negative mass compatibility issue with Real Fuels. Anyone trying to use SSTU with RF should download that update. The update is for 1.7.x but should work with 1.6.x as well.

@jdub3350 et al. new SSTU release which fixes the SSTU/RF negative mass issue I talked about yesterday.

Part of me is smirking and giggling.... (pretending I never did the same)

A wrecked habitat full of dead potatoes

It definitely does. It sounds like something is installed incorrectly. Maybe the old version of Kopernicus got in accidentally?

As @Darkherring says that is is NOT RSS. Another mod is responsible for that. There's no 'setting' you can adjust, you need to find the mod responsible and uninstall it. Install Real Fuels if you haven't already and download a proper engine pack for it. Since you're playing RSS I suggest downloading Realism Overhaul if you haven't already. (not an absolute necessity; you could get by with the stockalike engine pack and appropriately sized tanks) You don't say anything about what mods you have installed so it's not going to be possible to say anything further without more information.

@jdub3350 If you have SSTU tanks on that craft then certain tanks can trigger a conflict with Real Fuels under certain conditions.The conflict is that both SSTU and Real Fuels try to cancel out the mass on the tank prior to modifying it on the expectation that it will be offset by their respective resource switchers. Unfortunately the part has then lost twice as much mass as it should have which can push it negative. If there is not enough resource mass on the part to make the net mass positive then the Unity RigidBody will have negative mass and no forces can affect it. The Orion Service Module is a candidate for that issue as is the lander tanks. Spawn them each by themselves in the VAB with the same resources they had on the craft and then look at their mass in the engineer report. A more complicated method would be to look at the craft file and compare each part's modMass field against the part's original mass. If mass + modMass <= 0 then that's a problem. Edit: There has been a fix created for the SSTU issue but I don't think he's released an update with it yet. A verified workaround would be to identify affected parts and patch their mass to 0 with a ModuleManager patch.

@Jognt actually that’s been discussed in one of the issues on the GitHub page and is why I mentioned setting the speed limit to 50 above. It’s a scale related issue and the speed isn’t actually measured from the vessel. It’s the camera’s movement from frame to frame. For JNSQ it should probably be 125 but that’s an estimate. And (I suspect) may not work the same for all planets since as I understand it, several of JNSQ’s planets are new and not rescaled? On a related note even if the speed fix I detailed is applied, pausing the game while at an altitude that ROCs can spawn at but above the speed limit will result in all quads within range spawning ROCs since for a brief frame the camera will have a speed of zero. I am certain that one is pure stock and should be reproducible in stock except that it’s harder to meet the necessary conditions and the impact will be negligible. But if anyone ever does notice such a patch spawning after pausing the game? That’s why. And there’s nothing to be done for it.

@Jognt actually that’s been discussed in one of the issues on the GitHub page and is why I mentioned setting the speed limit to 50 above. It’s a scale related issue and the speed isn’t actually measured from the vessel. It’s the camera’s movement from frame to frame. For JNSQ it should probably be 125 but that’s an estimate. And (I suspect) may not work the same for all planets since as I understand it, several of JNSQ’s planets are new and not rescaled? On a related note even if the speed fix I detailed is applied, pausing the game while at an altitude that ROCs can spawn at but above the speed limit will result in all quads within range spawning ROCs since for a brief frame the camera will have a speed of zero. I am certain that one is pure stock and should be reproducible in stock except that it’s harder to meet the necessary conditions and the impact will be negligible. But if anyone ever does notice such a patch spawning after pausing the game? That’s why. And there’s nothing to be done for it.

The one that cuts the frequency of ROCs in half? No way that would have caused a 'black screen'. That output_log.txt file you uploaded was way too short. When uploading a log, make sure to run the game through to whatever problem you're troubleshooting until the problem is reproed (in this case, black screen) and then exit the game to ensure the entire log is flushed to file. I'd bet there's errors being spammed in there, maybe relating to KopernicusStar. Or depending on if the ocean fix is still in there somewhere and it patched the sun or Jool then that would do it also. But the one I provided doesn't touch Kopernicus, only the stock ROC_DEFINITIONs on each planet. The other thing you described where you moved away from your landing craft and the lag stopped: That's the ocean thing. KopernicusBuoyancy causes lag on planets with no oceans. No, doesnt matter what order things were installed in.

@Aelipse Modify this to suit you. As is it cuts the amount in half. @ROC_DEFINITION:HAS[#Frequency[*]]:FINAL { @Frequency *= 0.5 } It's not really the right way IMO since the exact percentage to modify by should be done on a planet by planet basis depending on its size. But that will get the job done.

@Aelipse Edit your settings.cfg file and change SERENITY_ROCS_VISUAL_SPEED to 50 (default is 500) That should help a little by reducing the speed at which you need to be going before ROCs start spawning (a lot of the ones you are seeing in the statistics are areas you passed over and you're going quite fast) That might not be the most appropriate value for that setting but I don't know how much GU affects planet sizes and there are other factors. It may also be necessary to adjust the ROC frequency in their configuration file. That could be done assuming a global scale value for all planets but the way it should be done is on a planet by planet basis depending on their size. (frequency will affect them differently depending on planet size and terrain quality settings) No. Just use :FINAL

No, that will not work. You cannot use AFTER or any other phase operator that way. You have to give it a single pass to execute in.

@Jognt Sorry, thought I told you Kopernicus + SigmaDimensions + Rescale x10 That simple. The Mun is a good testing ground. Come in low (i.e. shallow) so you accumulate a good ground track of ROCs on your way down.

It's just a warning. Read it, consider yourself warned and close it.

UHM. WHAT? Why can't we? Stick a Kerbal in a plane with an open air seat and send him up! Of course the question can be answered. This isn't some esoteric ineffable mystery. Come on man.

Then you should check your console for errors. It's not physically possible to change the distance of the RCS lever arm (which is what you do when you move RCS closer to or further away from center of mass) and not see a change in torque. Also, suggestion, don't use the capsule RCS. Use only what you need to for each RCS situation (translation, attitude, etc) (and yes, the red circle arrow is bad when translating)

5 might not be enough... joint rigidity is affected by node size. A node size of 5 is probably satisfactory for up to a 6.25 meter tank but those legs are supporting the mass of two giant tanks plus the cockpit. On my installation I actually set them to size 8 but that was because I scaled up to real Starship scale and I don't see them wriggling around like that. Although I don't think I stressed them out the way they were in that video scraping them along the ground with the engines either. On the other hand, no matter what I do, the whole ship seems to drift. But very slowly and almost imperceptibly. On my next attempt I will have the friction at 100 and we'll see what that does. (my whole Kerbin is also scaled up too and I think that does affect the physics somewhat. I should probably be trying this with stock sized Starship + stock sized Kerbin but I just haven't been able to drag myself back there)

@damonvv try increasing the tail fin node size to 5 for all three fins and also for the nodes they attach to on the engine fairing. And have you tried enabling rigid connection on those parts and autostrutting?

Oh most definitely. I had one working the day 1.7.3 was released with multiple controllers to put it in one of several positions. (one to do 'inchworm' movements and another to shift it 90 degrees over to another row of ports - having WBI's snapshot capability is very interesting since I can potentially replace 3 controllers with 1) So there's definitely something going on with the More Servos parts. I've also seen some other issues with the arm servo parts in the VAB which I suspect are problems in the model hierarchy but I'm still identifying them so I can properly report them. Issues such as discrepancies what axis the servos rotate around when using different attach nodes. Example: Mount a Mk1 Effector with its grapple end attached to a craft and its base pointing up. Slide the target angle. It should only rotate around the forward vector but instead also rotates around the up vector where forward is actually pointing up and 'up' is north/south. Anything attached to the base is also rotated around the up vector. (again, where 'up' isn't what we think of as up but rather what unity says is up) I'll post more about it later with some screenshots but I'm not very organized right now.

1.7.3 which is why I re-ran the test with stock replacements (except for the micro port. I can try replacing that but as far as I can tell it doesn't do much besides being a docking port and the model setup for those are fairly well known at this point, unlike the robotics parts were are still newish. <slow menace> I don't see how you can be so mistaken...

Here is the config that I've been testing. However I still see quite a bit of slippage. That could be because I need to experiment with the values or it could be an issue with terrain or launch pad physics. I'm not even sure how those are set up and on the one hand I've heard that terrain physics material hasn't been looked at since set up but the new physics material grippy pads are supposed to help so maybe terrain physics did get attention along with the grippy pad implementation. MODULE { name = ModulePhysicMaterial frictionCombine = Maximum bounceCombine = Minimum staticFriction = 1.1 dynamicFriction = 0.9 bounciness = 0 } The ones to look at are dynamicFriction and static friction. dynamicFriction is for when the thing is in motion already. staticFriction is for when it is still. The numbers are 0 (no friction at all) to 1 (full friction) However, staticFriction allows values higher than 1. I'm not sure if it actually has an upper limit. Also not sure if dynamicFriction can also be set higher than 1. Another caveat to my experiments thus far is that the BFR parts are scaled up to RO levels. Not sure what the actual diameter is; the rescaleFactor was 1.8 and the three parts were something like 20 tons each (dry). KSP devs and some other players I've talked to were of the opinion that the slippage was actually due to 'micro oscillations' between the parts and that increasing friction of the landing legs wouldn't help. I'm not ready to give up on that and will keep experimenting on and off as time permits.