Jump to content

KScale2 1.2.2.3 16th April 2017


Paul Kingtiger

Recommended Posts

I'd love to help with the bug fixing, but my GFX card just died, so I'm on my emergency AMD 5450 back up card until it gets through the returns process, and KSP runs like a legless dog on it. Seriously any rocket capable of reaching orbit causes it to slideshow, which is strange since I always thought KSP was more CPU limited than GFX card limited.

Link to comment
Share on other sites

Just FYI for anyone installing on 1.0.4, I've noticed reentry eats through my ablator resource quickly: for a 30km periapsis from a 72km Kerbin orbit, I was down to 50% ablator at 50km and ran out before splashdown, luckily I had reached max temperature and was cooling off before anything could overheat. A MM config below might be useful for anyone having this problem:


@PART
[*]:HAS[@RESOURCE[Ablator]]
{
@RESOURCE[Ablator]
{
@amount *= 2
@maxAmount *= 2
}
}

The amount may need some adjustment, I just arbitrarily picked 2.

Edit:

Observation 1: I noticed that phys warp causes the ablator to run out very rapidly early during reentry, basically in just a matter of 30 seconds or so.

Obvervation 2: I tried doubling the ablator above in my save (had to go into my save file and manually double the amounts for my vessels already in orbit). The attempt without any phys warp, the ablator ran out even sooner before doubling the ablator amount (went through 400 ablator by the time I got to 30 km).

Grrrrr, I don't know :mad:. I don't know if it is some mod conflict (not using DRE) or if it's some stock bug. Thought it might originally have been the fact that I was having a longer reentry with the double scale. I think I'm gonna go back to 1.0.2.

Edited by stevehead
Testing results.
Link to comment
Share on other sites

Could you try and see how the behavior changes if you use FAR instead? FAR's aero behavior should be consistent across KSP versions... but what I don't know (and am fairly interested in) is whether or not reentry heating is different between FAR and the stock aerodynamics.

Edited by Streetwind
Typos, typos everywhere
Link to comment
Share on other sites

Well, I wanted to give Squad's stock aero a chance, despite using FAR religiously pre-1.0. It was one of those rage quit moments for me last night. Seems like ever since 1.0 was released, I'm always finding some game breaking bug with either stock or some core mod for the selection of mods I'm using with a particular install that forces me to quit that save and try a different selection of mods or hope the next release of KSP fixes said bugs and not introduce new annoying bugs.

I'll try FAR out later today when I get a chance. I just want to sit down, play the game, and have fun, which has unfortunately been something lacking for me lately.

Edit:

Just tried FAR with just the stock solar system (no Kopernicus of any type). Still having the phys. warp issue during reentry, that and that parts are apparently heating too quickly under phys. warp for some people indicates a stock issue for me there. Without any phys. warp, FAR on stock used up about 50 units of ablator for a 600km x 30km reentry. Going to try the same with KScale2 + FAR in a bit.

Edit 2:

FAR + KScale2. Better than stock aero + KScale2, but tried both 70x30 and 70x40 reentries and ended up with about 30 units of ablator remaining of 200.

Edit 3:

FAR + KScale2 + MM Config to double ablator. Of the 400 ablator, I end with only 35 remaining. So doubling my ablator amount causes me to burn through 170 more units... I'm assuming its because it increases the mass of the part? Doesn't seem right that it would eat up that much ablator.

Conclusion: Physics warp is broken, for me at least, when doing it during reentry. FAR helps a little with a reentry in KScale2, but not by much. Still uses about 120 units more of ablator to reenter compared to stock scale. Doubling the ablator amount causes the ablator resource to deplete faster, almost doubling the amount shed off during reentry.

Edited by stevehead
Link to comment
Share on other sites

Yeah, timewarp with re-entry is an issue for everyone in 1.0.4, unfortunately. =/ And I can only speculate on how ablator consumption is calculated in detail. It barely weighs anything, so that can't be it.

Do note though that they don't have a "explodes upon depletion of ablator" trigger. The only thing the ablator does is cause a negative heat flux in the heatshield. In other words, it's like a "consume this to instantly shed x kilojoules of heat energy" resource. This prevents the heatshield from achieving a high temperature, because once the temperature rises above a certain point, ablator starts to get consumed in exchange for cooling the shield down.

That means that it's perfectly viable to have a heatshield that runs out of ablator during reentry, if the craft safely completes the maneuver. Running out of ablator just means that the heatshield temperature will rise unchecked until it explodes or stops receiving reentry heat. If you have enough heat capacity left in the shield, you might just finish your descent before it gets there. Especially since at very high temperatures, radiation flux increases significantly, which slows down the accumulation of heat. So adding ablator is not your only means of strengthening a heatshield; tweaks to maxTemp or even emissiveConstant should also increase the amount of protection it offers.

Of course, we now have this overcomplicated mess with internal temperature and two different skin temperatures and internal-internal conductivity and skin-skin conductivity and internal-skin conductivity and whatnot... you'll probably have to look into the exact causes of heatshields failing on reentry to understand where the bottleneck is. The shield could explode due to too high internal temperature, or due to too high skin temperature, and you need to treat them differently.

While you're testing, could you also test interplanetary aerobraking? I've heard people say that reentry in stock KSP is a tame little kitten while other planet's atmospheres are bloody axe murderers. Claims like "ship instantly exploded upon touching Jool's atmosphere trying to aerocapture". I'd assume that a scale increase would worsen this problem. Of course, whether or not timewarp was involved may have been a factor, I don't know; that's the problem with the current discussion, hardly any two people discuss things based on identical premises, because nobody seems to have all the facts. And here too, the question is: if stock KSP has that huge discrepancy between Kerbin reentry and other planets, does FAR have it too? Or does FAR's voxel drag model result in a less drastic difference?

I've heard it claimed that the heat simulation is distinct from the aerodynamics simulation, and runs off of entirely different values than in 1.0.2, which for example results in the fact that restoring the 1.0.2 aero absolutely doesn't produce the proper 1.0.2 heating behavior. If that's true, that implies that using FAR wouldn't make that much of a difference. But from what you posted, it does seem to change something.

Link to comment
Share on other sites

Conclusion: Physics warp is broken, for me at least, when doing it during reentry. FAR helps a little with a reentry in KScale2, but not by much. Still uses about 120 units more of ablator to reenter compared to stock scale. Doubling the ablator amount causes the ablator resource to deplete faster, almost doubling the amount shed off during reentry.

This seems to be a long standing issue with stock physics warp, where it increases resource usage and the like. I think squad multiplies physics while increasing delta time, which is wrong...

Link to comment
Share on other sites

Ah cool. Thanks! I'll give that a shot. Been taking a mini-hiatus from KSP doing some Terraria playing. Been on the fence about doing 64k or KScale2 playthrough (I just cannot do stock scale :P). Either way, that information should prove to be useful.

Link to comment
Share on other sites

I've been messing around a little with NathanKell's info. Below are some values that seemed to work decently so far (was able to survive an interplanetary reentry going almost ~5.7 km/s at atmospheric entry, ablator ran out and heat shield was getting close to overheating, but it worked).


@PHYSICSGLOBALS:FOR[KScale2]
{
// Turbulent convection
@turbulentConvectionEnd = 250
@turbulentConvectionMult = 81.25

// Newtonian Convection
@newtonianConvectionFactorBase = 6.355
@newtonianConvectionFactorTotal = 3.25

// Hypersonic Convection
@convectionFactor = 4.775
@machTemperatureScalar = 17.625
}

The values are arbitrary. I basically set the values to be about 3/4 distance between stock and RO values; 1/2 distance, i.e. the average, may work well with 64k. I'm no expert in thermodynamics/aerodynamics, so I wouldn't know if the values scaled linearly or what based on solar system scale size. It may need adjustment, but so far the game seems more playable for me. Stuff not protected with a heat shield do overheat as expected during reentry. Tried doing a rocket launch doing a typical ascent, and no random overheating there. I don't do planes much, so that is one area I have not tested.

Edit:

I should note that I am using FAR with this setup.

Edited by stevehead
Link to comment
Share on other sites

Okay, prepare to scratch your stevehead... </rimshot>

I just installed KScale2 and FAR onto a fresh 1.0.4 instance to test your proposed tweaks. In order to have a proper reference point, I first tried it with stock scale.

Vessel used: starter pod with 1.25m heatshield and a parachute (also two radial drogues, just to see if they would help slowing down in time, but it turned out to be unnecessary because FAR slows you down a bit higher up than 1.0.4 stock does)

Stock scale + FAR, 75km x 30km reentry: 196 out of 200 ablator left.

KScale2 + FAR, 75km x 30km reenty: 160 out of 200 ablator left.

I'm not seeing any of your issues here o_O; You said you had only 30 out of 200 ablator left on your 70x30 test with KScale2 and FAR, but that's not what I'm getting. This is in a sandbox save at default normal difficulty settings (that is, 100% reentry heat). And frankly, the numbers I'm getting make a lot more sense than yours. The stock heatshields are tuned to survive your average Eve EDL with some breathing room to spare, which is a significantly harder job than a gentle 30km periapsis reentry on Kerbin with 3 km/s orbital velocity under KScale2.

Could you please do the following?

- Delete your PartDatabase.cfg (it will autogenerate on next startup)

- Delete your Physics.cfg and replace it with one from a fresh KSP 1.0.4 download that was never started before

- And then try again?

KSP 1.0+ has this horrible tendency to screw up one or both of these files when you apply an update to an existing installation, and in rare cases, even when updating a parts mod to a newer version. PartDatabase can be regenerated, but Physics will be generated with completely wrong values and therefore must be sourced from a virgin download.

Edited by Streetwind
Link to comment
Share on other sites

Hmmm... okay. Weird, I've been using a clean install from Steam: I deleted my Steam KSP install when 1.0.4 was released, re-installed through Steam, then ZIP'd that directory up and been using that for my various installations. Also, sandbox on normal settings like you. I'll try again when I get a chance. It may be tomorrow before I can try it out.

Link to comment
Share on other sites

Outer Planets Mod and Trans-Keptunian support

Link: https://www.dropbox.com/s/7jl9ugh6bsx7ewc/KScale2-extra-planets.zip?dl=0

Instructions

1) Install KScale2

2) Install Outer Planets Mod and/or Trans-Keptunian

3) Unzip the above file and overwrite the KScale2.cfg

4) Make sure the following folders are empty: "GameData/Kopernicus/Cache" and for OPM users, "GameData/OPM/KopernicusConfigs/OuterPlanets/Cache", "GameData/OPM/KopernicusConfigs/SarnusMoons/Cache", and "GameData/OPM/KopernicusConfigs/UrlumMoons/Cache". This is required for the bodies to look correct in the map and tracking station views. Will cause the game to load slower the first time.

5) Run KSP :)

License

In case it's needed: public domain just like the original

Notes

I haven't "thoroughly" played with this setup yet, so be warned if there are any issues. Please let me know if there are any. The new configs should only apply if OPM and/or Trans-Keptunian are installed, else it will just use Paul's original setup. You can use OPM, Trans-Keptunian, or both.

By the way... if anyone knows why I had to halve the inner and outer radii of the rings in OPM instead of doubling, please let me know. I had it figured out pre-1.0 with Kopernicus/Kittopia, but I cannot recall how it worked.

Could you please also create configs for all other Copernicus mods, including Boris System, Asclepius and KerbolPlus

- - - Updated - - -

EDit: I wonder, can't we create a generic update scrip which double all planets/muns radius and semi majoris

something like:


@Kopernicus:AFTER[OPM]
{
@Body[Boris]
{
@Properties
{
-mass = dummy
@radius *= 2
}
@Orbit
{
@semiMajorAxis *= 2
}
}

Edited by FreeThinker
Link to comment
Share on other sites

Doubling the SMAs and radii is only a small part of correctly resizing a solar system. There's a lot more work than just that involved.

By the way: Looks like the source of the "crashes in career mode upon first escaping the atmosphere" bug has been tracked down, and it's something you can even fix manually until Paul Kingtiger updates to ship a bugfix config.

Basically, what happens is this: as you leave the atmosphere for the first time, the game attempts to generate contracts for the first time. Because of the small selection of contract types you're eligible for this early on, you're almost guaranteed to get a surface exploration contract. However, because the planet has been resized, the contract system is unable to find any surface above sea level for you to explore, and cannot proceed - freezing the game. It's not even a crash or anything... it's simply the execution of the game loop halting completely because it encountered a situation that's not accounted for (it can literally never occur in stock KSP).

The fix appears to be increasing the search radius for that contract type, or disabling it outright. Details: https://github.com/BryceSchroeder/Kopernicus/issues/48

Edited by Streetwind
Link to comment
Share on other sites

Hmmm... okay. Weird, I've been using a clean install from Steam: I deleted my Steam KSP install when 1.0.4 was released, re-installed through Steam, then ZIP'd that directory up and been using that for my various installations. Also, sandbox on normal settings like you. I'll try again when I get a chance. It may be tomorrow before I can try it out.

Alright, I've been playing a fresh KScale2 install with minimal mods, and the problems I was having are no longer present. I unfortunately do not have the two installs that were causing problems (rage quit deletion). I don't know, I must have installed something that was conflicting in some way. I've been under a lot stress with RL things, so my troubleshooting abilities have not been exactly top notch lately, so I must have missed something obvious. I'll report on any further issues if I come across any.

Could you please also create configs for all other Copernicus mods, including Boris System, Asclepius and KerbolPlus

- - - Updated - - -

EDit: I wonder, can't we create a generic update scrip which double all planets/muns radius and semi majoris

something like:


@Kopernicus:AFTER[OPM]
{
@Body[Boris]
{
@Properties
{
-mass = dummy
@radius *= 2
}
@Orbit
{
@semiMajorAxis *= 2
}
}

I haven't played those solar system modifications, so I had no original intentions to add a config for them. As Kopernicus becomes more popular and stable, and people make more configs for custom planets and such, it will become progressively more difficult to keep up with them all, even with just the popular ones. I chose to do OPM and Trans-Keptunian because I feel those two planet packs bring an experience most comparable to our real solar system but still have that stock feeling. Unfortunately, I just do not have the time to consider making new configs for other planet packs at this time; I barely have time to play in addition to maintaining/improving my two plugin-based mods and I still have some work to do with the OPM/Trans-Keptunian configs (Paul released an updated version of KScale2 that I have yet to make adjustments on my configs for).

As for a generic update script you mentioned, like Streetwind mentioned, its often not as simple. The code snippet you have is very much what I have for most of the planets/moons, but there are exceptions since the planet packs need to work together differently in certain places. For example, Paul's original config for Eeloo simply doubles the radius and SMA, but OPM does additional things such as moving Eeloo to be a moon of Sarnus, so there was a conflict I had to resolve (and I admit that my solution probably was not the best for future-proofing since it involves a change to the original KScale2 config, I plan to resolve this). Another example is Trans-Keptunian adjusts its planets to work with OPM, so I had to account for that.

If the planet pack simply adds planets and nothing else, the general snippet you provided would work most of the time, you would just have to apply it to each planet. An overlooked problem I quickly found is making sure the planet is of the right mass. If only the mass is provided in the original pack's config, you will need to quadruple the mass to maintain the same surface gravity (g = G * M / r^2); if only the surface gravity (geeASL) is provided, you don't need to do anything; if both mass and surface gravity values are provided, the mass value needs to be deleted like you have in your snippet.

I was hoping KScale2's Github repository would be updated to the release so I could fork and do a pull request with my configs, but I may just create my own repo that would install as a separate config pack. If anyone wants to add support to these other planetary packs, once I get it setup, you're more than welcome to help contribute.

Edited by stevehead
typo
Link to comment
Share on other sites

Alright, I setup a Github repository for planet packs support: https://github.com/stevehead/ksp-KScale2PlanetPacks

My release posts and info can be found at my original post for this: http://forum.kerbalspaceprogram.com/threads/125357#post2031390

I was having an issue with Trans-Keptunian, so the latest release doesn't include it. I haven't checked to see if it was an issue with it or with my own configs, may simply not support the latest Kopernicus or something. Will look into it.

Edited by stevehead
Trans-Keptunian update
Link to comment
Share on other sites

  • 2 weeks later...

So let's talk a bit about actually playing this, shall we? :P

I'm slowly but gradually playing through career as free time allows... with FAR, RemoteTech, Kerbal Construction Time, DMagic Orbital Science and others. Gonna need to install a different life support mod, the one I tested up to this point was kinda lacking (only two containers in really inconvenient weights and form factors). Probably gonna go back to TAC.

Here's what it takes to send a scientist to the Mun and return him safely, without 2.5m parts: https://dl.dropboxusercontent.com/u/44754370/screenshot63.png

139.8t, juuust scraping by the tier 2 launchpad limit of 140t. Some large-ish dV margins in the upper stages, mostly because downsizing the tanks one more step would remove too much dV. Also because I don't know exactly how much I'll need, since I've never gone before in KScale2.

Link to comment
Share on other sites

So let's talk a bit about actually playing this, shall we? :P

I'm slowly but gradually playing through career as free time allows... with FAR, RemoteTech, Kerbal Construction Time, DMagic Orbital Science and others. Gonna need to install a different life support mod, the one I tested up to this point was kinda lacking (only two containers in really inconvenient weights and form factors). Probably gonna go back to TAC.

Here's what it takes to send a scientist to the Mun and return him safely, without 2.5m parts: https://dl.dropboxusercontent.com/u/44754370/screenshot63.png

139.8t, juuust scraping by the tier 2 launchpad limit of 140t. Some large-ish dV margins in the upper stages, mostly because downsizing the tanks one more step would remove too much dV. Also because I don't know exactly how much I'll need, since I've never gone before in KScale2.

Universal Storage might help you with your life support parts. It's compatible with most of the life support mods out there and it adds some other useful parts. Installing it will also open up a load of new DMagic science experiments designed to work with the Universal Storage wedge system. Link in my sig.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...