Action Group position seems to affect centerline Turbojet Flameout

[WanderingKid]

So, wondering if anyone else is seeing the same bit of curiousity I am.

Quick and dirty fighter jet, slap some air rams or whatnot on first, then 3 engines, making sure to attach the center engine last. Flameout happens as expected, center engine dies first. So, for giggles, I slapped the two outer engines into Action Group 1. Did not include the center engine. Suddenly, I get asymmetrical burnouts. Hrm.

Action groups perhaps get checked first? Put center engine into action group 2. Still asymmetrical.

Flip the order. Center engine in Action 1, outer engines in Action 2. Center engine flames out first.

All engines in Action 1, Center flames out first.

So, flip the test. Build the plane 'wrong'. Center engine first, then the two outer engines. Expected flameout - asymmetrical. Playing with the action groups again, put the center into Group 1, the outer engines into Group 2. Still getting an asymmetrical burnout.

Putting them all back in Action Group 1 doesn't help either.

So, as far as I can tell not only do you have to have the center engine placed last, you also need to make sure it's in a 'higher' or equal action group than the other engines to cause a center engine flameout first.

I'm wondering if this is an odd interaction of KER and Alarm Clock, or if other folks have seen this (and if I missed something in the wiki explaining it). If there's some research into this, can someone point me at the link? My google-fu hasn't been able to find anything on controlling flameouts and action group interaction.

I'm wondering if Intake-engine manipulation is also adjusted by action group location.

EDIT: I should mention, the Version is 25.0.642.

Edited December 12, 2014 by WanderingKid
Marking as Answered

[The_Rocketeer]

As I understand it, engine flame-out sequences are less about the order of engine attachment and more about the sequence of attachment of engines AND intakes.

It also seems like the action groups are resequencing the construction order of the parts (from a processing point of view). Why or how is another matter, and beyond my Kerb-fu - I'd guess you need someone who really understands the game code.

I would suggest you try adding your intakes to action groups as well as the engines and experiment a bit to see if this affects the flame-out sequence. You might need to put the intakes on 1 and 3 and the engines on 2 and 4 for example, to avoid closing the intakes when u toggle the engine.

It's all guesswork I'm afraid, but it's what I've got.

[LordFjord]

I really do hope that action groups do NOT affect this. I'm pretty sure they don't but you never know...

Otherwise, in order to get synced flameouts, you need to watch out in what order you place the engines and intakes.

Optimal would be:

- intake

- intake

- engine

- intake

- intake

- engine

(assuming same type of intakes)

Basic rule here:

First place all intakes of the engine, then the engine that they are used for (primarily).

Alternatively, you can give the mod I'm making a try, see the link in my sig. With it you can build your plane as usual, then hit alt-F and it will reorder all the engines and intakes of your vessel according to the rules above. Small warning ahead: its not release-ready yet, might contain bugs and whatnot

But I'm using it and it works fine for me.

[Claw]

As I understand it, engine flame-out sequences are less about the order of engine attachment and more about the sequence of attachment of engines AND intakes.

It also seems like the action groups are resequencing the construction order of the parts (from a processing point of view). Why or how is another matter, and beyond my Kerb-fu...

So the reason why placement matters is because the entire craft is a long list of parts. Each part is processed in what is essentially the order in which it was placed. The game runs through this list and runs each piece of code associated with the part. So for intakes, they generate air. For engines, they consume resources and generate thrust. At some point, the engines are asking for more air than what's available. One engine will ask for air and the entire ship will be depleted. No more air is available until the next time an intake is processed.

So, if you place all your intakes first, then the engines, you are guaranteed to starve the last engine of air because no more air is generated before the engines down the line are processed. However, if you place some intakes, then an engine, then more intakes, then an engine, the air generation/consumption process is interwoven. So the first set of intakes generate some air, then the first engine consumes it all. The second set of intakes generate air, then the second engine consumes it, and so on.

Action groups do not reorder parts. You can assign action groups during build, or after you're done. It doesn't alter part order.

I would say it's possible that on your run where the engines were on a higher action group, the game just happen to be in a position where the intake air resources were different than on your other runs. In that case, it might have just been coincidental that you got asymmetric flameout. All that being said, I also wouldn't completely discount that this is possible (as weird things do happen in this game). But it's just not normally mechanized to respond to action groups like that.

Not sure if that helps.

Cheers,

~Claw

[The_Rocketeer]

So, if you place all your intakes first, then the engines, you are guaranteed to starve the last engine of air because no more air is generated before the engines down the line are processed.

So basically, this is what you (WanderingKid) described in your first para.

But then you said:

I slapped the two outer engines into Action Group 1. Did not include the center engine. Suddenly, I get asymmetrical burnouts. Hrm.

I don't think that Claw's suggestions in his last para get us very far... I still think further testing is going to yield a better answer than hypothesising.

[WanderingKid]

It'll be easy enough for me to assemble a video showing what I'm talking about. I'll see if I can't get it together this weekend.

[Claw]

I think I understand what you mean. I'm just saying that the way the code flows for generating/consuming resources and how craft files are saved makes this behavior unexplainable.

But like I said before, it's still possible. There are lots of little weird things like this in the code. Maybe the game reorders the parts on launch, although I've never seen evidence in persistence files where action groups affect the parts sequence. Like The Rocketeer said, more testing!

Cheers,

-Claw

[WanderingKid]

Agreed, sorry Claw. Wasn't a slight against you, was just typing quickly. Appreciate the discussion. Clarification: I'll assemble a video soon(ish) to show what tests I've done as a reference point both for myself and others.

[Claw]

Agreed, sorry Claw. Wasn't a slight against you, was just typing quickly. Appreciate the discussion.

No worries. I think maybe I'm coming off a bit rude, and that isn't my intent. I was also typing fairly quickly and trying to make sense at the same time. So my apologies as well.

I suppose I'm trying to say that it's not that I don't believe you, I just can't imagine why it would be reacting this way. Also, I quickly tried out what you said and didn't get the same results (but it was an admittedly short test). However, after all the time I've spent in this game I'm learning that I can't just discount (or even believe) anything until it's really investigated it.

Cheers,

~Claw

Edited December 12, 2014 by Claw

[WanderingKid]

Nope, you're good. I recently came off a bit rude in this forum and wanted to make sure I didn't do a repeat. I might be a bit hyper-defensive about making sure I don't do it twice. Hold that thought, let me make sure the bug I ran into is repeatable and provable.

AKA: Pics... or it didn't happen.

[The_Rocketeer]

Well FWIW I was being rude on purpose.

I eagerly await further data.

[WanderingKid]

There's something more afoot here than just the action group involvement. I with I still had the .craft file I originally did this with, I saved over the original when I tested the engine reversal build. I've gotten it to happen twice more, which leads me to believe those incidents are user error of some form. Trying to nail down the exact reasons why it can occur/how to cause it. I fear that whatever was going on, I cleared the problem with a reboot of the box.

And Rocket if you were rude I'm in a world of trouble... because then I apparently have no idea what polite means.

(Edited for more clarity)

Edited December 12, 2014 by WanderingKid

[WanderingKid]

*sigh* Alright, note to self. Before thinking something is acting out of expectation in the future, reboot and retest before posting.

I know it was occurring when I posted this because it boggled me and I ran through it multiple times to make sure I wasn't imagining it or just a PEBCAK error. Now I can't get it to behave the same way.

I'll keep my recorders open and if I can get this to happen again, I'll make sure to get a movie of it. At this point I think it's just the 64bit instability, though.

Sorry for wasting everyone's time. I'll be over there, in the corner, feeling foolish.