Kashaar

D'oh Thanks a lot everyone, it works now!

I'm working on a stabilizer function right now. Currently the AG power is fixed, which leads to some funny oscillation effects... but doesn't make this very useable. More work is needed! In other news, resource consumption is in, and increases proportionally with planetary and vessel mass.

Hmm, so KSPFields are a red herring in this case, I suppose... My problem is that the game doesn't seem to be assigning my PartModule's variables the values defined in the part.cfg. I'm writing an antigravity plugin, and I want some factors (agStrength, agAttenuation, etc.) to be set by the part.cfg, so I can create multiple parts with differing characteristics, but using the same algorithms. With the code above, the three variables are all 0 when I use the debug window to look at them in game. I can define them in my code like this to make it work: public double agEfficiency = 500; ...but that kind of defeats the purpose of the part.cfg, if I understand it correctly. I'm sorry if I haven't expressed myself clearly. I'm very new to C#, so if this is something obvious I should know I'm sorry. I only have a little previous experience in Python, and took a Java class maybe 10 years ago that never amounted to anything. Hmm, after this part: ...what does the game do with the attributes inside the MODULE {} brackets?

Oh, I thought those were linked somehow. Google isn't being very helpful unfortunately... or my google-fu is just too weak, so what is the usual part.cfg loading logic? In place of an explanation, a link to an open source plugin with a pointer towards the relevant piece of code would also be helpful.

Hello everyone! I'm new here. And I have a hopefully simple question: how do I make my partmodule class load properties from my part.cfg? Is there anything I have to do besides defining the variables as KSPFields? Relevant bits: public class KAntigrav : PartModule { [KSPField(isPersistant = false, guiActive=true)] public double agEfficiency; [KSPField(isPersistant = false, guiActive = true)] public double agStrength; [KSPField(isPersistant = false, guiActive = true)] public double agAttenuation; And from the part.cfg: MODULE { name = KAntigrav agStrength = 1.2 agAttenuation = 10 agEfficiency = 500 } Anyone have any idea what I'm missing? It's probably something obvious that I don't yet understand.

Yeah, pretty much. The same formula could easily be adjusted to allow higher orbital hovering, but I think that's not the niche this add-on should fill. Getting out of a gravity well is much more fun with proper thrusters, anyway!

I'm planning for this to be useful in surface missions, landers and skycranes and so on, where you might want to need to hover for extended amounts of time, and doing so using main thrusters would be wasteful and inconvenient.

Hello, everyone! I've been playing Kerbal for a while, and recently decided that while real-life is kicking my ass, I need a creative side-project to mellow out a little. So this Sunday I started learning C# to make an add-on for Kerbal pace Program! Since at the time in my Kerbal career I was struggling with making a reusable skycrane lifter, I figured I'd make something to assist with that. I had just finished reading Peter F. Hamilton's Void trilogy, and the Regrav drive technology in that universe which seems to work best at low altitudes and badly in space seemed like a decent point of departure. I shall call it: Pyrron Spacefaring, Inc. - Antigravity I managed to create a working prototype in game as a proof of concept, which I'm demonstrating here: In that video, the antigravity force applied is constant. It is always applied in a direction away from the current SOI's center of gravity, so as you can see in orbit, it has the same effect as a radial burn - moving the Pe down and Ap up 90° from where the craft is located in its orbit. This is just a first proof of concept, so those big colorful arrows are just visual debugging tools that won't be in the final add-on Now, my intention with this isn't to be a free propulsion device... I want it to be useful, but not overpowered to the point of cheating. It should fill a niche, and add interesting gameplay complexity. So I got some help from a friend (who is actually an aerospace engineer) coming up with a formula to make the antigravity force dynamic: it now scales with distance from the current planet's sea level, decreasing the higher you go. I thought about making it independent from the planet's radius and depend just on local gravity alone, but that turned out to be inconvenient to model in a way that makes it useful on more than one planet. (I'll probably revisit this later though, maybe scale it so higher gravities require more resources, or something like that.) Here's a chart of what it could look like on different planets: The AG factors mentioned are AG strength and attenuation, and can be set per part. The different graphs show the effect of the same factors on different bodies. The vertical axis shows the difference between AG strength and gravity at that altitude. At 0 m/s² is the equilibrium point, where AG force and gravity cancel each other out. My current "development plan" is to keep working on it whenever I need a break from writing my thesis, so updates are probably going to be intermittent. The to-do list looks like this right now: Design: Figure out a working model for resource use Coding: Implement resource use Coding: Create UI elements for relevant readouts and interaction (probably right-click and action groups only at first) Design: Decide whether to use surface height or sea level as reference point for AG strength Coding: Create smoother establishing of equilibrium point (right now the vessel goes up and down a lot before settling there) Design: Come up with interesting variations for parts Art: Conceptualize and create 3D model for basic inline part Coding: Ensure that using multiple parts works as intended, and general QA. Initial release There is, of course, lots of room for expansion, not only but especially in the art department. I've worked with 3D art before, so it'll be fun to revisit some old skills and see how rusty they've become Radial parts and thruster-like bottom caps are also things I'm considering, but I prefer to start small and expand if this turns out to be successful and fun. So... what do you all think?

Hello, everyone! I just wrote up a 2000-word, 23-picture report of a Jool mission and inadvertant rescue mission using Interstellar that some of you might find entertaining. You can find it here: The flight and plight of the Rainbow Retriever And if by chance anyone can tell me what could possibly have gone wrong at the end, or if it's "just" a weird and obscure bug that caused the energy drain, that would be awesome too. But I'm content just labeling it an equipment failure