Xyphos

@Teilnehmer You're AWESOME! thanks so much for your example! I forked it just to keep it around if needed in the future. Thanks again!

Actually, yes it is. myself included, as you pointed out I'll admit my own character flaws before I admit that video was legit vanilla (clearly it isn't)

Gilly is actually a class F (maybe G?) asteroid. Orbital velocity is ~33 m/s which means, if you run fast enough and jump to sub-orbit and fart your way to full orbit, you're stuck until your next burrito.

yeah, I've seen this video, it's actually believable, but I'm still a bit skeptic because of the mining equipment in the nose fairing. and I know your pain; 6 tons is a lot of payload for an Eve SSTO, I assume it's mining equipment? if so, I recommend fueling on Minmus or Gilly before arriving at Eve, leave the mining equipment affixed to the nuclear tug in orbit, descend a fully-fueled lander to the surface, do your mission, return and redock. use the nuclear tug to get to Gilly and refuel.

Actually, I've been playing since 0.90 and I can get to Eve orbit from sea-level, just not in an SSTO and I've been trying many designs for years which is why I call horse-raddish on this video. and you can't go around claiming it's "vanilla/stock" while using visual mods, god knows what other mods he's used that can't be seen; given the part count with smooth FPS while recoding, I'd say there's some welding and part mods involved too cuz this game has terrible performance on my [64gb / 4.2ghz / i9-9900k] without visual mods. so no, I don't believe for a single nanosecond that this was vanilla/stock and my cow-pie meter is reading off the charts. I'll change my mind when someone can do it on xbox/ps4 so until then, we'll just have to agree to disagree.

While fluff is nice to have, I don't think it's anything worth incrementing a version number over. Hope they work in some bugfixes and performance enhancers too. PS. in b4 "1.11 broke my mods"

@2:50 & @3:30 -- I don't recall LV-N's ever being pink/purple/magenta, 'tis clearly mod vessel, not stock. the dV required to perform that inclination change around Eve alone should have caused a mission failure.

I'm starting to think there's no way to add a reference to System.Runtime.Remoting? KSP log now says: ADDON BINDER: Cannot resolve assembly: System.Runtime.Remoting Edit: if not, I still have options: 1. Try a late-load wrapper with reflection (PITA) 2. Implement my own remoting methods (Lots of work)

IMHO, Dres is best experienced as a HyperEdited third moon around Kerbin, preferably in or near polar orbit but you get to HyperEdit it however you see fit.

Sputnik personally saw to that.

@linuxgurugamer Sorry to keep bugging, but my KSP.log now says: [LOG 02:34:27.568] AssemblyLoader: Loading assemblies [WRN 02:34:27.569] AssemblyLoader: Assembly 'RemotingTest' has not met dependency 'System.Runtime.Remoting' V0.0.1 [WRN 02:34:27.570] AssemblyLoader: Assembly 'RemotingTest' is missing 1 dependencies [ERR 02:34:27.627] AssemblyLoader: Exception loading 'System.Runtime.Remoting': System.BadImageFormatException also, in AssemblyInfo.cs [assembly: KSPAssemblyDependency("System.Runtime.Remoting", 0, 0, 1)]

Update: so as annoying as it is, I made a bone-headed move by creating the solution under the wrong platform (.NET standard instead of .NET framework) and tried to fix it by editing the csproj file to correct the mistake, this in turn screwed my project up from the very start where certain options weren't available, disabled or otherwise unused. sending the whole project to the recycle bin and starting over fixed the problem. thanks.

thanks, but I'm using VS2019 and for some reason, AssemblyInfo.cs is missing, targeting "net45" framework

in my mod assembly, I'm referencing a .NET library not native to KSP, but when I run the mod, the debug output says it could not find, load file or assembly. even coping the .NET dll to the mod folder fails. any workarounds?

2018 was over TWO years ago, KSP v1.5 is outdated and buggy; the fact that he flew and landed that monstrosity without it breaking or crushing is testimony. I'll retract my previous statement when someone within the past year can do it, as the keyword in play is "CURRENTLY"

just a simple change in your play style can make all the difference, and doesn't apply to just Eve. Happy Landings!

hmm, why didn't I think of that before? *derp* thanks a ton, I'll give that a try.

I deleted the code, currently implementing NamedPipes. API is a singleton class, upon instancing itself, it looked for UTIL and if found, Invoked AddAPI(API api = _instance) upon invoking, the exception is thrown because API produced different object types that wasn't castable between addons

Tried that, the OTHER.API would hook into UTIL.API but passing the object reference OTHER.API caused the aformentioned exception

Update: I'm going to try NamedPipes next, but I'm still open to suggestions.

so I'm scratching my head on this one, and open to suggestions. I'm attempting to write a utility addon (UTIL), that other addons (OTHER) can optionally use without referencing UTIL, so the OTHER addon won't require UTIL to function, but still could use if the UTIL addon is installed. if UTIL is present, I need a way to exchange data in both directions to/from OTHER, again, without referencing either one. my first attempt was obvious, GameObject.Find("OTHER") but that still required the OTHER addon to reference UTIL, which created a hard-dependency, which I'm trying to avoid. second attempt at this was to use BroadCastMessage but the problem is that BCM isn't target-specific so data is broadcasted to ALL listeners, which can cause lag, data collisions, interference, etc, and required the OTHER addon to sift through dozens of possible actions, which was a freaking nightmare. third attempt was to use System.Reflection wrapped in a simple API class that could be dropped into the OTHER project, but as I quickly found out, Exception Thrown: OTHER.API cannot be converted to UTIL.API as these assemblies do not share the same object type, despite being the same drop-in file, preventing me from obtaining an object reference to OTHER.API from within UTIL.API

Cheers!

need a solid way to determine if the game window is active in the foreground, minimized, fullscreen, etc.

I agree, Advanced Tweakables should be enabled by default, and let the experienced players turn it off for an increased challenge. (but doing so will also break certain mods)

This is well thought out and put together; very wiki-like. <-- *hint* nicely done!