Captain Sierra

I memory crashed the game without a single visual enhancement or part mod. We got on the topic of planet packs in MatoroIgnika's stream earlier and so I loaded up a bunch of planet packs onto one install (this was a fresh 1.0.4 test install just for this; as always, I was forcing DX11). That's Outer Planets Mod, KerbolPlus, New Horizons, and Trans-Keptunian. EDIT: Kerbin is now a moon, with a bunch of friends. And Jool got even more moons, including Duna!

I think we're going to see some kind of desync/instancing system like DMP where, by initiating time warp, you break the synchronous and have to reengage it later. Squad has talked about having a server module functional, so the possibility of dedicated servers for KSP I believe is very real (I think it would be highly advantageous for all these collab projects on the forum). I don't expect any kind of server browser. Likely it will be direct-connect with a bookmarks tab or something, much like Minecraft. Though I'm curious to see how this works from a non-server-based multiplayer perspective (which would no doubt be a huge selling point; open your game to MP for a bit to show off your station to a buddy or something). If you need to open ports and have static IP just to host a non-dedicated multiplayer session, that will be a huge detractor. KSP, by dint of being a hard game, will likely not have many problems with trolling (smashing stations, draining fuel, etc.)

Nice. Though if you look back three pages to Nertea's plan for the 2.1 update ... Your TB2 elevator bay is coming.

Whackjob would be proud.

I'm more impressed this thing flies okay under stock aero than the accuracy of the replica.

Back when these parts were smaller, it probably was. Nert has a larger VTOL engine on the to-do list which will probably be necessary for proper TB2 replicas. Is a wholly fictional aircraft something that's a solid basis for a somewhat realistically balanced pack? (I kid I kid, thunderbird replicas are stupid fun)

I like the idea of them only being switchable in the VAB. I think that'd be a fun limitation. Not sure how that'd be doable though. IS Mesh Switch?

I'll also point out the multiple times we've had SRBs blow up on us. Russia may be onto something ...

:0.0: :0.0: :0.0: I have no words ...

Our aerospike is only about half of what actually is there (and this schematic is for a 12cm model rocket, gravity fed, so no turbopump).

You're kind of right. I did some digging and here's what I found: The STAGE_PRIORITY_FLOW queries once from the root part to identify a part's stage (which you were monitoring with your plugin), unlike STACK_PRIORITY_SEARCH which queries from the engine, respects decouplers, and searches every time the engine runs out of a resource from its current source. STAGE_PRIORITY_FLOW tries to drain fuel based on what it thinks is the lower stages (remember, this was designed for monopropellant/RCS, not jet engines). On rockets, where your root part is almost always on the payload (or, in less frequent cases, on the uppermost stage), this works just fine. However, as my OP demonstrates, the system breaks down for cargo-carrying planes. Since a plane's root part is usually the cockpit, or at the least, on the plane, the game mistakes the payload for a lower stage drop tank and is pulling fuel from it thinking you'll jettison it mid-flight. As a sidenote, I considered proposing making the flow mode respect occlusion as a fix. This would prevent tanks in cargo bays and fairings from being drawn off of, but would also prevent the stowage of monopropellant tanks inside service bays (which is a perfectly legitimate and commonly used engineering strategy). - - - Updated - - - Which is why this is the bug. Technically, as much BS as it is, drawing across decouplers is a "feature" of this flow mode.

Okay I'm confused now. There's comments in my thread that read like their out of context, and general confusion. I appreciate the de-merge, but now I got a mess to untangle. EDIT: To update: This new fuel flow mechanic is an intentional change, but it causes the detrimental side effect of draining upper stages before lower stages due to how the part tree check works. This thread is specifically about the draining through decouplers first. There exists another thread about getting the mechanic reverted in general elsewhere. I'm updating the OP with this info.

THe core of the problem is that the search is being run one time based on part tree, not relative the active engine like for standard liquid rockets. if the query was done based on engine position (and possibly if it respected occlusion), it could be made to work (but this is technically a bandaid fix for a poorly planned design decision).

Yeah I understand. You're fully aware its an entirely undesirable mechanic, but hesitant to "fix" what technically isnt broken, even if it is detrimental. I cant say I know what its like to be in that position, but I can definitely understand your bind. Also the part you interpret as "dont bring this up" was not geared towards you. I fully expected Sal or one of the other game-mechanic-savvy mods to pop in and dismiss this for being not a bug, and in that case I'd defnitely have to fight to keep my bug report. It is as simple as removing that line from the .cfg (which reverts them to standard liquid fuel engine behavior), but a) I want to keep the even tank draining, and we the players should not have to edit our game files to avoid bad development decisions (this IMHO being a relatively poorly thought through one at best). Totally agree. Fuel crossfeeding across a part which explicitly states it does not allow certainly seems to match this, though as I understand what's going on under the hood, there technically isnt any code malfunction here. Whether or not we can declare this a bug is highly dependent on how we frame the issue. - - - Updated - - - I didnt even catch that in Claw's post. Yes, you basically hit my point on the head. This is the problem, this is the bug, and this is what needs fixing.

First guess is memory crashing. You can force OpenGL or DX11 to improve RAM usage, or cut back on mods. I'm also always available for help if people PM me.

I actually knew this going in, but a "feature" that makes your life harder instead of easier against its design more often than not, to me, is the definition of a bug, intentional or otherwise. Additionally, decouplers explicitly state they do not allow fuel crossfeed, but this is not respected. When the game tells you something, then contradicts that, ... you see where I'm going. Lastly, if I wanted fuel to flow across decouplers, I'd use a fuel line. Thats how we did it way back when. I acknowledge the all-tank fuel draw would be fine if it were per-stage. That part of this new fuel flow mode is not bad, just the lack of respect for decouplers. Also I knew going into this I'd have to fight to call this a bug, but I believe I've made a solid enough case to document this as a problem, intentional feature or otherwise.

Definitely this. I'd add a non-airbreathing set of VTOLs to the A set. ALso how do you plan the cargo elevator? I cant see how that'd work without taking IR as a dependency (and I've had a bad experience with IR and so hesitate with that). Also, an idea for a cargo ramp/cockpit part. You have the hollowness of the crew cabin, so what about adding that same hollowness to the Thunderhawk cockpit and making the part of it below the cockpit section split open side-to-side? Might do some crappy MSPaint mockups for ya later.

Cargo bays don't do anything special with the part tree. Unity sees no difference between using the cargo bay or a bicoupler in this scenario (at least thats what my approaching 2000 hours and very limited Unity experience tells me). Yes definitely lock tank contents, but if the scenario is a lander with many tanks buried under other parts, that gets harder. Locking of tank flow should be toggleable via AG.

I must confess I didnt use EE at al up until the other day post 0.90. It came back into my rotation after I tried and removed B9 wings. You're the second one reporting this and I cant replicate. Are you attempting to place the part in radial symmetry? Due to how that works in KSP, placing it in radial symmetry greater than 2 can often cause floating placement. This is also observable with any other part on the mk2 fuselage.

Yes. Worth it? Very much.

No, because you're on point. THe fuel flow logic change with jet engines is completely whack to the point of RAPIERs ignoring decouplers (I logged this as a bug in unmodded support). It only makes sense the fuel cells should obey more understandable fuel flow logic. Kod knows KSP fuel flow is suck misunderstood black magic as it is.

I take extremely unkindly to people who automatically assume x64 is the root of every problem someone has. 1) That was in reference to KJR exclusively, since it disables itself on x64. 2) my current general use install is not even x64, only my cinematic one is so I can run AVP for awesome screenshots. Don't assume because the word "x64" ended up in my post that it's whats wrong. I've had bugs under 64 bit that I have traced all the way back to vanilla 32 bit and reported. I've been lucky to have, outside of 0.90, a very stable x64 installation with no fatal errors and very little mod flaws. Try to get some more info before daring to make assumptions like that.

Claw, I made this report here: http://forum.kerbalspaceprogram.com/threads/129945-BUG-Decouplers-not-stopping-fuel-flow?p=2105401#post2105401 Since there's such a long wait to 1.1, I beg you. Deliver us from this evil.

Plugins of note: Interstellar Fuel Switch BahamutoD Animation Modules EditorExtensions Firespitter HyperEdit Kopernicus No Offset Limits Stock Bug Fix Modules There's a bunch more but they're more minor or I'm assuming have no bearing on why the procedural wings don't work. The KJR problem is usually result of my craft not needing KJR-level stabilization and thus applying that much strength is causing kraken summoning (also I run x64 half the time so there's that).

Overview: All jet engines, including the RAPIER regardless of mode, draw fuel from across decouplers and, additionally, draw fuel from tanks separated by decouplers first. Symptoms: Fuel is drawn from tanks that are segregated by decouplers without the presence of a fuel line. This is highly detrimental to airbreathing SSTO spaceplanes attempting to deliver fuel-containing payloads to orbit. Below is a test craft which represents a cargo-containing SSTO and demonstrates the detriments of this. Repro Steps: Build To build: Place Mk2 cockpit as root Add large mk2 cargo bay Add bicoupler Add two RAPIER engines on the bicoupler Place 1.25m stack decoupler inside bay Place Mk1 jet fuel tank on decoupler Secure craft with launch clamps Varify the RAPIERs are in the first stage and everything else is not Launch, throttle up, and stage once. Upon RAPIER flameout, inspect fuel quantities of both tanks. They should look like Other Applicable Info: As evidenced by my UI, I tested this in a heavily modded 1.0.3 version of KSP running on DX11. I received assistance verifying this issue's continued presence in vanilla 1.0.4 from other forumers in the KSP forum Steam group (shoutout to those guys for that). Spike sent me his screenshot evidence viewable here. Update: So apparently not even fuel lines can prevent this issue: Image courtesy of the Steam group guys. UPDATE 2: Following thread merge confusion, this thread is now exclusively related to jet engines drawing from decoupler separated tanks before others. Fixing other problematic "features" of this flow mode change is the topic for another thread (which I very much intend to start in Suggestions later). There's also another thread (that's somewhat old now) reporting the same problem which you can view here. This issue specifically appears to be related to how the fuel search is working. Unlike normal liquid engines, the search is done only once and is done relative the root part, not the engine. It targets tanks which will be decoupled first, and tanks that wont be decoupled at all last (this was designed originally for monopropellant). If your root part is not on your payload, the game treats your payload as a drop tank. It should look like on the runway.