Kellis

Pulled out and dusted off KSP after after letting it rust for a year, made sure to install KSPIE, and have since been quite enjoying myself again. FreeThinker: many thanks for your efforts on this mod! So - Recently started fiddling with the Timberwind thruster, and noticed that the exhaust plume is.. a bunch of black squares? Did some searching to see if anyone else had run into the issue, and found Issue 132 on Github. Further spent a while mucking around with the part .cfg to see if I could figure anything out. Switched out the model, went in and disabled various FX modules, and basically just tried to find anything that might affect the exhaust. Failed utterly. So, guessing that some configuration of custom exhaust settings are at issue, does anyone have suggestions as to what bit I might look at to un-custom it? Is that possible?

FYI: At first glance, this has also fixed the issue with the resources popup not being accessible from the Tracking Station.

The standard M700 Survey Scanner from stock. The duplicate definitions thing is an interesting thought. I may fiddle with that, tonight, and see what sort of resource overlap there is on every planet but Kerbin, Pol, and Bop..

Running into something odd, and thought I'd throw it out here...Looks bug-ish, though possibly a Kellis-did-something-stupid... Fresh KSP install. Grab the KSPIE .zip from the front page. Copy everything in. Start KSP. New sandbox game. Create a "ship" with a probe core, scanner, batteries, and antenna. Edit it into Munar orbit. Scan! Scan works, transmits information to KSC, and the moon glows white from whatever resource it just found. Return to the KSC, and hop over to the tracking station. Tab to the moon. No resource overlay. No resources listed in the popup from the resource button. Checked the console log and KSP.log for anything suspicious. Right upon switching to the tracking station, there's a (shall we say) suspicious. [LOG 20:43:27.756] [Tracking Station]: SetVessel(null) [LOG 20:43:27.757] [PlanetariumCamera]: Focus: Mun [ERR 20:43:27.796] Exception handling event onPlanetariumTargetChange in class KnowledgeBase:System.NullReferenceException: Object reference not set to an instance of an object at ResourceMap.GetResourceItemList (HarvestTypes harvest, .CelestialBody body) [0x00000] in <filename unknown>:0 at KSP.UI.Screens.KbApp_PlanetResources.CreateResourceList () [0x00000] in <filename unknown>:0 at KSP.UI.Screens.KbApp_PlanetResources.ActivateApp (.MapObject target) [0x00000] in <filename unknown>:0 at KSP.UI.Screens.KnowledgeBase.ActivateApps (KbTargetType targetType, .MapObject target) [0x00000] in <filename unknown>:0 at KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (.MapObject target) [0x00000] in <filename unknown>:0 at EventData`1[MapObject].Fire (.MapObject data) [0x00000] in <filename unknown>:0 [EXC 20:43:27.800] NullReferenceException: Object reference not set to an instance of an object ResourceMap.GetResourceItemList (HarvestTypes harvest, .CelestialBody body) KSP.UI.Screens.KbApp_PlanetResources.CreateResourceList () KSP.UI.Screens.KbApp_PlanetResources.ActivateApp (.MapObject target) KSP.UI.Screens.KnowledgeBase.ActivateApps (KbTargetType targetType, .MapObject target) KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (.MapObject target) EventData`1[MapObject].Fire (.MapObject data) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(MapObject) PlanetariumCamera:SetTarget(MapObject) KSP.UI.Screens.SpaceTracking:SetVessel(Vessel, Boolean) KSP.UI.Screens.SpaceTracking:OnSceneLoadRequested(GameScenes) EventData`1:Fire(GameScenes) HighLogic:LoadScene(GameScenes) KSP.UI.Screens.SpaceTracking:BtnOnClick_LeaveTrackingStation() UnityEngine.EventSystems.EventSystem:Update() From some poking around, the only other place I found someone reporting something like this was when they'd been hacking around in the Community Resource Pack and managed to remove some resource or other that was used by one of their mods. This doesn't seem to affect the operation of anything while running a ship - only the ability to choose a resource to view from the tracking station. Leaving the resource overlay on from a ship results in the overlay still showing (and there being no way to disable it) when switching to the tracking station. Removed just the KSPI WarpPlugin folder and restarted and ran exactly the same steps again - just to verify it wasn't the rest of the mods (or, heck, just the CRP, alone). Without KSPI, the Tracking Station works just fine..so it's either in KSPIE or in an interaction KSPIE has with someone else... Managed to track down a couple oddities in atmosphericresourcedefinitions.cfg looking for anything suspicious... LqdHE3 instead of LqdHe3 (dunno if case matters) LqdDeutrium instead of LqdDeuterium (missing e) ...not that the typo-fixing solved the issue. It happens when attempting to view minerals at the Mun. At Minmus. But not after scanning and viewing Kerbin. Huh. Kerbin works Mun doesn't. Minmus doesn't. Duna doesn't. Ike doesn't. Dres doesn't. Jool doesn't. Laythe doesn't. Vall doesn't. Tylo doesn't. Bop works. Pol works. Eeloo doesn't. ...not sure what Kerbin, Bop, and Pol have in common. Given everything is still usable from a ship, it's not exactly critical, but...Figured I'd report to see if it's something that's known or others have seen, or if I've just managed to muck up, somehow.

Looks like Nertea has put out a(n early version) "Cryogenic Engines Pack" which along with a liquid hydrogen fuel for the new engines also includes a Module Manager patch to try to add Firespitter tank switching to all tanks that don't already have it. You might try that, or if you don't want the full mod, see what's happening with the MM patch file and see if you can just keep some portion of that. http://forum.kerbalspaceprogram.com/threads/117766-1-0-Cryogenic-Engines-Pack-%28high-Isp-chemical-rockets!%29

It sounds like he's referring to something using the Firespitter dll to allow switching between "tank textures" and contents; a little next/previous button is added to the right click menu in the VAB/SPH. That's not Modular Fuel Tanks, which instead lets you specify the volume (up to a max) of which fuels to add to a tank, and which doesn't use Firespitter.. USI's Freight Transport Technologies (RoverDude) http://forum.kerbalspaceprogram.com/threads/91706- and Munar Industries - Fuel Tank Expansion http://forum.kerbalspaceprogram.com/threads/109885 both provide tanks that use it, for instance. (Assuming I'm remembering correctly.) B9 might, as well? I've not actually seen a mod that adds that capability to the stock parts, though it does sound like it would be incredibly useful. From what I remember from poking through the .cfg files for the two listed mods, it shouldn't be too difficult to set something up. Probably tedious, since it might require each tank to be Module-Manager-configured separately. (Disclaimer: only fiddled with modding for my own amusement, so not overly familiar with either Module Manager or the Firespitter FSTextureSwitch module..I think that was the one.) ...be far nicer to find such a thing, admittedly.

My solution for Tritium, so far, has been to create 3.75m Fission reactor farms using 'Tritium Breeding' to produce Tritium from Lithium. Of course, you still need to supply the Lithium, and anywhere except KSC, that's going to be...challenging. That said, if you build a silly enough structure on the launchpad, 40 or so reactors will produce it pretty quickly. You can then either have tanker trucks come pick the Tritium up (using KAS to transfer, or some such), or just recover the structure for stupid amounts of cash - which you can then turn around and spend on Tritium for the same net effect. That still leaves having to send resupply tankers out from Kerbin, but at least alleviates the cost issues. I haven't fiddled with it, given the relatively inexpensive nature of Deuterium, but I think it's the science lab that has to be splashed down to produce it, not the ISRU.

Maybe; I've run into an odd issue where the little green Kethane window in the map view turns into a couple of green bars, and the kethane map view goes away. I'm not completely sure of what's causing this, but I have observed that once the problem occurs, it's baked into the mod folder - affecting all saves, even new ones; I can remove all other mods but Kethane, and start a new game, and the problem persists. If, however, I leave all mods in place and reinstall the Kethane mod fresh, all saves are fixed. I doubt it's related to a parts pack - if whatever is happening is causing Kethane to bork its save mechanism, it'd almost have to be a plugin. (Almost. Computers are ornery.) Likewise, I doubt that it's MechJeb; too many people use it, so you wouldn't be the first report I've seen of the problem. That said, a list of active mods for comparison purposes: Kethane (of course) Protractor MechJeb Engineer Redux KSP Interstellar Assorted bits from NovaPunch 2.03a At the moment, I'm suspicious that the problem is somewhere between KSP Interstellar and Kethane, as it's the mod I've just begun fiddling with (lots of shinies!) and there were log messages from it in the ksp log fairly close to where Kethane freaked out. That said, I haven't yet thrown together a clean install with just those two mods to see if I can replicate, so I'm not sure if that's really where the problem is, yet. My untrusting and suspicious mind informs me that both KSP Interstellar and Extraplanetary Launchpads make use of Kethane, and were presumably put together to work against the previous 0.7 release(s) of Kethane, and may still work against 0.7.x but not yet against 0.8....something else to check on, I suppose. EDIT! Quick attempt at replication did not result in replication. Whatever it is, it's not going to happen just from loading up those two mods, and a few minutes of goofing around. Will watch for it happening, again, and try to remember to save the log files, next time.

It's harder to do, but one thing you can do for larger payloads is actually split the "core stage" into multiple core stages, and attach them at the corners of your payload. Attach boosters/asparagus stages outside of each of the core stages, and each core stage is only lifting 1/nth of the total mass of the payload. It can lead to some nasty strutting problems and inefficient staging patterns, because you sometimes need to keep dead weight around simply so there's enough stuff left to strut together, but in return, you can lift some truly large payloads, if you're willing to deal with the lag. (Can link imgur, if anyone actually cares; I'll refrain from image-spamming, for now..)

Looks like mumech has handled that one, Foran; it's been updated. Easy fix, I guess? Okay. Possibly esoteric question- I've not found any discussion on the topic, so I'll toss it in, here, and see what happens. I've been playing with decouplers and trying to determine how they work.. it looks like there are three different types (RadialDecoupler, Decoupler, and DecouplerGUI), and RadialDecoupler and the other two work differently. The RadialDecoupler appears to "let go" of its parent, and take all of the children attached to it with it. The Decoupler/DecouplerGUI, on the other hand, doesn't seem to let go of the parent, but instead lets go of the "top" node - at least, as far as the included default decouplers are concerned. That looks like the last (second?) element in the attachNode list, but I'm not finding anything that indicates why that's the case. I can just assume it's dropping the last attachNode and run with that, but I'm not sure that's really the correct answer; should I be looking at some other bit of data to tell me this? (Why do I care? Playing with complex delta-V calculation from the VAB, and it rather matters which bits fall off when a decoupler triggers, since you could conceivably attach silly-large weights to the surface of the decoupler instead of just using the thing "normally"..) Thanks for any assistance; this one currently has me stumped...

Delta V for a simple rocket isn't too bad, really.. Do a google search on "rocket equation" for more than you'll ever want to know, really. For a not-simple rocket, though...things can get just a little bit nasty.

How fast are you going, and at what altitude? It's possible that your engines can't overcome atmospheric drag. Really low in the atmosphere, 150m/s takes some doing, though it gets better pretty quickly..

Yeah, for something like this, you'd probably want to only calc the numbers at button press during construction. You know - "Hey - what's it look like now?" And what I scribbled doesn't even get into the whole boosters-with-fuel-lines thing, or circular maps of fuel lines (...ack) or inexact floating point numbers, so you're not really looking for empty tanks with ==0 in the first place, or... Silly fuel lines, you might at least be able to detect and refuse to try. Encourage smart rocket design, and all. I'm tempted to see what the API is and what data would be available, and what it would take to throw that sort of algorithm together. The one you're currently using absolutely has simplicity as a virtue.

Before I get into things - thanks for this plugin - for simple designs, it can be pretty dang useful. For more complex designs, it can still help a lot for upper stages... That said: Wall-o-text warning... tl;dr calculating delta v and algorithms and math. Hopefully, even, correct math. Maybe. ...I can't believe I'm registering for a forum account just so I can discuss fuel flow and delta v calculation under complex staging situations, but.. ..there you have it. Anyhow. To calculate delta v, we need to know just where the fuel is coming from, and when, and when we're decreasing the amount of dead weight we're hauling around. That leads to a few issues that need to be solved. When do we get rid of dead weight? We're getting rid of fuel weight all the time - that, alone, is several problems, actually - but we only drop dead weight when we stage - or explode, but it's not like that would ever happen, would it? So that means we need to know just when each bit of the rocket falls apart. ...assuming no explosions. Parts look like they're attached to each other as a tree; you can only attach parts to parts that are already attached to other parts, and you can't attach a part between two other parts. So to find out when a part falls off (no explosions!), start from the center of the graph (the command capsule), and work outwards. A part falls off when the decoupler it's attached to falls off. Walk the graph and just assign each part a number based on the highest stage of the decouplers you passed in the graph to get there. It's absolutely possible to stage a decoupler in stage 1 when it's attached to a part that is attached to a decoupler that detaches in stage four. Wishful thinking aside, any parts under that stage 1 decoupler will still be gone in stage four. So now you can get the stage where anything falls off. What engines do I need to care about, right now? Hey - an easy one! Engines first fire in a designated stage and stop being important when they fall off the ship. We care about all the engines that have been staged, and haven't fallen off the ship. They may not be firing because they're out of fuel, but we have to figure out they're not firing to figure out delta v - so we still care. Where is the fuel coming from at any point in time? Assuming a graph you can follow around fuel using, providing, and transferring items...to determine where fuel is coming from for a particular engine, start with that engine as the first node on the graph, and start walking.. Here's what my experimentation has shown me regarding fuel flow: If there something attached to this node using fuel line(s), then fuel will arrive via the fuel lines. All of them. If fuel arrives via fuel lines, it will not arrive via direct attachment. So for each part attached via fuel lines (that has fuel), go to that part, and follow this algorithm. Recursion! Yay! If you're not receiving fuel via a fuel line, and there is something (with fuel) attached to an attach point, then fuel will arrive via the attach point. If you're using a mod that provides fuel-flow-capable objects with multiple attach points, then fuel will arrive via all of those attach points where there's fuel. Unmodded, this really only applies to fuel tanks, as far as I can see. Again, recursion and track where the fuel is coming from. If nothing else is providing fuel, then this node is providing fuel. If it has any. Fuel flow comes equally from all places it's coming from. If I attach two tanks to an engine using fuel lines, then half of the flow comes from each tank. If I attach two tanks to one of those tanks, then there are three tanks fuel is coming from, and equal flow comes from each. I do not split the flow in half from the first point where there are two lines, and then split it again from the second. There are three tanks providing fuel, so each provides one third of the fuel for that engine. It doesn't matter whether a "node" is an engine or a fuel tank - you can attach an engine directly to a fuel tank, and then run a fuel line from a different (unconnected) tank to the engine. The engine will feed through the fuel line first, and only use the direct-attached tank when the fuel line isn't providing fuel anymore. If you use a fuel line to pull from the middle of a stack of fuel tanks, you will end up pulling fuel from both ends of the stack. Want a truly delightful experience? Stack three tanks on top of each other. Stick one tank off to the side. Put engines under both the stack and the single tank, and run a fuel line from the middle of the stack to the single tank. Light that sucker off, and look at the flow rates. Single tank? No flow - fuel is being piped in from the stack. Center of the stack? Again, no flow. Bottom of the stack? Half of the flow necessary to fuel the engine over to the side. Top of the stack? The other half of the flow for the other engine, and the full flow for the engine directly beneath. Distance traveled seems to be completely unimportant. Rocket surgery. What can I say? Once a tank is empty, it stops providing fuel, of course, and you need to re-calc the graph. When that top tank in this example runs out of fuel, then the middle tank is supplying all the fuel for the stack's engine, and the bottom tank is supplying all the fuel for the engine under the single tank. Fun. This becomes important when we start caring about how much fuel is coming from where. Confused, yet? We're just getting started. Fuel density For the stock parts, fuel is an even 200l/kg. (0.005kg/litre; whatever) Not so, unfortunately, for modded parts. Parts specify a full weight, an empty weight, and the litres of fuel that fit. This becomes important, in a bit, because it can really futz with our math.. Fuel flow over Isp or Modded parts and the amazing changing fuel density This is a little off-to-one-side, but will become important for calculations... Fuel flow is calculated in litres, and part weight in kg in the VAB. There is no direct relation between these two numbers. Stock parts all have 200 litres to a kg. Mod parts may not. Why is this important? Because the Isp on the engine is calculated based on the assumption of 200 l/kg. Start using modded parts, and the weight of the fuel changes, and you end up with different actual Isp. You can still calculate the flow through an engine based on the provided Isp, and the fuel flow rate remains unchanged despite the weight of the fuel in question. So it's better, for each engine we're playing with, to know the flow rate per second, instead of the Isp listed on the part. Oh - and we want to calculate this for both atmos and vacuum. What information do we have? Isp - measured in seconds. Thrust (F) - measured in Newtons, or kilogram-meters-per-second-squared. (kg*m)/s2 g - gravity; 9.8 m/s2 expected fuel density - 200l/kg From this, we can get flow rate of litres per second. Eventually. Actually, I've read hints that l/s is provided for the part; maybe Isp(s) is calculated? If so, that cuts out this little section. If not, though... From Isp, we can get effective exhaust velocity - which is Isp*g. From effective exhaust velocity and force, we can get the burn rate in kg/s. From that, and the expected fuel density, we can get litres per second - even if the density of the actual fuel changes, the litres per second burn rate still holds true. An example. If you take a 1.125 ton fuel tank and stick an aerospike on it, you'll last about 15 seconds at full burn. How do you math that out, though? Isp = 390s, g = 9.8m/s2, so effective exhaust velocity = Isp*g = 3822m/s That effective exhaust velocity is producing a force of 250N, or 250 kg m / s2..sooo... 250 kgm/s2 = ??kg/s * 3822m/s ??kg/s = 250N/3822(m/s) = 0.0654107796...kg/s. Yes; remember that the VAB speaks of kg, not metric tons. We have 200l/kg, so that little bitty number ends up with: 0.0654107796...kg/s * 200l/kg = 13.08l/s. Our aforementioned 1.25 ton fuel tank has 200 units of fuel. At 13 per second, 200l / 13l/s = 15.288s. So the flow rate for any given engine in l/s is (200*F) / (Isp * 9.8). Plug those numbers in again, just for paranoia. Yup, (200*250)/(390*9.8)=13.08l/s So we can now find both the atmospheric and vacuum fuel flow rates for any given engine. Good. We'll need 'em. Solid Boosters or Hey, look - a simple bit! Solid boosters are quite a bit simpler. We know right out their thrust, full and empty mass, and burn time. Calculating their burn rate in kg/s is a trivial (full mass - empty mass) / burn time. The Algorithm or Where the *yay!* is he going with all this, anyway? Judgement call time. Maybe even two judgement calls. For any given stage, we need to know whether we should calculate under atmostpheric conditions, or under vacuum conditions. We can try to math that out and come up with current altitude based on expended delta v, mass, g, air density and drag... or we can just ...gently caress the matter and let the user poke a toggle. I vote the latter. Likewise, we need to know when the user is going to want to eject a given stage. Which is most important? As soon as possible, as long as we don't drop empty tanks? Or maybe wait until no engines will be ejected that still have access to fuel? Another user determined option, perhaps? Regardless, for a given stage, you have a known current mass (we start with all pieces except launch gantries, perhaps), and a number of engines that could be firing, based on their positions in the staging list. So. Starting stage is max stage number... Start loop. Check to see if we should stage. If the user wants to stage as soon as it won't drop fuel, then check all the fuel tanks that will be dropped by staging. If they're all empty, it's time to stage. Decrement stage counter, drop any items that should be dropped, and recalc your current mass. If the user wants to stage only once you won't kick off any active engines, then find the engines that would be dropped next stage and see whether any of them have fuel. If they're all out of fuel, it's time to stage. Decrement stage counter, drop any items that should be dropped, and recalc your current mass. For each solid fuel booster that should be firing: Remember how many seconds of firing remain, and remember or calc mass remaining. Seconds remaining = (max seconds) - (seconds fired already) Mass remaining = (empty weight) * (seconds remaining) For each engine that should currently be firing: Find out which fuel tanks it's drawing from. See above notes on tracing fuel flow. Find out how much it's going to draw from those tanks. Essentially, calculate the l/s flow for that engine at full blast and tag each affected tank with that number. Keep in mind that each tank can have multiple engines drawing from it. When doing this, remember whether you're using atmospheric or vacuum flow rates. For each tank that has engines drawing from it: Remember how much fuel it theoretically has - if it's already been used, it's not full any more.. Find out how much fuel is being used per second from that tank - sum up all the tags from the firing engines. Find out how many seconds of burn are left at this burn rate. For all solid rocket boosters and fuel tanks, find the minimum number of seconds before something is empty. Drain all affected tanks and rockets by that many seconds, based on the burn rate. Calculate current mass. Clear any tags for the next time through the loop. Run the rocket equation. Things get just a tiny bit wonky, here, since you don't have a total Isp for your ship. So calc one. Remember that F = Isp(m/s) * mass flow rate, so Isp(m/s) = F / mass flow rate. Mass flow rate = kg/sec. How much did things weigh before? How much to they weigh now? Divide the difference by the number of seconds this time through the loop, and we have a mass flow rate. Sum up the forces granted by all active engines, then divide that by our mass flow rate. We now have an Isp(m/s) to throw into the rocket equation. dv = Isp(m/s) * ln(m0/m1). (or Isp(s) * g(m/s2) * ln(m0/m1) ..you can calc Isp(s) from Isp(m/s) by dividing by g... sooo technically, dv = (Isp(m/s) / g(m/s2)) * g(m/s2) * ln(m0/m1), but that's just a tiny bit silly.) That's the dv for this little segment. Now it's back to the top of the loop and do it all over again. Sum up these dv for each stage as you go. Now isn't that simple? Mind, I'm not sure it's worth it to you to run something like this, and there's no absolute guarantee my math/algorithm isn't missing a step somewhere, but if I haven't slipped a few gears, I think this is an algorithm to calculate the dv for a complex-staged vessel. Egads..maybe there's a simpler one? Please?