SpacedInvader

Ok, so in case anyone cares, here are the pics of what I did last night. All pics were taken from about the same point on the Mun, so hopefully the comparison is easy to make. Also, I think I might have overcooked the PQSMod_VertexSimplexHeight persistence a little, leading to an overly bumpy appearance in my tweaked version, but the size is so large that the on ground effect is quite small. I should also mention that v6 did nothing to cure the ground jitters for me, so I'm hoping there is more work being done on this. I'm curious now if there is a way to simply put a capsule / probe onto a planet's surface without having to motor it all the way out there. My poor mechjeb2 pod was killed about 10 times trying to poke around like this, and I can only imagine how much of a pain it would be to try and test this out on a planet like Duna or Eeloo if my probes died every other loading of the game and I've got to motor all the way back out there again...

Sorry for double quoting this, I just wanted to make sure the relevant post was in with my findings. So I guessed, perhaps in error, that the commented out values were the original ones that were modified to create the current real solar system config. Based on that info, and the fact that Kerbin is supposedly about 1/10th the size of earth (at least from the information dropped around this thread), I went ahead and simply increased the heightMapDeformity to 75000. My thinking here was that the reason the object is so flattened is because its trying to implement the same vertical height map over a 10x larger horizontal space, resulting in very gradual, flattened terrain. Anyway, initial testing shows that this made the Munar surface look much like it does at stock system size. Right now I'm putting a lander in the same place in the stock game, RSS without my modification, and then RSS with my modification so I can share some pics of the end result. What I would really like to find is some good documentation of what each part of the PQS block does so I could further tweak it's application, does such a thing exist? On a slightly different topic, now that I've upgraded to v6, my 10x Kerbol system doesn't seem to be quite compatible anymore, with the land around KSC now being below sea level and KSC floating in the air above it. I'm not sure what else might be wrong, but I'm pretty sure this isn't the only departure from the config I want to be using. How might I go about making the old config work with the new RSS? Lastly, I would also like to use the Planet Factory planets in their default configuration with the larger system, how can I make this work? Thanks. EDIT: I would also like to know what I would need to do to let multiple copies of KSP exist on the same system without interfering with each other. I'm not planning on running more than one at a time, but I would like one to play and one to mess around with tweaking things like this without having to try and remember which mods were where and with what configuration settings. Thanks again.

So, out of curiosity, how do you want to handle crash reports? I don't want to just start sending you crash logs for fear that you're going to get inundated...

Perhaps it's on their list, but they have such a long dev list that they just haven't gotten around to it yet.

This mod really has some serious potential. Ever since I started playing KSP (all of 3 weeks ago, but still), I've been wondering why the heck it loads all of the textures at the beginning when they could all be loaded and unloaded on an as needed basis. Installing this has dropped my RAM usage by about 1GB and is holding steady at about 2.4GB even with relatively fast VAB browsing. This is uncompressed and compared to aggressive mode of the active texture management mod. The only issue I've noticed (other than the ones mentioned in the initial post and later in the thread) is that on loading parts in the VAB, they sometimes load an extremely low-rez / blurry texture which then updates after 10-30 seconds. That being said, I'd rather have a short delay on loading than to have to bend over backwards to trim out parts and mods to keep RAM usage under 3.5GB (my crash point). Thank you for this! PS: Eagerly awaiting a version that fixes StretchySRB textures.

I had a feeling that v6 might be an improvement and while waiting for a response I gave it a try. Unfortunately, I run into an out of memory error before I even hit the main menu, which is a problem as I've already cut out all of the add-on's I'm willing to give up, have already pruned out the items I don't use from the remaining, and already use the aggressive mode of the active texture compressor. Can you think of any way to reduce memory load further without giving up any more mods? I'm starting to think I need to try running Linux on a virtual machine so I can get full x64 support and make use of my 16GB of RAM. As for the surface roughness, if I can get v6 up and running, I'll give your modifications a try. I'm thinking though that I might revert back to small Kerbol for the time being until issues like this are sorted out. From what I've read, there is a different PQS model being talked about that might work better, but that may not be implemented for a while. This is important for me though, as I'd say at least 30% of the fun of this game (for me at least) is the challenge of landing on another planet/moon without ending up rolling down a mountain or running out of fuel.

So I finally made it to the Mun with a probe lander using the 10x Kerbol system config, only to find the surface to be completely flat and "vibrating". I could still land, but I'm a little disappointed at the lack of landscape and also the surface movement. A little searching indicated that the flat landscape has been seen before, but nothing about the jittering surface. Are these normal problems and/or is there any way to fix them? Also, can I expect the same problems to be carried on to the other orbital bodies?

Ok, so I plugged in the mass numbers from the RSS config file for the 10x Kerbol system and came out with ~10.1Mm and low and behold it worked just great. Thank you. Now the question I have is how I can go about calculating the Delta-V requirements to get around in my new, larger solar system. I'm guessing I can't just multiply the numbers from the various Delta-V maps for KSP by 10, so is there a relatively simple way of doing this?

I'm trying to figure out how to put something in geostationary orbit while using the 10x Kerbol system by jsimmons. I've tried several altitudes and even found a calculator online for general orbital radius (not KSP), but so far nothing has worked. I though I might try to calculate it by hand, but as soon as I started looking at the math, my eyes glazed over and I doubt I'll get much headway there. That being said, in addition to wanting to know the right orbital altitude, I'm hoping there is a fairly simple way to calculate this so I can expand it out to the other planets when I get to that point. Any help would be appreciated, Thanks.

I'm having an issue with the new experiment system. It won't let me repeat an experiment even though the previous attempt was never turned in for the science reward. I was attempting the high orbit experiments with the cube, but forgot to put any means of getting the probe back on the ground into the design, so once I ran the sample experiment and realized that I needed to bring the thing back to the surface to get any benefit, I reverted, redesigned, and relaunched. Unfortunately, when I got the probe back in position and ran the experiments, none of them reported any science reward, including things like the thermometer and gravimeter, even though I'd turned none of them in for the science reward on the previous attempt. Some searching didn't seem to return any discussion about this as of yet, so I'm wondering if there is a way to reset the experiments so that failed attempts do not mean you're out of luck...

I guess I didn't really think about it that way. I just got the impression from the first post that it wasn't quite ready for mass consumption just yet. I also kind of want to explore the Kerbol system beyond the Kerbin SOI before I give it up completely for ours, but I guess I can try RSS with the Kerbin 10x config and that would solve the real fuels scaling problem pretty quick.

This is true, and I did find that using the stretchy tanks service module as a battery helped immensely, but needing to constantly do burns to keep power up both seems unrealistic and requires you to carry a lot of extra fuel. Either way, both ideas were just to try and make this mod more appealing to early career players who want the challenge of life support, but don't want to have to build flying batteries before they get solar panels.

So I only just now happened upon this exchange relating to my question. I can only attribute my inability to find it earlier to a lack of search-fu. That being said, I can think of two quick ways to solve this issue for people who are playing career mode rather than sandbox. 1: Scale electrical consumption with technology advancement (if possible), simulating the increased electrical draw of more advanced systems, so that early pods only use 24-50 units of charge per day, but by the time you've researched solar panels and batteries, you've got to keep up with the demand. 2: Add a very basic battery to the initial tech node. Something with enough capacity and light enough that it could be used in groups to support Kerbals on short missions, but not nearly enough capacity to support longer missions. This would at least bootstrap players through the early tech nodes until they develop solar panels and better batteries. Just some thoughts since career mode is only going to get more people on board and it would be nice to be able to use TACLS all the way through.

So I'm brand new to KSP, and that means that naturally I'm already setting out to make the game harder and more immersive. I've landed at RF partly because I like the idea of needing to manage the fuel types for each stage and engine, and partly because it allows me to configure containers for use with TACLS. The problem I'm running into now is that RF seems to have thrown my game balance out of whack towards the easier direction. I read in the first few posts that RF is designed for use with an up-scaled physical environment and since I'm not using RSS just yet (I want to let it get to a proper release state before installing), this means that I needed to also install KIDS and then dial back the multipliers to bring the power back in line with what the game demands from its current state. The problem is that even under these conditions, I'm able to launch into a stable LKO for about 3000m/s DeltaV rather than the 4500m/s that most of the available information describes. After some poking around in KIDS, my hunch is that the extra power is coming from the fact that I also have FAR installed which appears to need its own adjustments to bring deltaV requirements back in line with stock. I'm hoping someone here can confirm this and perhaps provide correct KIDS multipliers to bring performance with RF and FAR existing together back down to where it should be. Thanks.

So I'm brand new to KSP, and after a few weeks in .23, naturally I've set about trying to make the game harder and more immersive, which has brought me here pretty quickly. What I'm curious about though, being new to TAC and KSP at the same time, is whether or not the base electrical consumption is scaled correctly. The default is set to a base / per Kerbal of 2400 / 1200, and the documentation describes each pod as having 24 hours worth of use available, but at those rates, my MK1 pod runs out of charge in about 20mins, which means it can't even make a full orbit of Kerbin before the juice runs out. I understand the need for a draw on the battery to support life in the pod, but it seems that the numbers might be a little off? Anyway, I've searched through this thread, but found very little relating to my issue, so I'm hoping someone can bring me up to speed. Thanks.