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.

No you can't. A jet engine is not a ducted fan, they just don't operate or perform anything like the other. --Ducted fans and Rotors operate at near 0 axial velocity, ie they hover very efficiently, and have huge static(take/liftoff thrust), but putter out very quickly as axial airspeed increases. It's a general range of 0-0.3(or 0.15) mach they work in. --Propellers operate in the 0.3-0.8 mach range, they don't have the static thrust, but they don't putter out until you hit transonic velocity(they have a nice "cruise" curve). --Jets(all the atmospheric engines we have now) are generally designed to operate in the transonic(0.7+ mach) range efficiently, they also add fuel mass to the efflux, which drastically changes the equations, and have squat all for static thrust. --Propulsive efficiency depends far too much on current airspeed to make any general comparison, but jets typically have a very very narrow band of efficiency, while propellers have a much wider curve; and simply by the fuel mass addition, lose out regardless. Simple graphic, turboshaft means propeller, fans/rotors are another curve before that. We've had things that LOOK like propellers, etc for years via mods; however, they don't BEHAVE anything like propellers. Even with the addition of the jet engine modules, you will never be able to tweak the cfg files to make them behave anything like propellers; the code just doesn't contort that way, never mind autorotation.

I realize nobody really cares, but a couple of years ago, I was screwing with the then brand new resource defs, and figured out: Liquid fuel was probably some hydrazine derivative based on density and stoichiometrics, nothing else matched. I'd considered it LH2 when I had the broadsword engines going(I assume that's where the SABRE/RAPIER name joke comes from), but the numbers just don't work. Intake air and Oxidizer are the same thing(huge surprise there, I know) The air intakes are also magic vacuum cleaners that generate 100m/s of suction w/o any energy input, regardless of flight conditions. I also think Oxidizer matched relatively well with LOX, but memory's not 100% on that. So the air intakes are not only magic, they contain an oxygen separator/condenser/cryogenic system(all with no power input). Some/all of that may/may not be true anymore, but figured I'd post it again, just in case anyone was planning on fooling with resources. Oh, and the atmosphere density is completely screwball also, which results in an invariant mach velocity everywhere.

If I remember correctly from when I was "foolin wit coptas", my working test models were a coaxial version of the Mil-12 rotor/plant, and the same for the ATR 72. The problem with conversion to KSP was that the thrust on the ATR had to be scaled up(completely screwing conservation of everything) in order for it to make any sense compared to the rockets and jets, but there was a more or less constant scale factor I found for translating real thrust to KSP thrust. The helo just used the raw computed thrust values however, and was still able to "bob" up to around 20km carrying a Rockomax X200-32. No real world helicopter can do that, but I put it down to the size scaling of kerbin itself, having modeled the powerplant as a brushless dc "fuel only" motor unaffected by altitude, and being a cobbled together alpha job. I have absolutely no idea where fractal got the numbers for interstellar, but he/she assumes battery charge is in kW, you have to realize that the Mil-12 used FOUR D-25 engines putting out 4.8 MW each ~= 19200 "electric charge" per second in game, or almost draining 5 Z-4K batteries for 1 "mass" per second using batteries as fuel. That's 1067 Gigantor XL's to keep it stable, for a total of 374 mass not even including the powerplant or rotor yet. Seeing as the max takeoff weight for the Mil 12 was only 105 tons, and only made 2.2 km with 40 tons, one could never, ever, even come close to having a solar powered lifting copter that flies forever like PDC was suggesting was so easy. Propellers and wings won't help a bit either, as the numbers just aren't even close, and an aerofoil is an aerofoil. If there's anything to be concerned about, it's the completely nutzor scaling on the ion engines that make them able to be used this way, but that's completely stock Squad product. It's actually rather difficult to mod in anything that's more screwball than the stuff we're given in the base game. The other issue is size. The coaxial ATR equivalent had some issues with ground clearance, but you have to realize: That's 2 of the same powerplants just below the rotor assembly. <note, not to be confused with this way back in the day using DYJ stuff and bigtrack I think it was> In KSP, it became this at ~50 tons total, doing 106 at 2km, which is actually pretty darn close to the specs on the Mil-12. <seems no better images of the actual engine size size survived from 2012 on imageshack, sorry> Not that large of a payload, but it made the launchpad go cry in a corner. Looking back, I really did have a lot more fun modding all that crazy stuff in than I do playing KSP now. Never mind sending Moe's bar and an IHOP to the Mun.

I've run into the refusal to scene/vessel switch problem twice myself, but hadn't figured out what was causing it. For me, I only noticed it after I had built a ship, landed/mined/launched, rendezvoused, and tried switching to station to toggle killrot, so it's not an immediately noticeable thing. Oh, and thank you for doing all this taniwha, your efforts are very much appreciated.

Thank you for this. One would think Squad would have learned to take an hour and released stuff like this themselves by now, but it's Squad. Could I point you here, as you obviously understand the need for stuff like this, and what I was asking for? I believe what the others were talking about with the model reference is illustrated here.

Roandask, that happens because the game doesn't handle ground collision well. Harv never told the physics sim there was a stable state for immobile "ship" objects on the ground; so together with the craptastic ground collision code, "landed" objects are continuously popping in and out of a "sub-orbital trajectory", which causes their immediate destruction when you move out of physics range. Stuff on wheels is slightly safer(or not), and the landing legs are usually ok, as their suspension code helps nullify the constant jitter induced by the ground collision mess. The problem is that the runway especially just doesn't make any sense if it's propped up on blocks, especially as they're all transformers and you can't properly stick blocks where you need them; which is why I gave up on any surface construction, orbital construction doesn't have the problem. The good news: If that means what I'm hoping it means, taniwha is thinking of giving us some sort of actual stationary surface construction option. The launchpad, etc at KSC are not exactly part of the planet, but they do have the the immobility and persistence you'd expect of things like the runway and lp parts, I really don't know exactly how the code treats them, but that's the behavior you want. In the mean time, I highly suggest either sticking legs between the ground and anything you don't want destroyed, or simply keep all permanent objects safely in orbit.

Propellers done right is a lot harder than you think; especially when you have to rewrite the atmosphere system to have coherent densities so you don't have an invariant mach velocity like we do now. They also have absolutely no "power" relation to jet engines, it's comparing bananas and pineapples. They also really aren't that useful for spacecraft unless you prefer a stately, dignified crawl to orbit. All that said, yes you can have them, I had a 32m rotor helicopter flying around before they gave us the partmodule catastrophe. Took ages to ascend to 10km, and balancing propellers/rotors against "Squad math" is an exercise in futility. They can, and do, fudge the numbers with rockets and even jets, but props and rotors require an actual coherent physics system underneath.

Good to see someone finally got around to this again, going to try it out. Just wanted to know how you got around almost all of the stock joint crap code hiding behind private flags? Did you get someone to unhide it finally, or are we allowed to screw with the private junk now?

Finally trying this out (figure it might be relatively stable by now), few big problems I've run into so far: 1. Releasing from orbital construction dock bugs everything, have to switch via tracking station. 2. Smelter failing to attach properly when stacked below probe core, only works above. Seems to be old issue, causes massive headaches trying to build a top heavy lander around it. 3. Rocket part assembly "pod" is just hugely cumbersome to work around, had to build a 6X6 patio on top of a lander, then a wall with a ladder to the ground. Brings back the plywood flyer nostalgia, but might want to consider a cylinder with a door, and proper stack nodes for usability. 4. Biggest problem is the runway and launch pads. I simply cannot get these things to work in any reliable way, or get any repeatable handle on what the bugs are. Do they need a cmd pod? Why do they not have one integrated(about to mod this in to test)? Is it MechJeb causing them to vanish, or is it something else? Do I need debris enabled for them to persist? I figured out they have to be above the pod, but what are the other two nodes doing? How am I supposed to get the runway off the lander and onto the ground exactly? Don't get me wrong, nice models are nice; but it seems to me there needs to be some serious refocusing on making things reasonable to use, before making cool looking stuff. Still attempting to figure out how to properly set up the runway/lp. I'll get it eventually, or not.

I know this is slightly old now, but the reason water is so hard to land on is that: - KSP is built on top of the Unity game engine. - Unity doesn't have proper physics data/collision processing for material surfaces. - Unity "water" is designed to make small things appear to float, not function as a rocket landing medium. - Squad just plain doesn't do hard, time consuming code stuff like dump the POS physics sim Unity uses and write their own. Remember that Squad started from a marketing stunt company, they do big flashy graphic things quite well; don't expect well tuned performance and coherent engineering under the hood.