NathanKell

Deimos, as it stands in real life, is only 15x12x11 km, or a "sea level" radius of 5.5km. That means its SOI is basically non-existent as it is. I would seriously not recommend making it any *smaller*. ColdFire979: remove the PQSMod inside KerbinOcean. If that doesn't help, try to replicate the issue in RSS v7.2 itself; if the issue does not appear, make the *minimum* number of changes to the cfg possible to make it appear.

Does massfactor still work? I know you deprecated it, but it was useful for that...

Closed by request.

I have updated with the example of the trusses.

If that were true, stock KSP Win x64 would be crashier than it is. Since it's, remarkably enough, decently stable, it appears to be an issue only when the stack gets filled, and/or RAM usage is high enough that addresses are outside the 32bit space.

You found a known issue in KSP. Post on the support forum and maybe they'll finally fix it for .25.

All PQSMods except PQSMod_VertexHeightmap and PQSMod_VertexHeightNoiseHeightmap can define terrain without a heightmap I mean, except the ones that don't alter height (like RemoveUVs or Vertex Color, or whatever). Because that's what PQSMods are for: defining terrain.

If a mod does stuff on Update or FixedUpdate or OnGUI (or anything else that runs per-frame) then it, by adding more stuff to do each frame, will slow the framerate.

Almost nothing. For any physics tick (1/50 a second), the engine will request resources (based on thrust, Isp, and density of the resources). If < (ignitionThreshold * request_amount) of the resource exists, the engine will flame out. In effect, this means that ~1/500th of a second before all fuel is exhausted the engine will flame out.

You can see if the part contains a FAR module and then reflect to get the drag force. If not, the drag force will be 8 * part.rb.mass * part.drag * 0.5 * vessel.srf_velocity * vessel.srf_velocity * vessel.atmdensity

amo28: you need to include a maxHeight value (i.e. 0 meters = black, this meters = white) and, if you set ocean to true, an OceanColor. Check the fooExport (remove the foo to renable) node in Kerbin in the RSS v7.x cfg file.

You're guessing wrong. In fact, KSP Win x64 is quite broken, and either (a) doesn't catch stuff (which seems unlikely) or uses some 32bit pointers (and thus crashes to desktop when there's an exception involving them). Check the stickied Mods and KSP 64 thread in Addon Support. You can verify this quite easily by trying each mod in isolation; they all will work (please, point me to one that doesn't). It's just when there are enough mods that you're using more memory than can be 32bit addressed, and *something* throws (heck, I've had the kerbals in the VAB cause a CTD!) then the whole thing goes kaboom. Besides, if your guess were true (it's the mod's fault) then (a) they would also crash KSP 64 in Linux (they don't), and they'd have to be compiled for KSP 32bit, rather than, as we are mostly doing, x64.

Profuse apologies, all! I have been super busy with updating things for .24, with the Kerbin Cup, and with my new job. Here, at last, is what I promised nearly two months ago. Here is the Worksheet! On Google Drive Please edit responsibly. Please help me fill out cells that haven't been filled out, and start adding your own information to the Contributors list, and start assigning yourself parts (and mention on the Asset Groups you're assigned, and add each individual part you make to the assets list.) Note: I have not finished the specific asset list, and I have not yet updated the assets based on the work shown in this thread. This is a WIP, but Eyes is such a rich universe that there is a TON of stuff to add.

You keep getting better and better!

Version of KSP. This is a plugin for KSP, not your OS.

OrbitusII: not quite. Same ballpark, but not quite. . Mu explains it, in the second half.tl;dr planetary terrain is done via PQS, which is a procedural quadtree sphere. The height of any vertex is determined by the PQSMods attached to the PQS (one is usually, though not always--see Minmus for an example--a heightmap, but there are always also procedural noise-based modifiers). Use Kittopia to play around with them all in realtime. Once you zoom out far enough, or are in mapview / tracking station, the PQS is replaced by a single static mesh with a single large texture for color and a second single large texture for normal map. These do not change unless you (a) tell the game to recreate the mesh and ( load new textures. RSS can help you recreate the mesh, and can export the PQS into a colormap and heightmap (which GIMP or CrazyBump or whatever can turn into a normal map). For statics, you need to add PQSCity components (they're actually just another PQSMod...) and yeah, right now KerbTown is it for adding them.

The solution is not to be found in heightmaps, since the default heightmap, at 2048 pixels wide, yields a resolution of 1 pixel = about 12km x 12km. Even an 8192 heightmap would only yield a resolution of 3km x 3km per pixel. Instead, you need to play with the procedural PQSMods; they are the ones that do finer detail; heck, if you set the frequency high enough you'll have significant height variation meter-to-meter. That said, if you want to export the final map that combines all the PQSMods (the heightmap and all the procedural height modifiers) you can use the Export node in the RealSolarSystem.cfg file.

If x64 remains stable for you, go for it! I had to give it up, though, since it basically crashes randomly-ish and the log lies about why... (it seems to be passing 32bit pointers, since exceptions that are caught in 32bit lead to a full CTD in 64...sometimes.) No idea what KSPLua's from. Quite possibly Part Catalog; I don't use that mod myself... And you're most welcome!

Export the PQS to texture using RSS. That will give you the color map. Then you can copy it into a new layer, select only sand-colors with Select By Color, and presto, you can fill that on the other layer with the desired color.

Aside from KSPLua throwing errors, something very, very simple happened: you ran out of memory. Try with fewer parts and/or lower-resolution planet textures. Make sure you get the just released RSS v7.2, since that, too, will decrease memory a bit (if you only have 7.1 right now).

I'm closing this thread, as all development is occurring in the thread Nori linked. (And development is continuing, just not by MedievalNerd; he's too busy right now.)

Thread closed by request mecki, please take your discussion to the current thread, linked in the post above yours.

Um, one modification: you want to delete the old mod before you install. Since if you "delete the old mod" after you install, you'll be deleting the *new* mod >.>

Size on disk is not directly related to size in memory. On load, KSP will load *all* textures, uncompress them, and then recompress them to DXT1 or 5 (5 if the texture has an alpha channel). There is one exception: mbms which have a "do not compress ingame" flag will be left uncompressed. There are some loader bugs, which it's unclear if they are still in KSP, namely that some PNGs do not get mipmaps generated for them on load, and that TGAs are left as RGB or RGBA (i.e. uncompressed) rather than compressed to DXT (note that of course this still has nothing to do with whether your TGA was compressed on disk; as I said, *all* files are uncompressed on load first, before *anything* else happens.) If you see differences in memory ingame from converting files, that's due to the various loaders using more memory and garbage collection not freeing it yet. It will all even out in the end, unless the loaders have memory leaks. Finally, as of version 0.20 of KSP, since all textures are the same formats ingame, the extension of a texture doesn't matter at all. In fact, models and textures are read in *before* anything else, and *all* models and textures in GameData are loaded, regardless of whether they will be used for anything. Since models are only "tied" to textures after both have been loaded, KSP will look for a texture in the same folder as the mu with the same name-before-extension as is requested by the mu. This is because it's requested from the GameDatabase. If you have multiple files of the same name (but different extension) only one will ever be referenced by models (but both will be loaded and take up space. So don't do this); and if you have a model000.png and the model requests model000.mbm that doesn't matter, because the extension isn't used; what it's actually requesting is "a texture in GameDatabase with the URI /path/to/model/requestedTextureName That's also so that in a cfg in a MODEL node you can replace textures (i.e. you could do texture = model000, path/to/some/other/texture) The long and short is, you're pretty much on a fool's errand. Convert away from mbm only if you have limited *disk* space, or if you want to edit the image; if you do convert away from mbm, delete the mbm so that there is only one file. As you say, because disk read is slower than decompression, it may make sense to speed things up by converting to PNG so KSP has to read less data from the disk (even though it then takes some CPU time to decompress, whereas it takes 0 CPU time to decompress a mbm since mbms aren't compressed).

Yes, if you compile for a version of .NET that KSP doesn't use you will likely get unexpected bad behavior. Certainly you can't use features from above 3.5, so why compile to one of them? It just courts trouble and breaks references. As for the actual bug report: Windows x64 is broken as heck and *any* large (for a disturbingly small value of "large") number of mods will break it. Nothing personal.