Jump to content

Xyphos

Members
  • Posts

    1,083
  • Joined

  • Last visited

Posts posted by Xyphos

  1. 13 minutes ago, king of nowhere said:

     

    this is a sane design for an Eve ssto. using propellers to get past the worst of the atmosphere and finishing with rockets is doable.

    i am trying to build something similar and i am close, i would manage if i wasn't also trying to have 6 tons of payload

     

    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.

  2. 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.

  3. 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.

  4. @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)]
    

     

  5. 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.

  6. On 10/16/2020 at 11:12 AM, Vanamonde said:

    One of the toughest design problems I encounter in KSP is getting rid of the inflatable heat shields when they're no longer needed. They have so much drag that they are extremely likely to be blown against the ship and damage parts when being discarded. I would very much like to be able to deflate the things and drop them as a dense lump, like most other ejected parts. 

    Quote

    Contrary to popular belief, the inflatable heat shield's size isn't supposed to shield large payloads in dense atmospheres, but rather aid in aerobraking small payloads in sparse atmospheres *cough*duna*cough* because of it's large surface area producing large amounts of drag.

    if you were to use it on Kerbin, Laythe, Eve, Jool or even Kerbol itself, you'll quickly notice that all the mass behind the high-drag shield will want to shift forward, causing it to flip over and expose the payload.

    the popular Kludge to this, is adding an inflatable heat shield to the rear of the payload, and attempt to balance the drag forces on both ends with control surfaces.

    also, it is worth noting that entry to Eve's surface doesn't require a heatshield at all, if you carefully aerobrake a few times to low suborbit prior to final entry; heatshields are only required for a single-pass "I gotta have it now" style insertion.

    however, the jettison of the shield after use is also quite cumbersome, as it is likely to detach and collide with the payload, breaking things in the process, so it's common practice to just ram it into the surface, or pack it with a few dozen sepratrons to push it away, both strategies won't work well on Eve, due to it's dense atmosphere. I personally suggest using it to safely aerobrake to low sub-orbit and jettisoning it within the vacuum of space before doing your final insertion.

     

    you will need a  multi-stage vessel with over 8k dV just to reach LEO from the highest peak (see my signature for details) and over 12k dV from sea-level, but that's not counting the dV needed to return; a separate orbiter should be parked in an elliptical transfer orbit in which to rendezvous with your now stranded-in-orbit crew members, when/if they get there.

    currently, it is not possible to SSTO from Eve's surface without the use of mods, even using Breaking Ground's stock propellers to get it above 10km before going rocket-power is quite a challenge, one that I'm still undertaking since Breaking Ground's release.

    The best [stock] engines to use on Eve are the Mammoth, Vector, Aerospike, and maybe Swivel, with Swivel and Aerospike being best used above 10km.
    Mainsail, Skipper and Twin-Boar engines may also work, but aren't the best candidates.

    good luck, happy landings!

     

     

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

  7. Just now, peteletroll said:

    Can you share a code example? I'm not sure what you mean.

    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

  8. 20 minutes ago, peteletroll said:

    Reflection should be the way to go. You can't turn OTHER into UTIL, but you can use OTHER as a "proxy" to UTIL: OTHER and UTIL have the same methods, and OTHER just calls UTIL methods via reflection.

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

  9. 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

×
×
  • Create New...