Thygrrr

I have no idea then, very sorry.

Do you click on the little "Play" icon? Or just on the server name?

Can't see any errors, nor any connection attempts - what are you doing to connect? These buttons connect to a server. The green plus button on screen 1 is only for local servers or those that don't want to get listed on the master server.

That's not correct, this looks rather like they have a broken reflection probe; or forgot one; likely their multi camera system affects how far a reflection probe can look. There's an "infinite" setting, but the probe needs to be in the right scene; and if that isn't the scene the Stayputnik is in, it's hard to get that texture "across" (but it is doable)

Can you put it in a zip file?

Thanks so much, I was kinda stuck finding the Engineering Report. Cheers!

Care to share the code at some point? My idea is to not only show it in the Editor, but also in the ship Resource Panel. Like a consumable resource. My original question was more about the API of that class, though. I can see it in autocomplete and it's mentioned in the API docs.

That's exactly what I was implying. However, with air pressure, ISP will change, meaning your DeltaV will change; also, if you decide to hover on the Mun you're wasting dV without going anywhere. So there is a perfect and a worst case ascent.

Yes, a KSP.log would help.

I can't seem to find the docs for VesselDeltaV, despite it being mentioned, in the API documentation. Did I miss something? PS, sorry this made it into the wrong subforum

It's the very essence of not being a necessity; and people going out of their way to be courteous actually is what makes courtesy "nice."

The LMPClient folder actually contains a GameData folder that contains the actual Mod folder you need to put in GameData. If that is not the fix, you should explain what kind of mods you run and we can talk you through till it works.

Basic DeltaV is a mod. Also, DeltaV is generally dependent on drag, but AFAIK no DeltaV Mods calculate this, and that makes perfect sense. One could calculate a "perfect ascent" DeltaV, but that differs from craft to craft. However, if you know that "4000 m/s dV are enough to get into a decent orbit", and you know your craft has that much, you will be fine. In space, where maneuver precision matters more and more, DeltaV calculations are easier and easier because the crafts get simpler and there is no drag.

Mechjeb and KER have been more than good enough. Especially getting to Mun, Minmus, Eve and Duna are near impossible for a new player without something telling him "this rocket is good enough" or "adding more fuel isn't making this stage get any farther due to TWR" One of the least cluttered solutions is Basic DeltaV, and I'd go even further and put it in the engineering report, but instead of making that a foldup menu, make it a drawer from the right of the screen, similar to the function groups on the left. Or just keep it open at the top right of the screen. That's where players will see it because that's where the pretty launch button is.

When you base your NavBall stuff on deltaV, can you also put a deltaV and TWR indicator into stock VAB and SPH? And, during flight, maybe add "deltaV" as a resource to the resource view. I'm thinking of making this into yet another mod, but... why does such a basic feature have to be a mod. :)

Hmmm, this workaround defeats the purpose of not having to EVA in every biome (even though the more I play it like this, the less fun I have, so maybe I will leave it at stock)

This should be included in lvl 2 mission control "Flight Planning". TWR and burn times should be included in lvl 2 VAB/SPH engineering report, and reduce part count to 60 or something (I feel the 255 part limit is something you never reach at that tech level) Ideally, something like the Basic DeltaV mod becomes available at a certain level. If it has to be a small feature, JUST calculate Delta V per stage. It would make the game much, MUCH better. Display Delta V in the Resources panel as if it were a resource.

Well, anything that eases in / out physics, etc. is potentially a big problem when you use mods like Lunamultiplayer (which I am currently helping test) So JUST configuring warp values in a straightforward, robust way would be a huge boon. I found another warp mod (Time Control) that is much more robust than BetterTimeWarp, but also has its own idiosyncracies that make it undesirable (e.g. a very confusing UI, and its core feature is actually not someting I care about).

I run and maintain a personal mod similar to this, and I also changed crew reports to be biome dependent. Doesn't work as well as hoped, though, it effectively only Nerfed EVAs and doesn't let me store multiple crew reports (which is unlike EVAs worked). Any ideas how to make multiple crew reports storeable?

It works, but still has a bunch of bugs. That said, it works pretty well. It is being actively maintained and improved.

I think neither should be standard. B9 is a pretty janky set of game hacks; I find the variants management that KSP 1.4 brought much better. I'm really sad SO MANY mods still have a B9 dependency, worse even if they use the ungodly Interstellar Fuel Switch mod on top of that. Suddenly you have three "dimensions" to switch parts through, but each only uses one or two of these. Tweakscale... I would rather see procedural fuel tanks and trusses, but not procedurally scaled "everything".

Yeah, FlowerChild comes across as a somewhat egomanic character at times, their Minecraft Mod Better than Wolves (essentially the best MC mod ever made) is also strictly All Rights Reserved, Do Not Distribute. Cannot argue with FlowerChild's extremely good design skills, though. Guess the terms are warranted.

The documentation is outdated in that paragraph; much like a LineRenderer Component , Trail Renderers can be anchored in the world (or whatever transform you parent them to). As ou can choose your own material and thus shaders, you have very fine grained control over how these "particles" could look and orient themselves. Both do require some understanding of the KSP / Unity rendering path though, and I wonder how well it would work if every wheel had a trail, and trail generation would need to pause as soon as the wheel left the ground, etc.

I won't write this mod, but Unity 5 and up have a very decent TrailRenderer Component that is suitable for exactly this, and it would be just one Gameobject per wheel. It would, however, be somewhat nonpersistent, i.e. there is a max length and time you could have, but it could be hundreds of meters if not some kilometers long. As a nonphysical object, its overhead on the overall performance would be quite negligible.

In my recent 1.4.5 games, when I land a simple can style lander on the Mun, more often than not, one of the legs suddenly snapped off (at 3m/s vertical speed), and a phantom force launching the craft ~2km up from the surface again.