Yargnit

So I'm making decent progress, what I'm trying to figure out how to do is how to make a really deep trench, while keeping most of the other heightmap fairly flat except for a few craters. The problem I'm having is I can't seem to keep the majority of the planet flatish once my heightmapdeformity gets to around 15000, even if the rest of the heightmap except for the areas in question only has very fine color differences. I've gone to this extreme: http://i.imgur.com/bTTcS1S.png and I still can't keep the light colored areas flat. Any suggestions? Also, I don't suppose you can tell me how to fix this? http://i.imgur.com/HZrGoe4.png Specifically all of the blurring that happens at higher elevations when I attempt to make a very tall heightmap. And this as well: http://i.imgur.com/CkAcATA.jpg http://i.imgur.com/yFC0PRN.png Basically I need a way to blend the slopes better, that is as fine as I can make the color gradients in photoshop. (IE, 71,71,71 to 72,72,72 RGB) But I don't know what setting in KSP to use to blend those. (I'm trying to make a planet with an atmosphere in the ring you see in the middle, but non atmospheric when you land outside the ring)

So, apparently in: PlanetTutLargeMoon The "Planet" part is actually something that is an identifier to Kittopia, NOT part of the name you gave the example planet. So whatever you name the planet has to be Planet[Planetname] not just [Planetname] in the Kittopia file... That said I've finally got gotten it to at least read the Kittopia file, though it still doesn't appear to be applying my heightmap, the colormap is at least being used now, so I guess that's a start. And even though it's not using my height map, it doesn't look like Tylo's either. (At this point it just looks like a completely random scattering of mountains) This is the height map I'm trying to work with if it helps any: http://i.imgur.com/zl2cr19.png (Not asking if it's good or anything, I know it's not, I just want it to work period, once I can get one working I can work on making one better) Edit: Ok, so upon more tweaking, it turns out the default VertexSmplexHeights values in the example are simply so large that they obscure any actual heightmaps you use. One I turned those down by several orders of magnitude I was able to start to see my heightmap appear. I've still got a LONG way to go figuring out how to actually make a decent heightmap & texture, but at least I'e finally got them showing up in the game. For instance it seems like I need to greatly exaggerate my heightmap and colormap differences, the ones I made were way too blended.

Ok, I've tried EVERYTHING I can think of, but I can't get the terrain of my planet to be anything but Tylo's. I've completely deleted all my CFG's, and then used ones from OPM's slate, just replacing the texture locations with my own, but still nothing. @Kopernicus:AFTER[Kopernicus] { Body { name = Pactus flightGlobalsIndex = 185 Template { name = Tylo } Properties { radius = 125000 geeASL = 0.2 mass = 3.6191e+20 tidallyLocked = True description = Evidence suggests that Slate was very much like Kerbin until only a few hundred thousand years ago. An unknown cataclysm seems to have stripped the moon of its atmosphere and leaving nothing but a dead husk behind. Its vibrant yellow and brown color palette has inspired painters ever since its discovery, including the world-renowned Vincent van Kerman. ScienceValues { landedDataValue = 11.5 inSpaceLowDataValue = 10.5 inSpaceHighDataValue = 10 recoveryValue = 10.5 spaceAltitudeThreshold = 216000 } } Orbit { referenceBody = Kerbin color = 0.823529,0.705882,0.54902,1 inclination = 0 eccentricity = 0 semiMajorAxis = 1500000 longitudeOfAscendingNode = 55 argumentOfPeriapsis = 0 meanAnomalyAtEpoch = 1.1 epoch = 1343.91 } ScaledVersion { Material { texture = Pactus/Textures/Pactus_map normals = Pactus/Textures/Pactus_normal } } } } // CustomData Pactus { AdditionalData { Stock = False AddAtmoFx = False AddOceanFx = False OceanLoadTextures = False UnlitOcean = False ModScaledAtmoShader = False AddRings = False AddParticles = False DisableOrbitRenderer = False } PQS { PQSMod_VertexHeightMap { heightMapOffset = 0.0 heightMapDeformity = 10500.0 heightMap = GameData/Pactus/Textures/Pactus_height.png } PQSMod_VertexColorSolid { modEnabled = True blend = 1.0 color = 0.01, 0.01, 0.01, 1.0 order = 999999 } PQSMod_VertexColorMapBlend { modEnabled = True vertexColorMap = GameData/Pactus/Textures/Pactus_map.png blend = 1.0 order = 9999993 } PQSMod_VertexSimplexNoiseColor { modEnabled = False } PQSLandControl { modEnabled = False } } } This is what I'm working with at the moment (these are the ones I pulled from OPM and tweaked after the ones I copied from the thread here didn't work) The Kopenicus config works fine, but I cannot get the Kittopia part to work under any circumstance. Can someone PLEASE tell me what I'm doing wrong, I'm losing my mind here because everything looks right.

Yeah, I had an idea for how to do it later, unfortunately I still cant solve the part in my other post about kittopia not loading my terrain at all...

So I messed around just to see what I could do. I can get the Kopernicus part to work right, but I can't get Kittopia to apply the height or color. This is my cfg, which is correctly in SaveLoad, and I have a pactus_height pactus_map and pactus_normal (all 2048x1024 png files) in gamedata/pactus/textures. Any clue what I'm doing wrong? (The numbers are all just random at this time, & the texture is just something i threw together quick in photoshop. It's basically looking like a Tylo with a bunch of random bumps, and that's it. It Should be yellowish brown and more whispy. pactus { AdditionalData { Stock = False AddAtmoFx = False AddOceanFx = False OceanLoadTextures = False UnlitOcean = False ModScaledAtmoShader = False AddRings = False AddParticles = False DisableOrbitRenderer = False } PQS { PQSMod_HeightColorMap { modEnabled = False } PQSCity { modEnabled = False } PQSMod_VertexHeightMap { heightMap = GameData/pactus/Textures/pactus_height.png //Replace this with your file path heightMapDeformity = 2000 //how tall should the highest mountains be? heightMapOffset = 0 //only necessary if you're using oceans or if you get areas below 0 elevation scaleDeformityByRadius = False } PQSMod_VertexColorMap { modEnabled = true vertexColorMap = GameData/pactus/Textures/pactus_map.png //Replace this with your file path } PQSMod_VertexSimplexHeight { seed = 69696 //change this to any random number deformity = 10 //how bumpy do you want the ground to be octaves = 2 //how small do you want the bumps to be persistence = 0.5 //don't know what these do, you can try changing them and see what happens frequency = 1 } PQSMod_VertexSimplexHeightAbsolute { seed = 96969 //change this to any random number deformity = 10 //how bumpy do you want the ground to be octaves = 3 //how small do you want the bumps to be persistence = 0.5 //don't know what these do, you can try changing them and see what happens frequency = 0.8 } PQSMod_VertexSimplexHeightMap { modEnabled = False } PQSMod_VertexHeightNoiseVertHeight { modEnabled = False } } } Also I'd love advise for how to make a texture without SpaceEngine (It won't work for me, and anyways you cant exactly make them custom with it). Specifically how to make them custom in such a way that they match up at the edges. Thanks

The latest version doesn't appear to work at all for me. It constantly seems to want to phantom input full control on various axis whenever i'm not actually touching the joystick. I was hoping it would fix this issue I posted earlier: But I can't even get far enough to test it because I can't hardly get in the air w/o it going full control over and crashing me.

What would you recommend if you want to actually make planets with specific features? It seems like with either of these methods we're at the mercy of RNG, either finding the planet in space engine, or the rng seed used for asteroid type bodies. I actually have specific features in mind I'd like my planets to have, and I'm not sure how to ago about that. (Also, I can't use space engine, for some reason it always flies me backwards away from objects instead of toward them)

So aparently there is a conflict between MODULE { name = ModuleDockingNode referenceAttachNode = topdockingPortLarge0 nodeType = size2 } and MODULE { name = ModuleScienceLab containerModuleIndex = 0 dataTransmissionBoost = 1.15 crewsRequired = 2 canResetConnectedModules = True canResetNearbyModules = True interactionRange = 5 RESOURCE_PROCESS { name = ElectricCharge amount = 10 } } Where if both are active on the same part you lose the ability to perform right click action (in VAB or in flight) on the ship in any manner. (Fuel transfer, toggling modules, etc) No clue why they conflict, but after an hour of disabling modules one at a time to find the cause of not being able to right click anything, I narrowed it down to both of these being active on a part. So unless you know of a fix, don't merge a docking port with a science lab. (Or do as I ended up having to do and manually comment out the ModuleScienceLab after merging the parts)

Agreed! Well, that and the fact that if you want to use it with with clouds & stuff they conveniently use up every bit of RAM you can give KSP, so there's no RAM free to add other planet mods along side it. (Intentional? )

You're using -opengl mode I believe. I see the same thing with that selected.

So I just finally jumped in and ordered a 3d mouse (3d connection Space Navigator) for Kerbal because I know they specifically made them work in KSP. However, I am running into a fairly serious problem in the editor with it. Namely, once I've touched the 3d mouse, I can no longer grab any new parts out of the part menu. Specifically what will happen is as soon as I grab a part, it will get immediately dropped, and I am unable to pick it up again. Here is the exact error from the output log (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [EditorLogic]: Selected Part was lost for unknown reasons! This is possibly unwanted behaviour. And the complete pastebin of the entire log is here: http://pastebin.com/rmXHgs2v I am using win7 x64 (KSP is 32bit), and I have tried it with KSP running in directX 9, 10, 11, and opengl modes. Leaving the VAB/SPH (happens in either) and returning allows normal function until I manipulate the 3d mouse, at which time it breaks again. Manipulating already placed parts is not affected. Also I went back and tested an old 0.25 install and the bug was not present. I've tried multiple installs, including a brand new one I made just for this test, the same result is present in all .90 installs. Here's a quick video showing the bug in action: Thoughts?

Hey Teknoman117, just noticed you were back again. So excited to see you back to finally see true new planets possible ala your original Kopernicus instead of the duplication thing everyone's been having to do. Even though Kopernicus based copies are much more stable than Planet Factory ones were, the true Kopernicus planet was just on a whole other level. And as much as I really want to dive into planets, I can't bring myself to do so until I can implement them 100% properly. Let me know if you'd need some more testing/bug hunting done. Glad to have you around again & can't wait to see Kopernicus come to fruition.

After finally figuring out how to not run out of memory running this with AVP, (-opengl) I took a venture to 4 of Sarnus's moons to check it out. Landed on Tekto, Eeloo, Ovk, and Hale all in one trip. I love Tekto, it's absolutely beautiful. (And takes more d/v than you'd think to make it back to orbit from the surface!) Hale is crazy, the SOI barely extends 3.5km above some of the peaks, there's hardly room to leave a mothership in a stable orbit while you land. (Not complaining, it's neat) I did notice a glitch when I tried to burn directly for Kerbin intercept from Hale orbit, crossing SOI's between Hale and Sarnus I got like 6k Kraken Drive d/v throwing me out of Sarnus's SOI. After reloading and just tossing myself into Sarnus's SOI before going home it worked fine. Also can report Kerbal Engineer works fine now. Nice work, can't wait to see moons for the rest of the outer planets! Edit; Notice you say in the opening post Hale is supposed to be tidally locked to Sarnus, it wasn't for me.

I've never ran any part mods really, and just lightly play with visual mods. Also last time I tried the opengl version the performance was bad, either my new video card handles it way better, or performance got much better than it used to be.

Low res options in Astronomers pack didn't do it, but I was finally able to make it work with the -opengl flag. Funny enough using -opengl I sit at under 2.3GB RAM used without having ATM installed at all, compared to crashing above 3.7GB with agressive ATM using DX mode.

So does including the configs to work with Astronomers Visual Pack actually serve any good? I ask because even with nothing else of consequence running for mods, and using aggressive active texture management, KSP still won't get through loading before crashing using outer planers with AVP. It gets through the loading bar at like 3.2GB used, but crests above 3.7GB before the actual scene will load even with the aggressive settings being used.

I tried both Linear and Quadratic modes. That affects the raw input, but not the modified output the game receives. (Which is the problem)

Hey, I wanted to give this a shot after using an Xbox controller for years with stock control settings to test out swapping to my joystick/pedals. However I am having a huge issue where as soon as I start to pick up a decent amount of speed on my aircraft it starts culling the maximum joystick inputs severely. (Using RSS/NEAR if it matters) By the time I an flying at a couple hundred m/s I'm only able to get a maximum of 25% or so control authority. I know the AFBW is reading the joystick inputs correctly because the full range registers on the calibration screen, so it's something in the programming that's limiting the inputs. I can't however find the option to disable it and get true 1 to 1 joystick input. Can you please point me to what I need to do to enable a straight 1 to 1 input of controls. Thanks.

It was specifically designed as a simpler alternative to Real Fuel for people who want to be able to play on real scale KSP, but don't want to deal with new fuel systems etc. Real Fuel already makes similar tweaks, plus a whole lot more, so if you are using Real Fuel this would be fairly redundant. It shouldn't physically break it, but it probably won't exactly mesh well due to trying to tweak the same values. (Whichever tweak loaded last would override the changes made by the one that loads first) I've never used CKAN, I wouldn't know what to do to make it available on there. I know a lot of the Realism overhaul stuff for RSS tweaked the sizes of parts. I specifically wanted to keep the stock .625/1.25/2.5/3.75m sizing to retain as close to the stock experience as possible. Shouldn't the drag work out the same that it does using NEAR/FAR on a regular scaled Kerbin, except with a correct scale height for Earth? The pods haven't had their mass values reduced at all.

Haven't actually heard of it. This was just something I'd talked to a few friends about coming up with and decided since I figured out how to make it work of MM (before it was manually tweaked part .cfg's so i couldn't publish it because it would require sharing squad files) I may as well release it since a couple people I had mentioned it to asked me to. Real Fuels may have something that does similar, I honestly don't know. The advantage to this though is it literally requires nothing more than a .cfg file that's only a few KB in size to use since using RSS means everyone already has MM. That means it's system footprint is for all intents and purposes non-existent to use.

Just wanted to let you guys know, I put together a quick MM based stock part tweak for anyone who wants to experience full scale RSS without having to use realism overhaul and all that stuff. It simply adjusts the mass of the stock engines/fuel tanks to fall in line with real life rockets. This makes RSS much easier to learn because everything is familiar, and also lowers the system requirements for running RSS by not having to stack so many other mods with it. http://forum.kerbalspaceprogram.com/threads/110455-0-90-RSS-Stock-Parts-Stock-part-tweaks-for-simpler-Real-Solar-System-play-%28v0-1%29 Let me know what you think of it over there.

Have you ever wanted to give the Real Solar System mod a try, but don’t want to deal with the huge Realism Overhaul mods list? Would you like to fly around Earth (or an Earth scaled Kerbin) with same old parts you’ve been using for the last few months or years? Or do you just want to be able to show off your RSS scale creations to your fellow KSP’ers and actually have them recognize all your craft designs? If any or all of these are true, RSS Stock Parts is for you. DOWNLOAD - Kerbal Stuff Module Manager (REQUIRED) Download What is RSS Stock Parts? RSS Stock Parts is a simple Module Manager based tweak to many of the stock KSP parts to bring them in line with various, NASA, Russian, SpaceX, etc… designs so that they can be used on full (10x) scale planets at a difficulty level that closely simulates real life launches. RSS Stock Parts aims enable you to transition from playing stock, to full scale with a minimum amount of re-learning mechanics and installing additional mods. What exactly does RSS Stock Parts change? It’s very simple, RSS Stock Parts simply adjusts the weights of the various engines and fuel tanks in stock KSP to fall in line with the relative Thrust to Weight and Wet to Dry mass ratios that actual real life rockets have. That’s really all there is to it. The only other parts that received any changes are the cargo bays, that had their weights tweaked to be more in line (though still heavier than) the new weights of the fuel tanks that they share dimensions with. Everything else stayed the same. How exactly did I go about determining the new mass values? I started out by looking at the values of several well known and successful real life parts. The Saturn 5 F-1 and J-1 engines, the Space Shuttle SRB’s and SSME’s, SpaceX’s Merlin engines, various Soyuz engines, and the Lunar Lander engines. I also looked at the Shuttle’s external tank and the Saturn 5’s fuel tanks. After I had an idea of the range that the real life engines and fuel tanks fell into I went to the KSP parts and started dividing them into categories. For the engines, 1st stage lift engines like the Mainsail and KS-25x4 and so forth were matched up in TWR with engines like the F-1 and Merlin’s (TWR of mid 80’s to mid 00’s generally) Upper stage engine like the Skipper and KR-2L were brought in line with the SSME’s and other similar engines (TWR mid 50’s to mid 70’s). And landing engines like the 909 and Poodle were matched with the Lunar lander engines (TWR’s in the mid 20’s to 30’s). For the fuel tanks I matched the dedicated rocket (1.25m, 2.5m, & 3.75m) fuel tanks up to fall in line around the Shuttle’s ET and the Saturn 5 in terms of wet to dry mass ratios, and then scaled the Mk3, Mk2, & Mk1 plane tanks to be slightly less efficient as they scale farther away from the rocket tanks. (Mk3 is fairly close, Mk2 with it’s lifting body starts to lose a fair bit of relative efficiency) Monoprop tanks were also brought in line, though they should in general be sightly less efficient than standard fuel tanks. Finally for the Cargo bays I simply made them weight 50% more than the same size of fuel tank to account for the mechanics of the bay mechanism. Time for a few Example stats? ENGINES Mainsail: Old Mass; 6.0 - New Mass; 1.6 Skipper: Old mass; 3.0 - New Mass; 0.9 48-7s: Old mass; 0.1 - New Mass; 0.08 (48-7s was very strong, so needed minimal tweaking) NERVA: Old Mass; 2.25 - New Mass; 1.75 (Best guess based off experimental NERVA’s TWR’s) FUEL TANKS Orange tank: Old (Dry) Mass; 4.0 - New (Dry) Mass 1.2 NASA 14400 (Giant) tank: Old (Dry) Mass; 10.0 - New (Dry) Mass 2.7 (Fixed ratios being off for NASA parts) Mk3 Long tank: Old (Dry) Mass; 6.0 - New (Dry) Mass 2.0 Mk3 Long cargo bay: Old Mass; 6.0 - New Mass 3.0 (50% heavier than long tanks due to door mechanics) That really is all there is to it. Nearly every engine/fuel tank was tweaked in this manner (Jet engines were not at this time). What does this mean in practice? Simply, it means that you need a rocket that looks something like this to get a single kerbal to orbit and home, or to a station orbiting in LEO: While a rocket like this will get the weight of a full Orange Tank to a station orbiting in LEO, and the upper stage can be landed back on Earth for recovery: So what all do you need to make this work? The Only thing actually required for RSS Stock Parts to work is Module Manager. That said, RSS stock parts was designed to be used with: Module Manager (REQUIRED) Real Solar System (this is why we are tweaking the parts after all) NEAR or FAR (the stock soup atmosphere does not go well with Real Solar System) In addition, Kerbal Engineer gets a high recommendation, and will make it much easier to determine if you have sufficient d/v to accomplish your goal. With just these mods, RSS is completely playable using RSS Stock parts, and your game will maintain a very stock feel, just bigger. Because RSS Stock Parts is nothing more than a Module Manager tweak for the mass of stock parts, it shouldn't however have any compatibility issues with any other mods you wish to add, nor should it have a perceptible increase to memory usage. Sound good? DOWNLOAD - Kerbal Stuff Module Manager (REQUIRED) Download License; http://en.wikipedia.org/wiki/GNU_General_Public_License - - - Updated - - - Let me know what you guys think in terms of balance, feel free to try out different values on your end (CFG is very easy to change) and let me know if there’s any changes you feel should be incorporated into the official version and I’ll give it a look. Also let me know on your thoughts, should RSS Stock Parts stick to tweaking only the base required parts and mass ratios, or should I look at tweaking the mass of parts like cockpits and crew modules also. Also Should I play with the ISP’s of the various engines (Lower ISP of lift engines like mainsail, raise ISP of upper stage engines like skipper) or should I leave them as they are on stock so everyone knows what they are getting into. Tweaking them would balance the lesser TWR of upper stage engines compared to 1st stage engines better, while keeping it as is maintains the most stock like experience possible. Let me know what you guys think, I played with this a little in .25, but just figured out how to make it a MM tweak instead of manually editing every part CFG, so now I can actually release it. (So basically balance testing has just been by me so far)

I've got a 4GB video card Nathan, so I doubt that unless everyone who's tried the RSS-VE has gotten that.

It doesn't work for me with the newest RSS. I had planetary bodies showing up as white spheres on the main screen & in map view, & I actually had an out of memory red error show up just when loading in the f2 log. (only using 4k textures, not even running real fuels or any other mods to increase memory usage besides just RSS and RSS-VE) That was on a a Win install, not linux also so it's not just linux issues.

What, no Real Scale Solar System in the poll Kasper? On the plus side, Kerbals may finally get a ruler... go go banana for scale!