Waz

Why is this post still pinned if it's basically entirely out of date for the current version?

It works okay, but you need either powerful reaction wheels or extra engines (a few Twitches). But it doesn't compare to the maneuverability of a 4-Thud VTOL (except in aesthetics).

I tried using the Karibou with TCA and it performed very poorly. I think the VTOL engine is a single thruster, even if it looks like 2 independent engines. I'd love to hear otherwise, because it looks way cooler than 4 Thuds.

The SVE on CKAN currently includes a working build of EVE, to hold you over.

Okay, so I've looked at the code and kludged in UV perturbation to cubeMap.cginc: inline float2 GetCubeUV(float3 cubeVect, float2 uvOffset, sampler2D noise) { float2 uv; uv.x = .5 + (INV_2PI*atan2(cubeVect.x, cubeVect.z)); uv.y = INV_PI*acos(cubeVect.y); uv += uvOffset; float2 uvd = fmod(uv,0.01)/0.01; uv += (tex2D(noise,uvd)-float2(0.5,0.5))*0.002+_Time*0.001; return uv; } Of course, the 0.01 (fraction of the UV used for perturbation) and the 0.002 (amount of perturbation) need to be parameters, and I've just passed an interesting noise texture in to this one function - I didn't understand the multicompile stuff. The _Time things is just for fun - see the video further below. Also, the settings on the shader are probably a bit far from standard - I didn't set up a build environment for EVE, I just copied the shader stuff into my Unity setup. Now, with the time animation: Ignore the lines on some of the quad edges, that's some bug with my geometry. Also ignore the planet behind - no, that's not Kerbin, it's something else I'm working on (you can see I'm experimenting with perturbed UVs on the land too - a bit too "cloudy" currently, but interesting study). Edit: actually, the lines resulted from having mipmaps turned on for the noise texture. Understanding why is well beyond my CG skills, but suffice to say, turning them off made the lines go away. Edit2: the noise texture is: (wow, imgur didn't destory it!)

Thanks - I was worried it was too subtle to be easily appreciated.

A detail texture is exactly what I tried first too, but it either became too visible when zoomed out, or wasn't high enough detail to stop pixels appearing when zoomed in. The scales I'm dealing with with my nebulae are just too extreme - just as the clouds in eve have to deal with a ship floating a few kilometers or a few tens of thousands of kilometers away. I've found that the noise texture isn't detectable visually - I guess because it's varying something that's already non-repeating. The advantage of a texture is of course that you can try different "flavours" of noise easily to see which suits which planet, and other people can easily change them. It doesn't need to be forced to 1 pixel away, but of course if it's too far then it just chews up the detail that's there. So I'd expect that anyone wanting to replace the textures with higher (or lower) resolution ones would also want to tweak the size of the factional part of the UV used and the scale of the UV perturbations (and the noise texture) to suit the quality of the texture. I've only just started looking at it, but by offsetting the noise sampling by time, you get a pretty cool animation. Not useful for nebulae, but intriguing for clouds. Edit: quick crappy demo of animating the fine detail:

I'm working on procedural nebula in an unrelated project, and one thing I have to deal with is the camera getting extremely close to the nebula without it looking pixelated. I was looking at the clouds in EVE (SVE actually, with the 1500x1500 pixel textures) and pixelation is very obvious, so I thought I'd mention how I avoid it. Basically, I perturb the finest detail of the UV co-ordinates such that at around the resolution of 1-2 pixels of the source texture, the fractional part below this is used to look up a noise texture and perturb the UVs slightly. In pictures... From a distance, up close without perturbation, and up close with perturbation: As you can see, without the perturbation, the pixels show up at these extreme magnifications, but with perturbation, they disappear into cloudy detail. And you can keep on zooming in way more than this. Now SVE with 1500x1500 pixel cloud detail: I hope you can see what I found familiar! The change is pretty small. I use ShaderForge for my shaders, but it's basically just doing a mod/fmod of the UVs by a small number (0.01), scaling back to 0..1 (x100), looking up a red-green noise texture suitable for clouds, scaling that vector to be very small (0.001) and adding it to the UV before looking up the actual cloud texture. Net result is to add noise at the lowest detail where otherwise we'd see the ugly edges of pixels. I suspect lower resolution images could be used for clouds if the finest detail could be provided as a UV noise texture. If this is already possible, I'd love to work on some UV noise textures for EVE. Alternatively, if this is a Kopernicus thing, send me there.

Why would you reload a rover back into a rocket? To explore Ike and Duna all in the same mission? This sounds like the basic cause of your problems. Yes, KSP is not an everything simulator, you can't expect every possible idea to be streamlined. My suggestion is to use KAS/KIS to build the rover from a bucket full of parts, not entirely unlike how the Apollo rover was "some assembly required" (and it was left behind, they didn't try to pack it back up and drag it all the way back to Earth).

CKAN entry is borked - it's looking for non-existent: https://github.com/radistmorse/KSPPreciseManeuver/releases/download/68a26c7/PreciseManeuver.zip instead of https://github.com/radistmorse/KSPPreciseManeuver/releases/download/2.0/PreciseManeuver.zip Kludging the registry.json makes it work.

It seems to require AVC in CKAN. But AVC is just annoying if you're using CKAN, since it's already confirmed version checks, so AVC is always wrong. Shouldn't it just be optional?

I'm happily waiting, just setting up a local network for now an making do. (really I just wanted an excuse to quote the above so 1.1 users will see it and not think they're doing something wrong, just have to be patient)

I downloaded the ZIP when it was announced... no x64 exe. Then I noticed the Installer was significantly smaller, so I used that the second time... still not x64 EXE. Now I'm downloading the ZIP again... and it has grown to 1.4GB even though the 32 and 64 bit EXEs are quite a small difference. What's going on? Edit: seems the Installer now probably has the x64 exe, since it just grew by 200MB. The size increase still looks very strange.

Oh, the irony.... Hehe... that's what happens when you do a pre-release but leave out Store customers I guess! I hope Patcher works, or we'll all be downloading it twice after all - so much for saving bandwidth.

For some the "extended game" also involves posting pictures of one's achievements. While I don't agree with them, someone who has never gotten to orbit whining in a forum that someone else used Hyperedit to achieve their first orbit (or something less pathetic) fits your definition of someone calling out another person for cheating.

The "hump" for me is doing a Mun flyby without maneuver nodes, especially since you need to upgrade two buildings to get them.

[quote name='Thegamer211']Agreed, I can't build working rockets without KER. (Unless I make them very overpowered which I don't like)[/QUOTE] They're not overpowered Mun rockets.... they're test vessels for the subsequent Ike+Duna mission! (i.e. yes, when you're landing with a half-tank of fuel plus an entire top stage, you feel kinda stupid).

As a counter-point, I find the backwards-compatibility stuff just plain annoying as it prevents fixing real issues. It's generally bad practice to spend any time on compatibility before a 1.0 release. Things I would even change: * remove all X that are accessible via SHIP:X and similar - they just bloat the docs, obfuscate code, and waste identifiers. * fix the scoping rules to be simpler (and more like common languages). * line ending "." to separating ";". * "set x to y" to "x = y" (no need for == in if statements, since expressions cannot be statements in kOS). I'd even change ":" to "." for properties/suffixes. So I think those who want compatibility should be extremely glad with what there is, in counter-point to how annoying I find it.

Is it RemoteTech's or Uncharted Land's responsibility to fix the LAT/LNG of KSC? RT doesn't know where KSC is with this mod installed (but can be fixed by editing RT Settings).

Tiny request: "Name" field in Vessel group. I frequently launch multiple interplanetary ships that all look similar, so being able to put the ship Name somewhere would keep me from going insane while switching between them.

Kerbals don't appear to be able to EVA onto Corolet - they either explode or just lay on their back smiling like imbeciles. The graphics is also very strange - almost completely black on the surface. Tried with vanilla and with -force-d3d11. S-1 seemed to have the EVA problem, but not Potatus. When mining on Potatus I get a full tank of 1500 ore instantly. Enjoying the new planets though! (I've only played with Outer Planets before, which while it seems more stable, has more realistic and hence less interesting planets!)

The heights where timewarps are allowed for Corolet are way out. It's taking me 8 minutes real-time to go from 30km down to a lower orbit.

fuelLine moved up another notch - took me a while to realize that although it was shown as "owned" in AdvFuelSystems it was also shown in high performance fuel systems... and the latter took priority, entirely removing it from availability.

This tree is excellent, especially when coupled with RemoteTech and a Life Support mod to further reinforce the "unmanned first" principle. However, this bit: doesn't really seem to fit the scope of the mod. Or at least there needs to be more advanced versions later in the tree (non-Jr versions?), as otherwise there is really no point taking them even as far as Duna, especially since all the others transmit at 100% (and so having a scientist just for these 2 poor experiments is pointless). What is even the logic behind it? If the scientist can reset it, he must be removing/replacing the active ingredients, so he must be able to Take the data as well.

For symmetrical craft, roll is not needed. I've not found a way to tell the steering system to ignore roll completely, but I have had success with: local bd to NEXTNODE:BURNVECTOR:DIRECTION. set s to R(bd:pitch,bd:yaw,FACING:roll). (with steering locked to s). It's not perfect, since manual roll control still fights with it, but it's better than nothing. My actual use for this is allowing the player to rotate the ship to align solar panels with the sun manually.