Starwaster

So change the epoch

You know, I broached that very subject in the RO Discord channel and the response was lukewarm at best. That aside, Kopernicus has some issues that can in certain circumstances result in tremendous loss of performance by enabling surface features (their proper term so as not to confuse them with terrain scatter) under circumstances in which they should not spawn and in quantities greater than they should spawn. So far the only viable workaround is custom terrain quality settings that can reduce the range at which they are created and by reducing the number of them created. That unfortunately tends to spread them over a wider area which makes the rarer ones harder to find.

There's an option to enable automatically reuse old parts. However some parts you wont be able to use old parts for because of issues where the SY inventory system doesn't recognize them as the same part. (Real Chute parts are almost guaranteed not to be reused because of a certain persistent field which changes constantly so SY thinks it's a different part)

Did they have a bunch of spiky things on the outer edge of some of them? And weird emblems painted on the bottoms of some of them? I have something like that somewhere and I don't much like them either.

Pack() or Unpack() are called for every part on the vessel (which does things like update colliders, joints and rigidbodies and other physics related things) Also, an event is fired OnPartUnpack which is received by any code in the game which is listening for that event. Uhm... quick search of Kopernicus code says it does listen for that event.... but I don't see it doing anything unusual or lag inducing. It replaces the stock buoyancy component with its own version. Something which would occur very quickly. Even if it did cause lag it would be transient and not long lived at all. If there were an error in that process you would see it in the log. Other than that I don't see Kopernicus interacting with parts during an unpack. Edit: Oh, and PartModules are all initialized during an unpack.

@Jognt Re: very high number of features: When I first reported that I was on a Rescale 10x. The more the planet is scaled up, the more features, all other considerations being equal. Regarding the issue about performance changing with distance from another vessel, it's just a case of another vessel in proximity to the Kerbal decreasing performance. It's not directly linked to ROCs but when you have multiple things going on in the player's vicinity then performance decreases tend to compound each other. But there's no direct interaction or correlation between the number of vessels and ROCs in the area. They just don't interact that way. (I spoke with one of the devs on that subject after you mentioned it). Now, I do notice a graphical framerate drop when a vessel loads in (or increase when it unloads) but for me it's marginal and doesn't impact performance at all As far as feature quantity; I was under the impression that it was computed per quad loaded in but if there are fewer of them when there are more quads then maybe that's not the case. And my gender, since you seem confused, is male.

Two words. Inverse. Kinematics.

I think the Duna Direct parts have something like that? I'm still holding onto the hope that someone will make this:

Maybe try experimenting with ModulePhysicMaterial? It's what the grippy things use; increases friction so they don't slip as much.

Get RCS Balancer. It has a mode for standard engines and it will tell you if the thing will torque or not under engine thrust. If you don't have it it is a MUST

@Jognt but you can't have JNSQ without Kopernicus... you can't do stock + JNSQ only. No Kopernicus means no JNSQ

@Jognt on JNSQ_High I'm seeing right now in the Lowlands 24/1/2 JNSQ 0.7 Kopernicus 1.7.3-1 same MFI Remove Kopernicus? No, but go ahead and make a stock copy of your installation and see what you get. On average on the Mun you'll probably see 120-200 features and they'll be in a tighter space (fewer quads). One thing JNSQ is doing is cutting the number of ROCs by 1/4. Presumably he did that because the surface area is 4x so you get 4x as many ROC. Which by itself wouldn't be a problem if they spawned in under the same conditions that they do in stock but they're not.

@Jognt I just don't get why you'd be getting so much more ROC than I am on the same setting... I just went and put it on High (High High not JNSQ_High) and right now I'm only getting 190... maybe it's the part of the Mun I'm on. Maybe they're just sparse here, I dunno...

Or maybe because it's drag stabilized?

@Jognt @Diddly Feelerino Ok, with the JNSQ presets in JNSQ I'm not having significant performance issues and can't replicate the issue you guys have with vessels. The anomalous issue I had with JNSQ_Default was because I had restarted KSP to test a fix for an issue with the scan arms not being able to scan surface features. (remember how I said it wasn't an issue if it only affected the debug screen? Well, it affects the arms too) So, now that I fixed that issue I was getting some framerate loss with the scan points debugger turned on because apparently there's a good bit of graphical overheat in drawing all of those debug arrows. Surface Feature Finder is probably has some overhead too but not as bad because it only has to draw 1/5th as many indicators. (actually probably less because the Mun craters have at least 4x as many scan points as the stones do. I'm also not seeing anywhere near as many features as you are Jognt. You mentioned a total of 640 and I'm only seeing 33 right now. (That's grounded though; might see more coming in for a landing...) Can you double check that it's actually JNSQ_Default enabled? Look in Settings.cfg for preset = . With the menu issue only the actual settings file is a reliable indicator

Just Press F12 (or alt-F12) and look under performance

Yeah, I think I'm getting better performance with JNSQ_High but I didn't want to say anything until after you answered because it doesn't make sense.

@Jognt What happens if you use JSNQ_High?

Too flexible or too slippery?

@Jognt vessel packing AFAIK happens at a further range than that. But shouldn't matter unless there's something about the vessel itself causing lag aside from the issue at hand. And regarding that the only vessel that I am aware matters in the equation is the active one, in this case Bob, your EVA'ed Kerbal. Whether ROCs spawn and how many are spawned are calculated from the active vessel's position. Regarding the scanner arm, I don't suppose you had a chance to test that? If it's JNSQ then I know why the scan point error is happening.

640 total surface features is indeed pushing things a bit for performance sake spread over 128 quads. However since you mention that was in low orbit you have ROCs still loaded in that probably would have unloaded in stock. The most accurate reading is IMO going to be loading in a saved game where you are landed. It will take time for statistics to load in under those conditions. Maybe longer than if in stock. The issue with surface feature scan points has to do with visual feedback for the scanning arm scan points. If it only affects the statistics screen then it's not serious. But if you are unable to scan things with the scanning arm then yes that is very serious.

No, it LED to this issue because using custom presets was talked about as a possible remedy. When errors start getting thrown while changing the menu then it's only natural that people start talking about THAT.

This segment of the discussion was only focusing on the terrain menu setting itself; I don't think ANYONE actually suggested that THIS had to do with people's performance issue. We were only discussing our experience with the terrain quality menu setting.

That's what I'm seeing now too. It worked once and I thought it was working on subsequent occasions but it's not. And, adding those kinds of presets to the TERRAIN section by hand is also supposed to work but is not. Adding presets by hand is even something that has been suggested on these forums by knowledgeable people but when I try to add presets by hand now, it behaves exactly the same as what you're seeing. The way Kopernicus adds them is through code and then (I think) KSP is writing them to the Settings.cfg file itself. So something broke somewhere and I'm guessing it happened fairly recently. Looking at the relevant Kopernicus code, I think that what is happening is that on subsequent game restarts Kopernicus detects that the new presets have been loaded by KSP and so it doesn't go through the final stage of adding them. (after all, why add them a second time?) So what it looks like to me is that this is a new KSP issue rather than a Kopernicus issue. Hopefully it's possible to do a workaround through Kopernicus. We should make a new issue for it on the github site. Edit: Tried it one more time just to confirm: Delete Settings.cfg (or delete TERRAIN secion should do same thing but I did the entire file) start KSP and it works once;. The new terrain quality presets can be accessed. After that when I start the game a second time and every time after that, there is an array index exception (IndexOutOfRangeException) when moving the slider past High. So KSP is loading enough of the list to populate the menu slider but is not loading more than the first three default nodes. Edit #2: So as things are right now, the only player workaround seems to be to one of: Delete the entire settings.cfg file before starting KSP each time Delete just the TERRAN section. (don't screw it up!)

Same. Also, some of @OhioBob's postings on nuclear rockets on other forums were used in the early days of Real Fuels to determine engine stats for alternate propellants