Tau137

July 26, 2019

Ignore

January 6, 2018

2 minutes ago, linuxgurugamer said:
Ummm, if you looked at the configs, you would see that TweakableParachutes isn't installed if RealChutes is. Look at the moduleManager.configcache file:
@PART[*]:HAS[@MODULE[ModuleParachute]]:FOR[TweakableEverything]:NEEDS[!RealChute,!FerramAerospaceResearch]
{
	MODULE
	{
		name = ModuleTweakableParachute
		deploymentFactor = 1
		semiDeploymentFactor = 2
	}
}
I'm postring results of some tests in the TweakableEverything thread

I have been suspecting that there is something odd about latest MM 3.0.1 (have been having issues with patches not being applied, error where were none before), but.... yes, need more testing, logs etc...

January 6, 2018

@linuxgurugamer:

FYI: there is confirmed mod interference with ReaclChutes - stock parachutes drag as if semi-deployed even before activation (mod-added RC chutes work fine). Removing corresponding dll and config (even config itself messes RC-enabled stock chutes) from TweakableEverything resolves the problem. I believe this is new to 1.3.1, as I used both in earlier game versions with no issues.

Also reported in RC thread.

January 6, 2018

11 hours ago, stupid_chris said:

Absolutely can't reproduce this on my side. Remove every other mod and try this on a clean new game, if it still happens I'll take some logs and see whats up!

Change the maxTemp in the materials config, in the RealChute folder

Found it - TweakableEverything (parachute config and dll). Removed, as there is no need for it with RC. Thank you!

January 5, 2018

@allista: Are you aware that you are using wrong conversion coefficients for Monopropellant? You took them from stock mini-tank, and that is ~~the only one~~ (radial tanks are pretty bad, too) that holds almost 3 times as much as it should have, compared to all other containers?

As a result, all other non-RCS container (stock and mode), after you patch them, can hold almost 3 times as much RCS fuel as they were supposed to, by volume, and all formerly RCS tanks (except the mini stock one) can only hold 1/3 of other resources (e.g., LFO).

If you consider this important (few people would care, presumably, except perhaps those that use NF Spacecraft, where this miscalculation gives almost cheat-leave advantage to monoprop engine over LFO, e.g., on landers), please correct the MM patches; stock mini-rcs tank can be either left extremely overstuffed or, optionally (at your or end-user's choice), nerfed to its proper volume of ~160L.

I also noticed some glitchty behaviour with TweakScale, where parts with configurable containers, when cloned in editor from resized parts, get scale factor applied twice (^2) to container volumes... have not figured that one out yet, but it is not a big deal.

Otherwise great stuff, I have almost everything "configurable" now, helps a lot with keeping part count low. Thank you keeping up great work, on this and your other mods (I just wish you'd enable orbital option for Ground Construction...)

January 3, 2018

@stupid_chris:

BUG: with the latest RC version, all stock parachutes drag as if semi-deployed before activation. RC chutes work correctly. No physics-altering mods installed,.

I checked everything but could not find the root cause (part files, MM patches for RC and Tweakscale, compared to 1.3 configs - everything looks the same).

I wonder if anyone else experienced this?

September 22, 2017

13 minutes ago, linuxgurugamer said:

You can just remove the dll for the docking nodes and leave the others if you want, it was designed that way

But, a log file can still be useful

Thank you for quick response and the tip, I will certainly do that. Just looked at the log again - nothing but loading messages for this mod, but here it is (from a crash as I did not have others stored, but that should not matter - crash is unrelated).

https://www.dropbox.com/s/fs48g6m28adqm85/output_log.zip?dl=0

September 22, 2017

@linuxgurugamer: Love this mod (mostly used it to cheat reaction wheels and engine gimbal limits), as well as other great work you do,

BUT

...most docking ports (stock) stop working at random. Might connect once or twice, might never connect (fresh ports, no tweaks). Trying to re-dock multiple times, reloading or restarting the game does not seem to help; moving ports with KIS sometimes does. The more complex the ships are, the more likely ports stop working (permanently) - e.g., trying to re-dock interplanetary crewed ship (~70 parts, 5 ports) with its lander (~25 parts, 1 port) is almost impossible). Analyzed everything, scrupulously went through saves, compared before and after, "good" and "bad" ports - nothing wrong, but they still wouldn't acquire! The only extra module in docking ports was from this mod, so I tried removing the tweakabledockingnode (or what's its name) from saves - no change. So I removed the mod completely, and not a single docking issue since.

No reason to post logs, as there is nothing relevant (no errors, nothing about docking or this mod, even in verbose mode) in there, and, considering semi-random nature of this bug and a number of mods I have, saves wouldn't be useful either. This bug has been present since at least 1.2.2, but only now I could pinpoint the culprit. My mod list is below. I hope this might help you to track down the issue.

Spoiler

000_AT_Utils
000_Toolbar
000_USITools
AirlockPlus
AirplanePlus
AquilaEnterprises
ASET
AtmosphereAutopilot
AviationLights
B9_Aerospace
B9_Aerospace_ProceduralWings
B9AnimationModules
B9PartSwitch
BetterBurnTime
BetterTimeWarp
BoulderCo
Chatterer
CommunityCategoryKit
CommunityResourcePack
CommunityTechTree
CommunityTraitIcons
ConfigurableContainers
ConnectedLivingSpace
ContractConfigurator
ContractPacks
DavonTCsystemsMod
DeployableEngines
Diazo
DistantObject
DMagicUtilities
DynamicBatteryStorage
EasyBoard
EasyVesselSwitch
EditorExtensionsRedux
EngineLight
EnvironmentalVisualEnhanceme
EvaFuel
EVAStruts
Firespitter
FlexoDocking
FlightPlan
FMRS
FShangarExtender
FuelWings
GroundConstruction
HeatControl
HideEmptyTechTreeNodes
InterstellarFuelSwitch
JSI
KAS
KAS-1.0
KerbalAtomics
KerbalFoundries
KerbalHacks
KerbalImprovedSaveSystem
KerbalJointReinforcement
KerbalReusabilityExpansion
KermangeddonIndustries
KIS
ksp-advanced-flybywire
KSPWheel
Landertron
LETech
MagicSmokeIndustries
MainSailor
ManeuverNodeEvolved
MarkIVSystem
MechJeb2
MiningExpansion
Mk2Expansion
Mk3Expansion
ModRocketSys
NavBallDockingAlignmentIndic
NavHud
NavyFish
NearFutureConstruction
NearFutureElectrical
NearFutureLaunchVehicles
NearFutureProps
NearFuturePropulsion
NearFutureSolar
NearFutureSpacecraft
OPT
PersistentRotation
PlanetaryDomes
PlanetShine
PortraitStats
ProceduralFairings
ProceduralParts
QuantumStrutsContinued
RcsSounds
RealChute
RealPlume
RealPlume-Stock
ReCoupler
RecoveryController
RetractableLiftingSurface
SCANsat
scatterer
ShipManifest
ShowAllFuels
SmokeScreen
SpaceY-Lifters
Squad
Squidsoft
StageRecovery
StationPartsExpansion
StockVisualEnhancements
StretchySNTextures
SXT
TacFuelBalancer
TacSelfDestruct
TakeCommand
Targetron
ThrottleControlledAvionics
ThroughTheEyes
ToadicusTools
TokamakIndustries
Trajectories
TriggerTech
TweakScale
UbioWeldingLtd
UmbraSpaceIndustries
VanguardTechnologies
WaypointManager
Workshop

deltav.ksp
MechJebAndEngineerForAll.cfg
ModuleManager.2.8.1.dll
ModuleManager.ConfigCache
ModuleManager.ConfigSHA
ModuleManager.Physics
ModuleManager.TechTree
stockEngineGimbalIncrease.cf
toolbar-settings.dat

July 6, 2017

Just now, OhioBob said:

All bodies in KSP have axes that are normal to a fixed reference plane. It's possible to incline a body's axis relative to its orbital plane by inclining the orbit. This is how the mod RSS simulates Earth's axial tilt. RSS inclines Earth's orbit 23.5 degrees, thus giving it an apparent axial tilt of 23.5 degrees. However, this technique is very limited. All bodies still have their axes pointed in the same direction. So if all the orbits are inclined similarly, all bodies will have similar axial tilts. It's impossible to vary the tilts from one body to another.

...

I've heard that KSP may eventually add axial tilt, but I have no idea what the status of that is, or how it will be implemented.

Neat, I did not know that (never played in RSS), thanks!

July 6, 2017

1 minute ago, JadeOfMaar said:

Sad reality. Kopernicus gives us many things, but that's not one of them.

Thank you for the explanation!

July 6, 2017

3 minutes ago, JadeOfMaar said:

Axial tilt cannot be done in KSP. If any planet looks tilted it's because it's likely a gas giant with a deceptive texture and its rings alone are tilted and rotation-locked.

I was pretty certain Kopernicus allowed that... or used to allow?

July 6, 2017

A question: what is the easiest way to introduce rotation axis tilt on planetary bodies in an existing config (e.g., SVT or OPM)?

May 29, 2017

20 hours ago, Ruedii said:

Yes, the visual enhancement mods will drastically increase the amount of function done per a light source adjusting your rendered light count (in the settings) to something sane (usually 8 or 16) will often drastically improve performance.

This is interesting, but, presumably, graphics (local lighting etc.) would not be calculated in map mode (which is clearly seen in testing, when "time per frame" decreases somewhat, but not enough). And I do not believe I saw any difference between stock settings (8 light count?) in 1.2.9 and my regular setup with that settings maximized (1.2.2).

So the core of the problem is not rendering or GPU, it is how mods calls are made (apparently quite irrationally, somehow linked with part count and physics where they should not be). Probably need to make a test with all the mods I can find that have nothing to do with physics or graphics.... just need to yet again overcome this dreadful combination of feelings I have towards KSP - addiction, adornment and frustration.... probably soon, with 1.3 once a reasonable number of mods is updated.

Also would like to thank everyone who looked into this thread and started thinking about it (and/or testing) - perhaps we will get something (performance improvement) out of it, eventually, in future versions, assuming Squad ever resumes focusing the development towards more depth and refinement rather than breadth and accessibility.

May 15, 2017

@diomedea Thanks for the voice of reason. On my part, I will try to be less passive-aggressive.

May 13, 2017

14 hours ago, Ruedii said:

How about you not question my competence to begin with? I only replied at the start to be nice.

The probem IS in Unity, and if you search Unity GC issues you would find thousands of articles on it.

Instead of trying to accept a person's help you are picking a fight with them, WAY TO GO!

Thank you for your insightful and extremely informative response, it is greatly appreciated!

May 11, 2017

10 hours ago, Ruedii said:

First, I know for a fact you are mistaken on that one. Specifically Vanguard Parachutes is not available for 1.2.2 specifically due to exception errors. There is a complete from-scratch rewrite that I provided a link to.

Second, Things don't necessarily appear in the output log as far as you can tell. NRE Exceptions and bad call exceptions only appear in the Unity Player.log, not the KSP's output log, and definately not the Operating System output log.

Finally, if you don't know what GC problems are, then don't question me about it. GOOGLE IT! I'm not going to explain basic computer concepts to someone. Let's just say KSP isn't the only game affected.

GC operations are memory-bandwidth bound on the main thread, meaning one CPU will be running at about 1/4-1/2 capacity, shutting down all background activity by the game engine. I can go into detail about Unity's archaic GC engine but you can find plenty of complaints about that online as well, and even some articles from last (finally) fall promising a fix "soon." You may notice this is a topic that makes me irate, because I know there is nothing Squad can do about it without paying a fortune to have Unity create a replacement GC at top priority.

Anyways, KSP does not support multithreading on all operations, especially with mods. (Many mods are called in manners that create world-freezes this stops all background activity. This is something that can only be fixed by the mod developer or a contributor who knows coding if the mod is open source.)

As a note, for the person who is having trouble with Kerbal Alarm Clock, there is one function that can be quite heavy on KAC that can be fixed. By turning down the update times of certain things in the options for KAC you can drastically improve performance. I'm thinking of filing a request to put the mod on a timer other than the frame timer to boost performance, and to move as much of it as possible to a helper thread. I need to look up the exact timer call to completely offload it to a helper thread.

1. Irrelevant, as it does work. Also irrelevant because it was not used it the test cases presented.

2. Yep, never argued that.

3. Google! Yes, I never realized it exists, thank you!

KAC: this one was brought up as an example of a mod that should not be affected by part count, and yet there is a noticeable hit. Same way as EVE, in theory, should have a "constant" (not dependent on part count) performance hit.

Let's consider this simple example: stock vs. visual mods (EVE+Kopernicus+SVT), huge craft.

Let's further simplify that each frame game spends most of cycles on graphics and physics.

STOCK: 50fps, 20ms per frame. P+Gc+Gu=20 (Physics, Graphics-craft, Graphics-universe)

MOD: 20fps, 50ms per frame. P+Gc+MGu=50 (modded graphics - universe). Result: MGu >= 30ms

Now let's fly the simplest smallest craft possible (P2+Gc2 << P+Gc):

MOD: 60fps, <17ms per frame. P2+G2 + MGu = 17. Result: MGu <= 17ms

Anyone else noticed an inconsistency? Somehow the mod graphics (terrain & clouds) work twice as slow for 300 part ship vs. 10-part ship! Or we have to assume that somehow Physics depends on the presence of modded graphics. Either - or, as these mods do not touch physics or craft rendering.

Some might say (or direct me to Google) something regarding 3D rendering and how it is done and why computational complexity of drawing an object within a background scene would be affect by the way background is drawn. True, but only partially, and most importantly.... absolutely irrelevant to the argument, as the performance problem remains even in map view with almost nothing to render!

Now, what else have we missed so far that can explain this? Perhaps collisions (Kopernicus), that could explain it.... except it does not, because the same behavior is evident without Kopernicus, with just EVE, or with a bunch of mods that have nothing to do with part count whatsoever, and yet each adding a bit of lag on per-part basis! I do not have fps numbers handy for these - I might have time to get those, too, and I encourage everyone to test this "assumption" themselves!

Conclusion: physics (or something else related to part-count) is somehow affected by presence of graphics (and other) mods. This means that something out of these mods is being called in each physics processing iteration!

And THAT is the problem I am trying to bring up here. So, instead of misdirecting and implying my utter incompetency (it is only partial, not total), would you be willing to run similar tests and present results here? The purpose is to either:

1. Prove that the problem is specific to my computer and vast majority of users are not affected. If that is the case, I'll gladly admit that it is "my" problem, and will shut up.

2. Bring more factual confirmation that the problem does exist. Perhaps it is Squad coders' mistake, perhaps it is an inherent Unity issue - I do not know (again, Unity and C# programming is definitely not my strong sides), but that is even more reason to get devs' attention - in the interest of all players, especially those who actually do extensive career and exploration sessions and build ships and stations with hundreds of parts, those who love the game and want to make it better - even if all they are able to put in the pot is a few tests and observations.

May 8, 2017

On 5/2/2017 at 7:38 PM, Bornholio said:

Are you running in Dx11 mode? Make sure its 64bit. (KSP_x64.exe -single-instance -force-d3d11)

I'd suggest running Memgraph mod. Make sure you learn the hotkeys (alt *) and read its usage OP.

Large part count i move on to using Welding mod to get rid of unneeded part complexity. Again read the OP for the mod or you will make mistakes.

Thank you for the tips, I will check out Memgraph.

I always run x64, but not forcing DX11. I should test DX11 and OGL and see if that makes any difference.

My main concern is that even utility mods slow the came down in proportion to part count (how clouds can be so much slower on 300 part ship vs 10-part ship? Why it is noticeably slower with just Alarm Clock?) - the rest is kind of self-explanatory, given that any improvement demands some performance sacrifice.

UboWelding - I use it occasionally, but its limitations (graphical for animated parts, and need to restart the game - and that takes at least 5 minutes with my 2GB mod setup... with the game installed on SSD) make it not ideal for routine tasks, mostly useful for one-of-a-kind space station or IP mission (and those I tend to assemble in space with KIS and Konstruction, and would like to start utilizing GroundContsruction more, but it has one annoying glitch that throws exceptions on part count changes).

May 3, 2017

Question/poll: how much effect does KJR have on your framerate? At what rig specs? Example:

Intel E5-2690 2.9-3.8GHz, 16GB RAM, GTX780

300-part plane on runway and in flight (six A300s linked in one airsnake). Stock:50-35fps. With KJR: 31-12fps. Flying Aeris3A - 60fps either way.

Same thing in 1.1.3 (just a bit slower overall). Another interesting observation about stock 1.1.3 that I completely forgot - the joints flex a lot less compared to 1.2.2 with rigid attachment enabled on all parts (no autostruts, as they tend to twist and warp my ships - quite literally - after prolonged timewarp)! Almost feels like I do not need KJR there... almost, and that is only true for light planes, not for heavy rockets or SSTOs.

@ferram4: is that normal? Also, are there any plans for KJR-lite, something that just takes care of the Kraken (if that is even needed since 1.2) and tweaks stock settings instead of going full-bore with proper connection recalculations? I can live with some flex but not with 12 fps ()and yet cannot live without KJR in 1.2.2), and 300 part count is not uncommon for my stations and IP missions...

Of course there are also issues in general with how KPS handles active mods (slowing game down noticeably for large vessels for mods that should not depends on part count at all, such as EVE, Kopernicus packs or even utilities such as KAC), but that is a subject of a whole different thread.

May 3, 2017

On 4/20/2017 at 10:06 PM, digger1213 said:

So, I just decided to try out 64 bit KSP to see if I could get any better FPS with my large (or rather, small but high part count) base on Minmus. I found there was rather little difference in FPS anyway, with an increase of maybe about 3 fps, still below 30. Does 64 bit support CPU multi threading? What effects does 64 bit actually have on the game? From the little bit of reading I have found, it appears that it only effects ships, with each ship getting its own thread.

Anyone actually use 64 bit?

x64 uses more RAM, but, on the other hand, is not limited to 3.5GB cap as 32-bit version is (only relevant if you use mods). I have not found any difference in performance/fps between the two.

May 3, 2017

On 4/23/2017 at 6:08 PM, ZooNamedGames said:

I want to give a bit of a message to the developers of Kerbal Space Program. One not of complaint, inquiry or demand, but rather of praise and appreciation. I may not be a game developer, but I can rationalize the struggle, the hopes and sleepless amount of effort that goes into games, especially ones like Kerbal Space Program. I just want to share my adventure that came with Kerbal Space Program. I know of the strain the developers are under and I'm hoping this honest heart felt story will help let the developers know that there are members of this community who don't like what Squad is doing for us, but are happy, appreciative but are truly made better as people in this world because of their silly game of green men conquering their solar system in death traps we call "rockets

Please: less praise (after all, every one of us have already given them our support in monetary form; some people - more than once), and more push towards quality and accountability, otherwise they will keep sitting on their behinds focusing on commercially and politically appropriate localization efforts instead of actual game development. "The old guard" is mostly gone, and the tendency towards bureaucratization of the whole thing becomes more and more apparent with every passing month.

May 3, 2017

On 4/23/2017 at 10:41 AM, Numerlor said:

Just started career with research buy in and I'm wondering if it is any use. Only thing that came to my mind is small manned ion probe that wwould need it to survive re-entry

I have never used it. Presumably, it could be useful for science return capsules, but not much beyond that.

May 3, 2017

1. Play the game, keep failing

2. Watch Scott Manley

3. Play more, read articles on orbital mechanics

4. Research and install essential mods. watch a lot of youtubers for learning and new ideas

5. Play the game, get some hands-on experience using what you have learned (see above)

6. Enjoy!

May 3, 2017

Two days ago, I finalized my mod setup for 1.2.2 and did a lot of performance testing. Yesterday and today, I argued with a moderator about his "excessive use of force" on my (quite benign) comments

May 3, 2017

Once you've done this a few times (and/or have Kerbal Engineer or MJ to get all the TWR and DV stats needed), there is really no need for abort sequence in 99% of launches. And if you do something really ~~weird~~ non-conventional, it is likely not going to save your green dudes anyway. Essentially, it is just a homage to real space programs - cute, but rarely useful/used is KSP, unless it is your first playthrough, or if you are a real stickler for no reverts and no quicksaves (and even then, for complex accent vehicle you will need quite elaborated escape sequences; pis is part of fun, just depends on hoe much time you have to play and how much of a masochist you are). Just IMHO.

May 1, 2017

8 hours ago, Ruedii said:

First: One of these mods is obsolete and is thus throwing an exception on a regular interval.

Second, you have a mod creating a lot of garbage due to changes to the version of Unity3D (The dev-kit used to make KSP).

GC Cycles are memory bottlenecked and operate solely on the main thread (thus only use one core). During this process all other parts of the game are temporarily stopped. Under normal situations these cycles are so quick you don't notice them, but when a mod is using a lot of script variables instead of using static assets, it has much more to check, and often much more to clean up.

You can check if it's the GC by checking the performance tab.

First - not applicable, all mods are latest and greatest, compiled for 1.2.2 (the only exception is KJR, 1.2.0). I guess I should have stated that in the first place, but I presumed that to be self-evident (for every self-respecting and at least somewhat experienced KSP player).

Second - reasonable assumption, but I cannot localize ONE single mod(s), and there is no garbage in the output log (does not negate your argument completely, but still) - it looks like EVERY SINGLE mod I add creates more problems/slowdown (I can even see slowdown on high-partcount ships with just KAC(!) installed).

GC Cycles... does not help me to understand why the performance is so abysmal on my rig, while not being neither graphically nor CPU bound. Surely, if I have a mod that is not optimized and, on every cycle, keeps pulling a lot of info or doing a lot of stuff - that could be a culprit. But how would a visual enhancement mod (textures, clouds, shaders) be so much slower on a large ship compared to a small one (even though the mod has nothing to do with object interaction aka "physics", and there is a plenty of other objects/vertices to render in the scene, so part count on the vessel should not matter that much - after all, somehow I get better fps flying around KSC compared to flying over the ocean with nothing in sight)?

BTW, comparing frame rate in flight scene vs. map view (while flying) - map view is better, but not by much (~25-50% fps difference), so looks like it's mostly in physics and/or external (mod) calls - still somehow dependent on physics/partcount.

Performance tab in KSP is a big lier - actual numbers (as reported by Windows and NVidia) are quite a lot different (significantly lower fps, significantly higher actual RAM consumption; and the performance tab tends to freeze often, showing nothing after a while).

Anyhow, the idea of this topic was not to try to discredit one's observations/experience, but rather to collect more of them (preferably supported by not just "feelings" but actual recorded/verifiable numbers) to be able to make any sort of fact- and statistics-based conclusions - to (hopefully) bring this issue to the developers' attention.

In other words, are you in a similar (mod-wise) situation to one of those described above? If so, what are your benchmarks compared to stock game? At what PC specs?

THAT is what I would like to see in this thread, and would greatly appreciate if the (mostly) irrelevant arguments were kept out, despite the oh-so-sweet urge to comment :wink:

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Tau137