-
Posts
1,083 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Xyphos
-
-
On 10/23/2020 at 5:12 PM, mabdi36 said:
The whole world isn’t filled with hypocritical liars
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. -
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. -
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"
-
19 minutes ago, mabdi36 said:
<video>
@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.
-
On 10/13/2020 at 10:27 AM, Okhin said:
There's no such thing as an innocent space probe.
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.
-
10 hours ago, linuxgurugamer said:
Assuming the name of the dll is: nonNative.dll
In your AssemblyInfo.cs add the following:
[assembly: KSPAssemblyDependency("nonNative", 0, 0, 1)]
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" -
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.
QuoteContrary 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! -
1 hour ago, peteletroll said:
You definitely can't cast API objects, but you can store them as Objects and access them via reflection.
hmm, why didn't I think of that before? *derp*
thanks a ton, I'll give that a try.
-
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 -
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
-
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 -
-
need a solid way to determine if the game window is active in the foreground, minimized, fullscreen, etc.
-
7 hours ago, Geonovast said:
Just the opposite, not having some of the not-actually-that-advanced features is going to be detrimental.
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!
What's the best way to communicate between addons without referencing an object?
in KSP1 C# Plugin Development Help and Support
Posted · Edited by 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!