Stiggles

I was wondering about the volumetric clouds: are the, what I assume are, sprites making up the clouds going to be definable through files in the mod or are the cloud textures from the base game? I was going to play around with the clouds when they came out in whichever release it was, but want to know if I should make a series of sprites in preparation like the following two I quickly whipped up while toying with ideas for making cloud cover textures not derived from the same satellite images of earth that everyone is using: 1. 2.

The new update seems to function a bit better on my PC but I am noticing one issue: the clouds near the horizon of the planet (beyond the horizon of the layer) are not being rendered when above a layer. This does break the effect since there's currently no depth to the layers, which I just realized is pretty much linearly corresponding to the alpha of the layer (ie. thicker clouds are more opaque).

Thanks! I also figured out a way to do it in Photoshop after looking at your tgas in the new version: Create an alpha channel and paste the black and white image into it. With the new version, will png textures work or do they have to be tgas?

In an attempt to make the textures feel a bit less out of place, I created a set of textures and a config for the planets Kerbin and Duna and also Laythe. The only issue I'm having is a framerate drop when looking at the clouds in flight. (probably due to the bumpmap for the lowest cloud layer; I don't remember it being there until those were added). I think I found the way to get the clouds looking right, but am having a pretty difficult time getting Photoshop to translate black level into transparency. Additionally, I wish I knew a good way of getting a decent bump map for the whole cloud layer that isn't just randomly punching levels into Photoshop on the base texture. Here's the result of a lot of tweaking. Duna is really subtle, but much easier to see in game: If anyone wants to try the textures out: https://mega.co.nz/#!Iwki2BLZ!dovJ1kdngPtiHcExa1Ha7TMnM9kbXzKiN52o-Vo01O0 Is there any way to expand the halo around Kerbin to reflect the actual extent of its atmosphere? My cloud layers are at around the right heights according to the formulas, but the atmosphere ends, visually, way too early.

I just started working with this mod today (trying to get some realistic settings down.) So far I'm nearing on a decent Kerbin setup after doing some calculations for the atmosphere and creating/modifying some textures, and Duna is now more like real life mars (sparse, wispy clouds in it upper stratosphere). So sparse that you can only see them in the right light. I can send you what I've got so far, if you want that.

I've been toying with a polynomial function to keep the angle in check. This one has been working for me during my launches (I am using FAR): [COLOR="Blue"]lock [/COLOR][COLOR="Black"]pVal [/COLOR][COLOR="Blue"]to [/COLOR][COLOR="Black"]-[/COLOR][COLOR="Orange"]1[/COLOR][COLOR="Black"]*([/COLOR][COLOR="Orange"]1.25[/COLOR][COLOR="Black"]*([/COLOR][COLOR="Purple"]altitude[/COLOR][COLOR="Black"]/[/COLOR][COLOR="Orange"]1000[/COLOR][COLOR="Black"])+([/COLOR][COLOR="Orange"]45[/COLOR][COLOR="Black"]*([/COLOR][COLOR="Purple"]apoapsis[/COLOR][COLOR="Black"]/[/COLOR][COLOR="Black"]tAlt[/COLOR][COLOR="Black"])^[/COLOR][COLOR="Orange"]2[/COLOR][COLOR="Black"])).[/COLOR][COLOR="Black"] [/COLOR][COLOR="Blue"]lock [/COLOR][COLOR="Purple"]steering [/COLOR][COLOR="Blue"]to [/COLOR][COLOR="Purple"]up [/COLOR][COLOR="Black"]+ [/COLOR][COLOR="Black"]R[/COLOR][COLOR="Black"]([/COLOR][COLOR="Orange"]0[/COLOR][COLOR="Black"],[/COLOR][COLOR="Orange"]0[/COLOR][COLOR="Black"],[/COLOR][COLOR="Orange"]180[/COLOR][COLOR="Black"]) + [/COLOR][COLOR="Black"]R[/COLOR][COLOR="Black"]([/COLOR][COLOR="Orange"]0[/COLOR][COLOR="Black"],[/COLOR][COLOR="Black"]pVal[/COLOR][COLOR="Black"],[/COLOR][COLOR="Orange"]0[/COLOR][COLOR="Black"]).[/COLOR] It definitely could use some work, though. This has a check inside the main launch loop that halts it if the ship reaches horizontal and the ship will burn gradually more horizontal as the apoapsis approaches the target altitude. If you want it to turn faster, change the coefficient on the first term (The 1.25; effectively 1.25 degrees for every 1000 meters of altitude). The coefficient on the second term adjusts the maximum effect (in degrees) of the apoapsis approaching the target altitude.

What I've been trying to do (with the node calculations) is use the nextNode:deltaV:mag as the the reference for the throttle control. Something like: if (nextNode:deltaV:mag<1 and isBurning=1) {throttle = 0.}. It works, sort-of, but the script is so slow that it overshoots before the system realizes. If it doesn't overshoot and stop, then the node flips and the ship starts wandering in an attempt to chase it back. A good formula for the throttle control would be a boon, but I've yet to find one gradual enough. Hopefully there's a more simple solution less prone to failure, but it seems it doesn't exist yet. I really do hope some more apparent (and less process intensive) ways of completing these basic tasks get implemented. If not, I'll settle for "else if..." and "else..." statements and making "=" synonymous with "to" in set and lock statements. "else if..." especially, it would considerably simplify my logical checks. Oh! And a logical statement for "not". That would help too.

I'm sorry if this has been answered before, but has anyone figured a good way of performing the burn for a node accurately? I've gotten the node placed at the right point and starting at the right time, but I can't seem to get the burn to end anywhere near the right point. My code's a mess of different, cobbled together methods right now, and it's performing a circularization burn that's 3km off on both apoapsis and periapsis (if it even works at all).

Find a computer with more RAM? Photoshop is nuking my PC with the 16K Tiffs.

I'm working on a few too, though I may downsample to 8K. If eran100 doesn't put up his before I get them converted on my end, I'll put them up. A question for everyone else: do the textures get put into the folders North=Up or South=Up? The original Kerbin texture from the assets file is showing up in Photoshop as South=Up. Is that just fluke of that DDS, or something to keep in mind for all the textures?

That is awesome, and it appears updated up to .21, but do you know of a way to get the full maps off the page that doesn't involve a lot of printscreens at full zoom?

I noticed a couple bugs: one in the Remote Module and a couple features missing in the Fuel module: In remoteTech, you've designated the large (2.5m) probe stack as only a remote control module, when it is a remote command module in the official release. @PART[probeStackLarge] The line: isRemoteCommand = false should be: isRemoteCommand = true In the fuel module, you're missing definitions for the LVT-30 engine (liquidEngine). OR, at least, it only has the stock fuel configuration available. Also, if you select the default engine fuel configuration (Normal LiquidFuel and Oxidizer) you don't get the option to load the correct ratios into the fuel tanks for the engine that you get for the other fuel types.