kellven

Really don't desire more argument today, but they're absolutely right, using QoL as a game balance tool is just plain the wrong answer. Always. I've always thought the whole research implementation was gimmicky, clunky, and just didn't belong with the rest of the game, but nobody asked me. It served well enough as an early placeholder for a system to get players to go places with an in-game incentive, but at the time, I assumed it would be replaced with something more...organic to the game systems. Instead it seems to have simply stuck around so long it's now canonical.

I just have steam set to only update ksp on launch, and never launch through steam directly, so it stays on 1.5. The particular way squad went about obfuscating code and locking down their content was truly unfortunate. I'm sure it made sense to them back in the early panic about pirate distribution, but it also made it all but impossible to create a real, effective mod api that would avoid constantly breaking mods. Btw, I was gently prodding at getting some kind of very basic, stipped down version of MKS into stock, not just welding on the whole mod array as is. I mean deconstructing the mod to it's most basic gameplay elemets, ie: -Some kind of arbitrary location launch site infrastructure. Proper ground connection baked in also. -At least an optional framework for crew resource usage/requirement, with overrideable failure handling. I love extremely detailed survival everything, but I recently heard someone bemoan the lack of ability to switch it off, and I have to agree a simple settings screen toggle option is ++good for everyone. -Better support for meta resource tracking/processing. Just having some of that stuff baked into ksp stock code base itself, even if at only a rudimentary, mod overrideable level seems a good idea to me. At the very least, it would put the onus of breaking changes back on the code monkey doing the breaking. I realized later however, that most of what would really need to get added first to make an appreciable quantum improvement in stock gameplay is a functional KIS/KAS system, then arbitrary launchpads, basic life support thrown in somewhere, and finally the array of parts to make at least a basic version work. The whole stock ISRU system is precedent for this kind of thing, no where near as what the mods at the time did, but got the basic idea in stock. Development recently seems to be handfuls of parts with new models, etc, not really budgeted for complex structural additions. Just an idea, but if not-squad could get KIS/KAS, Rover, maybe pull in a couple other moders and make say a collaborative second expansion, might start to make some business sense, give the community what they manifestly want. P.S. I really miss my now ancient usage of the KIS tag, but it went to a good cause. P.P.S. One of these decades, I'm going to have to learn how to write comments, instead of books.

I completely understand we're still well into the part of the year where work is unofficially over, so kudos to RoverDude for still being active here. Whenever the new work year starts, perhaps a cleanup of the version numbers & individual mods would be appreciated by your adoring public. Personally, I just never liked firespitter, and not really sure what parts of constellation are safe to excise in what groups. I guess you got hired by Squad, or whatever they're calling themselves these days, so congrats. Probably been asked already, but is there anything in the works to fold MKS into KSP itself in some form? When I came back to the game, I realized within a couple hours KSP was all but unplayable without at least the end goals of MKS + USI life support to add pull to get through the grindy exploration stock offers.

Way way back, I had an inline rcs "slice" part that was just indispensable. Not only did you give us an updated, prettyfied version, it looks like yours can actually affect roll, something mine never could. I see a lot of old ideas cycle back around, but almost never an actual functional improvement. My hat is off to you.

A little late, but Destroyer's shuttle made me nostalgic for the good old days of crazy flying contraptions before I begged C7 to give us that landing gear just before he joined Squad. Kind of wonder what KSP would look like now if he hadn't, as it's basically the same part now. Jumping the tower was an art in itself, but we used to launch all aircraft vertical, should be much easier now. Landing was done on skids or the struts, don't know how the current physics joints would handle it though.

Apologies in advance for any ranting, simply thinking of Squad-code induces compulsive rage. Q: -Does anyone know how gravity is handled in code now? -From what I remember, it was handled (back in 2012) in some hidden method of the ancient Part class, and all the gravity modifying mods had to recompute the gravity of every single part, and apply a second force with opposite vector, doubling the instructions just to get back to base, this was beyond stupid. I also remember that when PartModule came out, Squad just dragged along nearly all the ancient code, and stuck it in a new package. From what I understand, Squad in their infallible omniscience decided at some following point to obfuscate their magnificent contribution to programming, which if they did what I think they did, means they're now feeding their entire code base through maximal method overload and rename routines, which I suspect means getting ahold of the damn misanthropic gravity method is now well and truly impossible. -Can anyone confirm this is the case, or tell me how to acquire the object? Reason for Q: The idea I had was to inject a tiny amount of ontological sanity and modability into the stew, and create an actual "public sealed Gravity" object, and possibly other basic physics-system objects, collision being the only truly non-trivial system(and best left to Unity for now). The Gravity object doesn't actually handle gravity, it's just a publicly accessible immutable container for links to the code that does. Inside Gravity are interface properties, which initialize to the default Squad code implementation; and a few general control properties which specify or report things like whether "vessel-based" or "part-based" implementation is being used, "2-body" or "n-body" computations are in effect, what's overridden, who's responsible, versioning, and whatever else needs tracking. This allows some sanity to be used with all the obsessive compulsive code hiding and obfuscation: Leave the damn Gravity object and interfaces alone, mark the actual SQUAD IMPLEMENTATION private/internal/whatever, obfuscate the implementation only, and simply set those hidden objects as the default initialization values of the interface properties. Doing something like this will allow the modding community to actually mod the game in depth, in ways the dev team didn't think of, without compromising Squad's actual IP, or having any need to document/reference any of the source code that doesn't have a valid reason for being public. The best part is that this is how C# is actually intended to work in the first place. One other benefit of separating and properly organizing physics code out of unity is that the Kraken can be truly slain, at least in theory, and high-mass restrictions can be resolved. Aside from collision handling, the actual implementation of the physics required by KSP is very nearly trivial, well documented all over the net, and not really THAT much work, even using native code. Using custom implementations means KSP can finally have a physics system that does what KSP actually needs it to do, instead of what Unity thought was a good idea to borrow from PhysX. The difficult part of this is putting together a comprehensive framework in C# to tie it all together, and properly handle modding, and properly hide the implementation that actually deserves it from decompilation/theft. Unfortunately, it's precisely the high level architecture and planning that I've seen Squad fail at the most miserably.

A long time ago in a galaxy far far away... http://forum.kerbalspaceprogram.com/threads/12743-KIS-Kerbal-Mart-IMOP-0-13-0-17-2Oct12 Consider everything under the WTFPL Total Irresponsibility No Liability License re G Sillius Maximus. Remembered I also planned at the time to make "The Gap", but couldn't get transparency to work properly for the physical gap back then. Just wanted to pass along some ideas.

Feel free to ignore this unless you want to code aerofoil physics. Ok, so obviously nobody gave a $#!^, so I didn't either, and dropped the thing. And decided to kill my KSP modding habit for good. But I mod things because I want to, and this gave me an itch that needed scratching, so... I spent a couple hours dusting off C# and came up with https://dl.dropboxusercontent.com/u/74137297/AtmoData.cs which is an interface/default-implementation/static-factory for encapsulating the atmospheric data one would need to have to compute aerofoil thrust, or at least the start of all that. No idea if it works in game, but it's necessary as the stock density calculations are completely FUBAR, or were the last time I logged it out back in 2012. Still needs relative wind speed, but that was going to be in a larger data class "FlightCondition". Basic idea is you slip in a vessel reference, store the object, call a polling method once a frame, and everything now has access to a static copy of the current flight conditions. The stock code simply has each and every single part calling expensive calculation functions in FlightGlobals every single time they need a bit of data, which is beyond idiotic. And the itch is now scratched, so I'll just abandon this again.

Would really really like a wedge mystery goohickey, the pill is just so incredibly awkward. I'd like a science jr wedgie also, but know someone will veto that. I realize I could do it myself in 2 minutes with notepad, but I'm religious about not modding these days. Great stuff with the rest of the parts I've tried so far.

mindstalker & qfeys: What mindstalker is talking about is VECTORED thrust, not parallel axis thrust. It's a terribly old bug in the engine code that nobody at Squad ever bothered to look at. I was complaining about it back in 2012, but soon realized it was a lost cause, and assumed had been fixed when they fixed the screwball PID controller settings. I really wouldn't bother trying to get a fix in now, Squad just doesn't do that kind of stuff. If I remember right, the idiot code was hardwired into the old engine "Part" code, and apparently just got copypasted into the PartModule scheme. Unless someone has rewritten the thruster classes since I last looked at them, it'll be impossible to dig out the thrust vectoring section, so only solution would be to rewrite the thruster classes from scratch. Lots of problems there, as the GUI dependencies(stack icons/bars/etc) were rolled into a new system that was all marked private, so someone would have to rewrite most of the staging display code as well. Oh yeah, same thing goes for the VAB catalog blurbs. Very glad I gave up modding this game.

The Hummer dealer. Either that, or where you left your keys. Sorry, I had to.

There's a whole bunch of problems here. 1. Rotors are heavy. 2. Rotors with high inertia are the ones that autorotate well. They have weights added to the rotors specifically for that purpose. 3. Heavy is bad ultimate evil for spaceships. 4. Go to orbit without chutes, deorbit, pay attention to your airspeed at altitudes. Preferably write it down, especially when you hit about 250m/s. See how many more seconds it takes for you to impact, and write that down. 5. Why 250 m/s? 0.8 mach asl is the absolute maximum you're going to sustain with a rotating aerofoil design without going into transonic blades and all that fun. 6. First thing you've got to do now is deploy that rotating contraption without snapping the blades/mast and/or destroying your attitude control. If that's done, you still aren't in the position of a helicopter autorotating from a very high hover, you've got a helicopter with zero rotor momentum and a stupidly high negative axial velocity. There is no real way to explain why without going through the whole BET/momentum derivation of rotor thrust, but that is a very, very bad spot to be in. 7. Remember the time to impact you wrote down earlier? Subtract the time it takes to deploy your contraption, and time it takes for the rotors to get up to speed without snapping off. That's about how much time you have left to gain control of your descent, negate 250m/s descent speed, pick a landing area, align, initiate glide, and flare. No rush or anything. 8. Assuming we're still considering the 1D (zero lateral velocity) scenario, an autorotating rotor will behave exactly like a parachute of the same diameter. What that means is you're better off with the chute anyway, as the parachute is going to be simpler, lighter, and much more capable of safely deploying at the airspeed you need it to. 9. If we're considering the 2D(or 3D) scenario where you want to pick your landing spot, you still gain absolutely nothing with an unpowered rotor over a steerable chute. All the real navigation has to be done by carefully planning the deorbit. 10. In order to gain anything with a rotor, it needs to be powered, which needs an engine, which is very heavy. You are much, much better off with a well planned deorbit, small flight control surfaces for course correction, and the tiny amount of propellant you'll need to land with rockets. In other words, this thing, or this thing. I know coptas are cool, I had one in KSP a couple years ago, but they just don't have any purpose in spaceflight. If you really want to drown yourself in calculus, find a textbook on helicopter aerodynamics, and figure the math yourself, it's the only way to really understand the why.

No. For the simple reason that it's just a bunch of meaningless scribbles on a piece of dead tree. The idea of space, or the international oceans being a shared resource is just a way of saying nobody with enough guns and peasants to do anything about it actually cares enough about it to enforce a claim on it. If that ever changes, whomever decides it is worth the effort to claim it will do so; a silly piece of paper and a bunch of political posturing isn't going to stop anyone if they think there's a profit to be made in the end. And no, nobody's going to put nukes on mars, or the moon, or anywhere else until and unless there's an actual population up there sizable enough to warrant using strategic weapons to control. We won't be fighting wars in space because wars aren't about weapons fighting each other, they're about people exerting control over people, who are all still on the ground, and not likely to leave any time soon.

Sorry, didn't make it clear, the broadswords were SABRE engines, the game just couldn't handle curved colliders, and I wasn't about to model them, so they became straight. Ok, tried working the fuel thing again, but found another problem, can continue it over here where it belongs. On topic, had an idea which really appealed to me. Since taniwha apparently understands how to muck around with terrain editing and static planetary objects; how many people would give their left arm to see these again? <insert darkness joke here> It's probably obvious where I'm going with this. Instead of just having deployable launchpads, go with deployable resource extractors too. And while you're at it, might as well add in power and local storage facilities. And since it's just so terribly easy, have them all operate in a global C# object instead of local gameobject scripts so they can simulate function statistically when out of focus. And make system/planetary/local GUIs for managing it all, as it's really not much more work. And can I get some cake over here, and a drink, and a pony, and a treehouse, and...by Wednesday, great thanks. As far as that deployment mechanic quandry goes, I see two main ways of doing it. -In flight part that activates, either spawning some effect based on it's location, may/not consume vessel in process. Trivial except for finding a reasonable offset if required. -Location based system. Couple of ways to do that too, might want to see how KAS does the attach-pylon-to-ground-with-ghost-object bit. Other way might be map based, but that would require a map function, which could be a nightmare if KSP GUI programming is still the arcane dinosaur that made Captain Kludge flee in terror. Probably doesn't help much, but all I got on the mechanical angle.

Well, I was trying to work out the fuel numbers again with 0.35 1/2 parts, but it seems someone last year figured out resource densities only make sense using 5L volume units. That is a huge problem when we figured out back in 2012 Isp only make sense if the volume units are liters, which you might just shrug off, until you realize the engine code doesn't have any concept of fuel consumption anymore, it works backward from an Isp and thrust value. Anyone want to try working the math again, and post what they come up with today? Anyone care to take a stab at what fuel the math resembles now? The forum ate my thread from the last time I went through it, and can't make myself face it again. There were 2 other unresolved physics issues I was aware of when I gave up in 2012: -Atmospheric density was never connected to the temperature curve; so local mach velocity is invariant, and molar mass fluctuates wildly instead. Is this still true? -Unity does not consider units for physics calculations. KSP scales the mass to Megagrams to get around unity mass limits, and this necessitates KN for force as the acceleration is locked to m/s^2. No scaled exponents, so no problem, until you get to big G, where it turns around and rips your head off. Luckily, KSP never actually touches big G, it just uses the shortcut of gravitational parameters handed over precomuted, which keeps the game from exploding, but doesn't make them any less bogus. Is this still true, or even verifiable given all the differing values the game reports? This was a particular pain to test with a plugin, and the numbers just did not add up. I realize Harv et al are human, but the team has a nasty tendency to use shortcuts with engineering equations that have critical underlying assumptions, forget about those assumptions, and scale something screwball. The problem is they make a plan to "fix it in a future update", then cancel the update so they can add more graphics, and it snowballs when they start coding again having forgotten about the problem.