KScale64 v1.2.2 16th April 2017

[Mr Betelgeuse]

23 hours ago, EatVacuum said:

 

For me KSC is on the mainland and the island airport is out on the island where they should be. But for interest I redownloaded my dropbox file onto my mini-laptop and looked through it. Each site (KSC, Island Airport, KSC2, monoliths etc.) has a "PQSCity" module and a "PQSMod_ MapDecalTangent module. As I understand it PQSCity overrides the stock settings for each site, i.e. defines the sites coordinates and height above the surface etc. PQSMod_MapDecalTangent is used to override the terrain - raise it, make it level so that the structures will be sited properly on the ground.

Unfortunately the coordinates are not stored as degrees of longitude and latitude, but as radial coordinates (or maybe offsets fromfrom their stock position? If anyone knows, I'd be interested to find out) and I'm not sure how to translate them. For KSC they are;

repositionRadial = (1009355.0, -8801.9, -3704960.0)     

and for the Island airport;

repositionRadial = (186194.6, -16135.7, -570176.8)

Open your Kerbin.cfg file and see what coordinates  you have for each site. If they are different than the above, re-download and replace the Kerbin.cfg file in your install. Hopefully that will fix the positioning problem, if not then it might be more 64 bit caused weirdness.

So I did what you had me do. I went to the Kerbin.cfg, searched for the KSC and island airport, and the coords are exactly the ones you had there. Regardless, I change them, but to no prevail, the KSC is still at the island airport. I'm not sure why this is happening...

[EatVacuum]

On ‎2015‎-‎12‎-‎23 at 3:46 PM, Mr Betelgeuse said:

Regardless, I change them, but to no prevail, the KSC is still at the island airport. I'm not sure why this is happening...

I'm mystified, for now I am thinking it is 64 bit weirdness. Paul's original config had latitude and longitude coordinates, I wonder if substituting those into the Kittopia-generated Kerbin.cfg file might fix it? I'll try that when I have some time over the holidays.

[NathanKell]

Um...why do you think it's 64bit weirdness?
 This mod is 64K, i.e. Kerbin etc rescaled 6.4x. It has literally zero to do with 64bit.

 

Unless you're using the hack for 64bit for Windows, of course, and then you have bigger problems.

[Mr Betelgeuse]

4 hours ago, NathanKell said:

Um...why do you think it's 64bit weirdness?
 This mod is 64K, i.e. Kerbin etc rescaled 6.4x. It has literally zero to do with 64bit.

 

Unless you're using the hack for 64bit for Windows, of course, and then you have bigger problems.

I think you need to read the rest of what he's responding too...

[NathanKell]

There being a prior conflation in this very thread between 64bit and 64K, and all mentions on this page being ambiguous, I felt I ought to mention it. Apologies if it's not releveant.

[EatVacuum]

 

On ‎2015‎-‎12‎-‎27 at 0:03 AM, NathanKell said:

There being a prior conflation in this very thread between 64bit and 64K, and all mentions on this page being ambiguous, I felt I ought to mention it. Apologies if it's not releveant.

You're right, the 64k name for this mod has caused confusion on prior occasions. But Mr. Betelgeuse did mention that another problem he had with the KSC buildings was probably caused by the 64 bit workaround. I couldn't recreate it after redownloading and installing the configs I posted, so I don't think there's anything wrong with them. Betelgeuse still had it after changing them, so I was speculating that the colocation problem might also be caused by the workaround.

Certainly no apologies necessary, rather considering how active you are in the forums on so many topics I want to say thanks for all you do. You've given a lot to this community and actually, you taking the time to help me figure out some PQS complexities in the old thread was what led to me dabbling with improving the terrain in 64k in the first place.

[NathanKell]

Ah, ok, I did indeed miss that context!

And my pleasure, glad it helped!

[Sandworm]

If anyone is thinking rename to avoid further confusion, may I suggest "640k" as a refeence to the infamous Gates quote "640K ought to be enough for anyone."

Edited December 29, 2015 by Sandworm

[Mr Betelgeuse]

Any updates on the surface configs for the rest of the planets?

[Jodo42]

A config for the newest OPM update would be nice too. Plock/Karen have a rather silly orbit.

[Gazpachian]

So I got a neat surprise when entering Moho's SOI on a flyby mission, I was instantly in space near Moho. "Great, 6 biomes worth of near space science! This mission got way more profitable than I'd have thought!"

Anyways, the issue is that the space altitude threshold for Moho is set to the radius of the sun, not Moho itself.

Line 28 of 64K_Kopernicus_Stock_Planets.cfg should read:
            %spaceAltitudeThreshold = 1600000

Instead of:
           %spaceAltitudeThreshold = 584227280

Moho is the only celestial body with this issue. Thanks for an excellent mod, by the way!

[Tellion]

Finally found the time to update the OPM configs for 64k - you can get them here: https://github.com/Tellion/OPM_64K

I did not notice any severe issues, however it seems that the atmospheres of the gas giants are quite dense even in their upper regions which makes aerobreaking relatively rough. Also, 64k and OPM seem to be gamebreakingly incompatible with SigmaBinary for some reason - this happens without any custom configs as well. No idea why this is happening, maybe some problem with the MM priorities... I also removed the AVP configs as those weren't all that useful in the first place.

Edited January 1, 2016 by Tellion

[Sigma88]

@Tellion which kind of issues are you having? SigmaBinary shouldn't have problems with rescaled systems.

Unless your patches are applied after mine, which is unlikely since "Sigma" is pretty late in the alphabet

[Tellion]

15 hours ago, Sigma88 said:

@Tellion which kind of issues are you having? SigmaBinary shouldn't have problems with rescaled systems.

Unless your patches are applied after mine, which is unlikely since "Sigma" is pretty late in the alphabet

The system that ought to be a binary is blank which is accompanied by serious NaN exception spam. I am somewhat at loss as to the cause, especially as earlier versions of SigmaBinary did work without issue (a few months back, that is). After trying things with BEFORE and such I noticed that it also occurs with 64k and OPM only, no custom configs applied whatsoever, so it seems that the cause lies within the 64k configs themselves - no idea what specifically though. Maybe numbers get applied after letters by MM?

[Sigma88]

2 hours ago, Tellion said:

The system that ought to be a binary is blank which is accompanied by serious NaN exception spam. I am somewhat at loss as to the cause, especially as earlier versions of SigmaBinary did work without issue (a few months back, that is). After trying things with BEFORE and such I noticed that it also occurs with 64k and OPM only, no custom configs applied whatsoever, so it seems that the cause lies within the 64k configs themselves - no idea what specifically though. Maybe numbers get applied after letters by MM?

I've taken a look at your config and it seems it should work fine.

you are using :AFTER[OPM] which is definitely fine.

I haven't installed it yet so I can't say for sure.

anyway, you just need either mass or geeASL, no reason in putting both. (geeASL will be overwritten by kopernicus if you define mass)

EDIT:

@Tellion looks like the problem was not in your 64k patch but in OPM itself.

@CaptRobau the "template" cfg you are using is from an outdated version of SigmaBinary, if you will release a 1.9.2 in the near future you should replace it with the latest template (this one)

Edited January 3, 2016 by Sigma88

[EatVacuum]

On ‎2015‎-‎12‎-‎31 at 2:17 AM, Mr Betelgeuse said:

Any updates on the surface configs for the rest of the planets?

Sadly no. Between social commitments, a couple of viewings of The Force Awakens, release of British tanks in War Thunder and new game distractions resulting from the Xmas Steam sale I barely advanced my own KSP campaign at all over the holidays. My usual method is to go there, look around and then figure out what needs to be done and I haven't reached Duna yet.

[EatVacuum]

On ‎2015‎-‎12‎-‎23 at 2:28 AM, Mr Betelgeuse said:

Thanks for the help! I really want to make some configs for the surfaces of the rest of surfaces because they really make 64k a lot nicer and in my opinion better. However, how much trouble was it to create the surfaces for Kerbin, the Mun, and Minmus? Did it take a long time to make? Any advice for me making the rest of them?

There's two parts to it, and the first is simple, the second not so much.

Step one - you just have to figure out how much to increase the vertical scale to get it appropriately "lumpy". Originally I would have thought 6.4x higher would work for all planets, but then you get issues like Kerbin's mountains being so high that you can't fly over, or sometimes even between them as the atmosphere height is only scaled up a little bit, so the air is two thin for flight. So for planets with atmospheres, that didn't work so well, which led to...

Step two - figuring out how the PQSmods for altering terrain work, and then using them. NathanKell posted some good starter info here --> https://github.com/NathanKell/RealSolarSystem/wiki/PQSMods-supported-in-the-cfg. There's a couple of other relevant posts on that github that might help.

You can just write the PQSmod code directly into a .cfg file, but using Kittopia provides a GUI interface that is (sort of) user friendly but more importantly you can use it dynamically, in game. I don't have my notes here but when I do I'll try to translate them into something useful and post them up here for anyone who's interested in knowing which PQSmods are most useful for terrain "improvement".

Edited January 4, 2016 by EatVacuum
more info

[HebaruSan]

On 1/3/2016 at 6:34 AM, Sigma88 said:

@Tellion looks like the problem was not in your 64k patch but in OPM itself.

@CaptRobau the "template" cfg you are using is from an outdated version of SigmaBinary, if you will release a 1.9.2 in the near future you should replace it with the latest template (this one)

@Tellion and @Sigma88, you are awesome. I had trouble with this in my 64K-OPM install last week (Plock and Karen were missing, and focusing on Plock-Karen crashed the map screen till restart). Since Duna-Ike worked fine, I hoped I could update Tellion's config to look more like the ones from OPM, but I had no luck with that, so I resigned myself to playing with normal non-binary systems. But meanwhile you were figuring it out here, and now with Tellion's latest update and Sigma's updated template replacing the end of OPM/KopernicusConfigs/OuterPlanets/Configs/PlockKaren.cfg, everything is working! Thank you for making this cool stuff and keeping it functional, and please let me know if my updated file should be dropped off somewhere.

Here's hoping I can actually get a ship out that far!

[PDCWolf]

I've been using this mod for a while now, got DRE configured and going (was burning up on reentry every time), and everything is great except for one thing: I'm not slowing down enough to open my parachutes, every time I reentry I end up going really fast (like 450m/s) near sea level, so I never slow down enough to be able to open my parachutes. I'm using FAR.

Any ideas? maybe the atmosphere was not made with FAR in mind? Every configuration is default except heattweak.cfg, I'm only using stock parts, I've not modified anything.

Edit: This only happens with the small capsule, not with the mk1-2

Edited January 7, 2016 by PDCWolf

[NathanKell]

Welcome to (one reason) why RO upscales parts. Stock payloads have 100% the mass of their real counterparts but only 41% of the surface area (i.e. drag). That makes reentry quite painful.

You'll need to come in much more shallowly, or use propulsive braking, or do something to lower your ballistic coefficient (i.e. increase drag : mass ratio).

[Joco223]

Is there a way of fixing overheating parts in 64k? I use Real Heat and all of my solar panels and antennas exxplode at about 70-80km when im going about 5.5lm/s. I set the reentry heating to 60% and they still overheat

[CatastrophicFailure]

Well this is annoying. I'm using the configs a fellow on this thread made up (user name escapes me) to restore some bumpiness to Minmus and the Mün, but it seems I cannot switch away from most landed vessels. If I do (like return to the tracking station), it's immediately deleted and I get the "crashed through terrain" entry in the log. But some vessels seem to be fine (the non-important ones, of course). Anyone else having an issue with this? Only tested on the M&Ms so far.

[Sigma88]

44 minutes ago, CatastrophicFailure said:

Well this is annoying. I'm using the configs a fellow on this thread made up (user name escapes me) to restore some bumpiness to Minmus and the Mün, but it seems I cannot switch away from most landed vessels. If I do (like return to the tracking station), it's immediately deleted and I get the "crashed through terrain" entry in the log. But some vessels seem to be fine (the non-important ones, of course). Anyone else having an issue with this? Only tested on the M&Ms so far.

If you are loading an older save the most likely scenario is that the "bumpiness fix" increased the terrain height. When you load a landed vessel it will spawn under the surface, then shifted upwards, pass through the ground and explode.

You could try enabling cheats (indestructible vessels) and see if that saves them. I can't assure you it will work, so backup your saves

[CatastrophicFailure]

No, this happens right away. Launch a new rocket, land, go to tracking station, lander gets deleted. 

[Sigma88]

1 hour ago, CatastrophicFailure said:

No, this happens right away. Launch a new rocket, land, go to tracking station, lander gets deleted. 

Hmm then I haven't see this issue. But I have never tried that cfg you were talking about