kellven

Only read the Op, and the one above, just wanted to mention a couple things. First, that link to the workthrough of propeller operation probably isn't really what you want, you should probably be using combined blade element and momentum theory if you're trying to get any values in flight. It ends up being a non-deterministic equation, but it can be reasonably well solved running it twice in a newton iterator loop. Find a good book on helicopter aerodynamics if you want the full equations. Second thing was that jet engine thrust is supposed to fall off when you exceed their operational velocity curve same as any other real atmospheric engine, not sure what exactly you were expecting Hodo. Almost forgot, back when they came out, I dug around the air intakes, and at least back then, they were creating a magical 100m/s induced velocity without requiring power, and had a very loose interpretation of intake vs orientation.

Been a really long time since I looked at it, might want to also check if the part was overheating/exploding also, if you haven't resolved the problem.

Vanamonde is entirely correct. I ran into the temperature problem about a year ago trying to make engines with actual copter physics. If you really dig into the physics, you can see from various universal constants the units things have to be in. The real problem was that KSP has/had no actual system for temperature. The game just assumed it is/was 59/60 F at the pad, on Minimus, Jool, and the center of Kerbol. It also has no concept of molar mass, so every atmosphere is just plain old Earth air. With biomes, that may have changed, or they may have just added a random number generator to the temperature sensor output for the science system, haven't played/poked around in it yet.

Praise Kerbol. Does that mean XML is back too?

I think I'm just going to go ahead and remake my rotor/prop physics engines again. I still have my mountains of algebra scribbles on BET somewhere. Without further ado, I present the KIS Propeller Propulsion Plugin Project, or P^4: Our chief of development had a few questions. -Does anyone have(or know of) a current mod that replaces an engine module's update code? Would save me a ton of time if I didn't have to reinvent that also. -Does anyone have(or know of) a current mod that replaces stock engine stack icon behavior? Fuel remaining and heat are probably the least useful metrics to display on a propeller. -Does anyone have(or know of) a current mod that replaces the stock metrics in the VAB select-a-part GUI? Rocket motor metrics have no meaning in the aerofoil world. -I remember C7 at least tentatively deciding to replace the "throttle as %thrust" behavior on the nuclear motors with "throttle as %fuel consumption" a while back, did that end up in the game, and did the idea propagate to the rest of the motors? While it may make some sense in a rocket motor, it's beyond useless on a propeller, and if it's propagated through the control code, I'll have to fight with that also.

Actually, I thought Nexis banned assemblies referencing System.IO way back in .18 from loading. Is that no longer true, or was it another assembly that was banned? I just realized the old sticky about the PartModule Incident isn't around any more also, unless I'm in the wrong forum somehow. As far as getting a relative transform, there may be something in Unity I'm unaware of, but you could get the (world) transform of the part itself, then take a reference to the parent, get it's (world) transform, subtract, and end up with the relative transform, though it would also include any physics warping from the engine. If you can get ahold of the values from whatever is holding vessel prototypes nowadays, you could derive the un-warped values.

Hat's off to anyone willing to try fixing the stupid wobbly connections. Just sign this release form, insurance card, blood type, organ donor card, next of kin, living will, preferred institution for commitment, burial instructions, and you're good to mod. Here is where I left off, feel free to use/ignore anything there. The issue was temporarily solved in 0.17, but broke immediately when we got the fubar docking code, and I couldn't fix it without breaking the EULA, or doing insane things with Unity directly. Basically, the rockets are wobbly because Harv decided way back that it was just too hard to set up configurable joints properly(which are very poorly documented), and opted instead to use the quick and easy fixed joint, which is basically intended for stuff like making spitballs adhere to walls, not holding a rocket together. You don't necessarily have to use configurable joints to fix it, though that's what I did, the surface connections are/were hinge joints, which is why they don't wobble in quite the same manner. Settings like the physics iteration rate were hidden far beyond the layer of code we had access to with plugins back when I left, and I doubt you'll have much luck now, unless you manage to talk directly to Unity in the game scene, and get them to stick. A very serious problem I had was that fixing the wobble, and thereby making rockets an actual (mostly) rigid body, broke the terrain collision code; apparently, it actually relies on the wobblyness to compensate for it's inability to actually simulate terrain collision. To directly answer your original question: there is no answer. The physics engine Unity uses has a basic limit of around 10 for mass values. Obviously, 10kg parts means a very small rocket. Harv's solution way back when was to use mass units of "tons", or kilo-kilo-grams, and thrust(force) units of kilo-newtons, which together cancel out the extra "kilo" when calculating acceleration. I'm assuming you're asking about atmospheric pressures. Through testing(back in 0.17), I figured out the atmospheric model was basically using constant-temperature pressures equal to Earth std atmospheres. In absolute units, they convert to pascals the same way Earth atmospheres do, just remember the temperature is always 60F when using the gas laws. So: 1 KerboGram = 1000 kg 1 KerboMeter = 1 m 1 KerboSecond = 1 s 1 KerboForce = 1000 kN 1 KerboPressure = 1 atm = 101325 Pa and it's always a chilly 60F outside. The problem is that through testing gravity, I found out Harv still has/had the planets using masses in kg, which causes a very bogus big G, and throws the whole physics thing out the window. You don't notice it as much in game, because it's all specifically normalized to have the surface of Kerbin be the same as the surface of Earth, but if you dig at all, it falls apart fast. However, as long as you're only using Force + Mass -> Acceleration, the failure to scale length and time appropriately won't bother you too much.

I suppose I can at least ask, as the new update came out and all. Is it safe to return with my helicopter projects; or is the spaghetti monster still lurking in the bowels of KSP? Are things still run entirely through side effects on black box methods with all the real bits hidden behind private flags; or is the code base actually organized into something that won't give me nightmares? Has anyone on the team figured out how to use interfaces instead of constant breaking changes with every minor patch? Is it at all practical to completely replace a stock module without breaking the EULA? Not really expecting any good news, but I thought it was at least worth asking.

If you want to make something that doesn't require multiple parts, or is too complex for that, what you want is probably a single "Part" that is composed of multiple unity gameobjects, connected to the base gameobject with unity hingejoints/configurablejoints. The real problems with multiple "Parts" is that the overhead of each full part is massive compared to the overhead of just a gameobject; and if you're using parts, you have to fight the KSP spaghetti code to get them to behave the way you want. I'd start with reading some of the unity documentation tutorials here: http://unity3d.com/learn/documentation. When I had my helicopters flying, I was manipulating the rotor gameobjects directly, the white untextured monstrosity is all a single "Part" as far as KSP is concerned. In this case, I was setting their rotation directly each frame, rather than using joints, this is how the gimbal on engines works, or at least how it used to work. On that note, did nexis ever fix the spoiler tags, and if so, where's the syntax?

Trying to get a simple algorithm for propeller thrust. -Has to work inside KSP, so the ridiculous quadratics, blade sections, and look up tables are out. -Also has to work from static to stall, and operate in atmospheres with different densities. The first part I got from http://www.grc.nasa.gov/WWW/k-12/airplane/propth.html Momentum theory: force = PropArea * dPressure dPressure = 0.5 * AtmDen * PropDeltaV Already much slower than existing engine calcs, but it should still be workable. Problem is how to calculate the PropDeltaV, or change in air velocity caused by the propeller. Could derive this from a given power, or thrust, but I can't find a straightforward equation relating either: -power with "propeller efficiency",and air data yielding imparted delta v -thrust with some system of coefficients accounting for air data yielding imparted delta v This probably isn't too difficult, but I have the spatial reasoning skills of a blind infant, so any help would be appreciated.

Is the root of the problem, I believe. Unfortunately, my fix to the over-wobbly part connections just doesn't work as well as it did in 0.14. Inflight, it's mostly fine, but the ground contact code we have now makes stuff go crazy if the part connections aren't allowed to wobble and slide all over. Only safe way to deal with stack flexing is to extend something radial, and strut the parts to the distal ends of that, then strut the radial parts so they stay mostly in place.

I've done some more poking around under the hood' lately. I'm no longer completely sure the lag they gave us in 0.15 is directly a gfx issue. Using plugins to have a little tête-à-tête with PQS(The part of KSP that creates square terrain from a spherical planet), I'm starting to think it's either a setting that's never properly "set" in the code, or it's the "beaches" that are created presumably by land/water contact. It may/may not be "something in the water" exactly, but the new terrain system we got in 0.15 definitely kills FPS for a lot of us. 0.14 cleared up ALL lag, but 0.15 made it worse than it was in 0.13.

Recoded for 0.17 ED: Edited main post for fixed spoiler-ification of pictures/old junk BTW, spoilers now need "spoiler=Title" instead of just "spoiler". Many thanks to http://kerbalspaceprogram.com/forum/showthread.php/22864-Testing-Forum-BB-Codes

I sent the author a message, but haven't heard back in an hour or so, so impatience personified(me) just compiled my fix for using this with MajiirKerbalLib. Here's the fixed version: https://dl.dropbox.com/u/74137297/KFuelTransferFix.dll Note: Filename has been changed to avoid crossing the streams. Instructions: Drop this dll into your plugins folder and Move "FuelTransferMod.dll" somewhere safe. Do not use both at the same time. When Younata comes back and fixes this, just delete "KFuelTransferFix.dll" and forget about it. code is here again: https://dl.dropbox.com/u/74137297/FuelTransferModule.cs All I did was change the tank testing to use the Part.Classname string instead of runtime type comparison.

I was thinking the same about the multiline stuff, of course that could be a wrap issue, or '\n' issue, or a bunch of others. output_log isn't the problem, it's just highly annoying to not have a reliable in-game output for debugging stuff, having to close/restart KSP after every single tiny detail test is just impractical.

I've had problems with the F2 log in game being "lazy" since I picked up KSP, usually, but not always when something is screwy with someone's code. After taking out my frustration on my Esc key, I just noticed that the log does eventually reach the end of it's inbox and display current messages if it's poked enough with new messages. I'm wondering if anyone knows exactly why it gets backlogged, and if there's anything that can flush it to the bottom other than lots of new spam.

Appears this is incompatible with: Looked at his code, and he's ...erm... modifying the stock classes directly, which I didn't think was possible, but it's causing a problem when your mod goes to check for a stock fuel/rcs tank. The skinny: (in FuelTransferCore) -You're using ".GetType() == typeof(FuelTank)" which compares the runtime type of the part against the unmodified runtime type of the stock FuelTank class. -He's modifying the runtime type of the stock parts, including the tanks. -Result is you find no tanks, and the list for transfer is empty. I had to exclude the MuMech roboparts for a plugin I did, and found "part.ClassName" is set to the name of the class the part uses, and is just a string; bypassing typing, and multi-plugin dependencies. So I changed your stock tank checks(3 sets?) to: .ClassName == "FuelTank" and .ClassName == "RCSFuelTank" recompiled, and it all seems to work out in game. Here's the modified .cs file: https://dl.dropbox.com/u/74137297/FuelTransferModule.cs

Bump for pancake goodness.

Bumpage for 0.17 update

The thing about fuel/oxidizer loadout mismatch is mostly solved IRL by simple mission planning. Only in KSP do we just strap on some tanks/engines and liftoff. That said, fuel, at least LH2, is extremely light, as in virtually negligible in a functional rocket design, and again with LOX/LH2, the actual mass of fuel/oxidizer is also tiny, 1 LH2 : 6 LOX is the stoichiometric ratio, which in practice means it\'s the LOX requirement you have to worry about. The tank size (atmo drag), and cryogenic system that make it not so trivial IRL, but KSP doesn\'t really model those well enough to consider. When I had separate LH2/LOX tanks in KSP, I just setup a lot of 'structural' pieces to hold LH2, since almost all of the mass was the tank itself. In flight, this meant I had to guestimate the amount of LOX tanks I would need in space, add an equal number of matched tanks, and just build the rest of my chassis with 'structural' LH2 tanks, and I never really had to worry about fuel. As long as I brought along enough LOX to get through the space portion, I always had plenty of fuel to joyride through the atmosphere on return, and do a powered landing with fuel still in the tanks. If you\'re using separate vacuum/atmo engines, then you have to consider engine weight, as atmo engines are heavy, but if you have combined engines, it\'s just a flat engine mass increase offset many, many times over by not having to haul extra oxidizer through the atmosphere in the most demanding stage of the flight. If you are using separate engines, a powered landing doesn\'t really take that much fuel. The lower atmosphere does almost all of the work, so dumping the atmospheric engines may well give you a better working mass in space, but it also shifts COM, which could cause problems later on. If you want to adjust your landing after de-orbit, however, or if you\'re taking off again, might as well just keep them. Bringing along the jets could also let you do a deorbit burn with just LH2 if you set periapsis in the stratosphere, potentially saving a few orbits.

Interestingly, people were reporting the exact same thing (unexplained veer to north) with my old joint fixer plugin. I never did figure out why that happened unfortunately, and I tore apart just about everything trying to figure it out.

Bump for repackaging properly. No other changes made, except removal of version number in VAB, and recompilation. Proper 'even-draw' MuMech VariableTank (fuel tanks) proving problematic. I forgot about an old old 'feature' of r4m0n\'s engine code that only looks for stock 'FuelTanks' when dealing with stock 'fuel' requests. The problem lies in the stock tanks, which as of 0.15x, automatically use the stack draining rules instead of draining that particular tank when directly told to burn fuel. The difficulty is that r4m0n has tanks which still function properly, but they aren\'t considered when an engine is asking for stock 'fuel', and that feature is in the actual engine code, which requires a rewrite/release of the VariableEngine class, which would require parts to be assigned a different class individually(part.cfg). Fustration. Happy Summer Moddings. 'laser'

I think I\'m almost ready to work on KSP stuff again, so I\'ll start by harassing other modder\'s threads. Usual crazy code gibberish here: I did a 'quick' workup of a fix to the stock tank fuel draw problem(always uses stack, never the tank itself), but the only way to dig into it was hijacking the stock tank code with a PartModule, and I couldn\'t get the fuel box to display properly no matter what I did. Since I was already recoding the FuelTank class, and r4m0n already has a MuMechVariableTank class that still works like it\'s supposed to; and someone asked about air/rocket engines, and I never repackaged mine properly: I\'m just going to repackage the stock fuel tanks setup to use the MechJeb class. Anyway, if you want fuel tanks that work with DYJ\'s engines, and actually drain evenly, I\'ll stick a set at the top of the thread here Should be ready later tonight (few hours). Edit: Forgot about an old 'feature', going to be more problematic than I thought.

Good thing I decided to check this subforum for once. I made a plugin that extends mechjeb\'s rocket engine extension code so that it has an airbreathing mode, and a rocket mode, and switches automagically at a predefined altitude. It was an attempt to implement functionality for the SABRE engines for the SKYLON project, but the plugin was configurable to whatever specs you put in. Thobewill10 kindly made a model for it, but the code works with whatever model it\'s given. I haven\'t worked on it in quite a while, and it appears I never repackaged the last fix into a proper plugin, so I\'ll go do that now. The 0.14 versions ran on special LOX/LH2 tanks, but I think the 0.15 stuff runs on normal fuel, as the fuel system in 0.15 is um...'feature-full'. The thread is buried here:

Part.Modules is a PartModuleList PartModuleList has these: public PartModule this[int classID] { get; } public PartModule this[string className] { get; } Which are indexers is fuzzy memory serves, so if you know the classname of the PartModule: Part.Modules['MyModuleClassName'] should resolve to the module you\'re looking for. This is assuming the system is actually implemented that far. Edit: Forgot that those indexers return a PartModule object. If you want a reference to your actual PartModule subclass, you need to cast it. To do so safely: // //class MyModuleClass: PartModule { } //Part MyPart; // MyModuleClass module = MyPart.Modules['MyModuleClass'] as MyModuleClass; if (module == null) { //Error stuff here } End of pedantic reminders Happy Moddings