Tellion

Okay, that lightens it up a little! I have also managed to reproduce it now, massive g-forces but no heating here. Most interesting, because I failed last time I tried. I used my main install for testing now, so there might be some mod interaction after all. What I wonder though, if this really is as simple as a single parameter that does not fit, why doesn't it occur for everyone? EDIT: Is there any chance that nobody has actually tested this with and without FAR? because I can reproduce with OPM(64k)+DRE+FAR but not without the latter. I dont quite believe that, surely some of us here run FAR... Alright, not sure if this goes for you too lajoswinkler, but the reason is tied to 64k for me. It seems that orbital velocities increase so damn much that the default parameters do not cut it in this case. Whatever the problem is, it does exist in vanilla OPM (with FAR) - the deceleration is much higher than it should be. I reach about 5 g at 303km height, that is 900m below the boundary to space, and obviously way too much. It does not kill any kerbals however, since the orbital velocity is cute and fluffy and at no point enough to even drain a single point of ablative shielding away before you lost all your velocity. All of those issues go away when running without FAR; at that point reentry behaves as expected both in vanilla OPM and in 6.4x. OPM So basically, what we seem to have here is a FAR incompatibility - probably some value that FAR dislikes. Most likely I am just restating what Borisbee already found out, but maybe it helps nonetheless. Doing the same reentry profile (DRE, FAR, 64K, hyperediting into the edge of the atmosphere) on Jool [like 21km/s initially] displays no such effects, so we should be able to find out what changes are responsible and revert those. The FAR window also has an Atmospheric Composition section, I noticed Gas Molecular Mass and Gas Viscosity differing significantly between Jool and Sarnus, Urlum und Neidon there.

You *should* be able to get away with it using the low res options from astronomers pack. If that does not work, there is not much more you can do except maybe switching to linux. However, there are configs for KSPRC (not sure if that one is any easier on your RAM) and AVP:Oblivion. Especially the latter I would give a try in your case. This is quite the vexed issue you are having there, mainly because we have hardly any reproducibility. What you are describing should definitively not be happening, and it does not seem like you are making any mistakes in the execution of the aerobraking maneuver either... Does it occur when you use the latest stable DRE with the latest OPM only? Toss FAR in and out of there, any differences? All on a clean savegame of course, mods downloaded from the links in their respective threads. If yes, well, some people more apt at reading logs will definitely ask for your player.log or output.log depending on your OS (what OS is it btw?). Post them here, that will lead to more people seeing them and help anyone else who might encounter the issue in the future. If not, there is something specific about your install or mod combination that you have to identify with the old "remove one at a time" method.

I fail to follow you. Where does Newton's law of gravitation have rotational speed in its formula? You might make a case for effective surface gravity at the equator being slightly lower than at the poles due to the earth's rotation and associated centrifugal "force", and that speed actually concerns us a lot when we try to launch into retrograde or polar orbits, but why would an orbiting body care about that at all? In a more empirical sense, why did not a single on of my vessels change their orbits when I switched from the 12h config to the 24h config on the same savegame? Have we discovered yet another flaw in KSP's physics simulation?

Rbrays last post was one and a half months ago, so it seems that RL has gotten to him. This mod does still work fine though, no updates needed.

Ah, I thought that one was custom made. Very interesting indeed

Looking very impressive! I wonder, can we get space engines cloud textures into EVE somehow? That would rule (and melt our pcs) but it would mostly rule

My pleasure! And they are right in doing so, because 64bit for windows is an unstable mess. There is one way out of the misery though, and that is the 64bit linux version - which is actually stable as a rock. Buying new ram for ksp is a great feeling, I tell you

Welcome to the forums and congratulations on your first post! You are playing with windows 32bit, that means your memory limit is extremely tight. If KSP approaches 3.5GB, it will crash for sure, but for many people it does earlier. You also installed the 8k textures, those are quite memory intensive (yes, they might suffice to push you over the limit). Try instead going with the lowest resolution first, and see what happens. If they still do not work, we will require a log from you

KSPRC comes bundled with the dlls afaik, so installing KSPRC -> updating dependencies is what you want to do Installing the latest, say PlanetShine, and then copying KSPRC over it will revert to the version that KSPRC came with when it was released. AVP on the other hand comes with .cfgs and textures only.

I think everyone following any thread whatsoever that has anything even remotely to do with planetmaking knows of your peril in great detail by now... Complaining over and over again will not help you in any way, just following the basic steps about getting support on the other hand will most likely accomplish just that. As someone else has even created a star successfully, there is most likely something wrong with your config or your install, how about redoing both? How about actually providing a logfile? For real, it is not that hard ._.

It does work with OPM, though you really do not require it for anything right now afaik... The KopernicusTech version of Kittopia did really not work (scaledspace update/export) on my install on the other hand.

I am so damn happy for having made the plunge to linux last year 11GB of ram usage while playing ksp ftw. <insert something with masterrace> *ducks away*

This is fun We need more donut shaped planets, that would take kerbal references to food to a whole new level! Also dinosaur space eggs :3

Running the latest OPM with Kopernicus Tech works mostly fine, however I have discovered that I cannot use kittopia tech to update scaledspace let alone export the meshes. OPM now uses the main branch Kopernicus for handling scaledspace, so regenerating them is needed... Clicking the "update ScaledSpace" button will throw a NRE with this NullReferenceException: Object reference not set to an instance of an object at PQSMod_VertexHeightMap.OnVertexBuildHeight (.VertexBuildData data) [0x00000] in <filename unknown>:0 at PQS.Mod_OnVertexBuildHeight (.VertexBuildData data) [0x00000] in <filename unknown>:0 at PQS.CreateMaps (Int32 width, Double maxHeight, Boolean hasOcean, Double oceanHeight, Color oceanColor) [0x00000] in <filename unknown>:0 at PFUtilityAddon.PlanetToolsUiController.WindowFunction (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: 4294967295) content. Complete logfile here. Any ideas? Edit: replacing nothing but the dll from kittopia resolves the issue. weird ._.

I just noticed that the ScanSat compatibility file multiplies the max_alt parameter by 1 instead of 1.64, leading to the best_alt actually being above max_alt in some cases. Is that intended?

I replaced the Kopernicus.dll that comes with the latest OPM with the one from here and it is working fine - if anything goes wrong, just revert the changes (and restore the savefile from the backup you made).

Ah, so the heightmap method does work after all. A pleasure to hear that, looking forward to the results!

You know, just because the thread title still has 0.25 in it, it does not mean that the mod does not work. Just read a few pages back, and you will notice that all relevant dependencies have received updates. Doing a little research yourself is a very good thing if you want to mod your game extensively, believe me.

@Thomas: most likely using this guide. The normal map issue has also been solved afaik, I am not a 100% sure how though, just search for it in the last pages of the kopernicus threads.

That's the PQSMod. Add a PQSMod_VertexHeightOblate in Kittopia (observe results while being close enough with a vessel for the pqs to load) and try to update scaledspace in kittopia... Maybe Augustus used some other way though, or it is just that one PQSMod that gives kittopia trouble.

Yeah, rbray's absence is depressing ._.

Not wanting to derail this thread too far, what about adding the PQSMod_VertexHeightOblate into the .cfg files in Kittopia instead of the ingame gui? Though that might be buggy as well... Yes, you are probably right about that. So we could use higher resolution heightmaps if that is the problem, and if those are supported... Also PQSMod_VertexHeightMap and the heightMapOffset parameter maybe? Not sure what Cpt. Robau has already tried of those...

WOW. Luckily, I installed my fourth ram stick today. Linux ftw

I thought I would post this here: Love this mod.

Its weird... Is there a limit to what heightmaps can do, because all those asteroids ppl base on space engine also have highly irregular landscapes, and those do work... What about the PQSMod that PF uses for that oblateness, can Kittopia implement that, or is it some custom stuff Krag wrote? Edit: Alright, found and resolved the issue that was keeping the 64K configs from working with OPM 1.5.2. New Download here, also edited original post. Not much has changed, more .bin files (from kopernicus this time) and different handling of antennas (the two largest RT antennas will now reach every point in the kerbol system if it is working as intended). Enjoy!