Devnote Tuesday: Fuel Flow

[Terwin]

17 minutes ago, OrbitalBuzzsaw said:

Will 1.2 have an option to toggle  the new RemoteTech-style antenna mechanics on/off?

RoverDude has mentioned it being switchable multiple times, so I would guess Yes.

 

Edited July 27, 2016 by Terwin
Adding links to RoverDude posts

[OrbitalBuzzsaw]

3 hours ago, Majorjim said:

Can anyone confirm if we will, yet again, have to redesign craft after the rocket parts update? 

That's the other thing that makes me hesitant about 1.2.

Just now, Terwin said:

RoverDude has mentioned it being switchable multiple times, so I would guess Yes.

 

What about toggleable on/off on separate save-games?

[Kerbart]

Wasn't a considerable amount of work spent on fuel flow in the last release? And now it's already being reworked? Or was that prep work for what's being done now?

[Red Iron Crown]

3 minutes ago, OrbitalBuzzsaw said:

Will 1.2 have an option to toggle  the new RemoteTech-style antenna mechanics on/off?

I believe that was mentioned in previous Devnote comments, the answer was yes.

[Terwin]

17 minutes ago, OrbitalBuzzsaw said:

What about toggleable on/off on separate save-games?

I scanned over RoverDude posts back to May, and did not see any specific references to per-save settings, so I would guess it is a per-install setting, but that is just a guess.

Of course per-install vs per-save does not mean a whole lot with KSP as it is trivial to copy an entire install and then change the setting in question...

 

[Red Iron Crown]

13 minutes ago, Terwin said:

I scanned over RoverDude posts back to May, and did not see any specific references to per-save settings, so I would guess it is a per-install setting, but that is just a guess.

Of course per-install vs per-save does not mean a whole lot with KSP as it is trivial to copy an entire install and then change the setting in question...

 

I would imagine it would be per save as a difficulty setting, but that is just a guess.

[Streetwind]

Yeah, all mention I heard of it being configurable was in relation to difficulty settings.

[Alshain]

11 hours ago, AlamoVampire said:

except @Alshain the check is killing things on the OUTSIDE of bays. This is nothing near intended. Not only that, it seems you can fire engines THROUGH CARGO DOORS. please tell me how

Yes, that is part of it.  There are two issues here.  It's using other functionality that was already in game and there is a known issue where things attached to a cargo bay's outside are considered inside.   That issue has been around since cargo bays were introduced.  If you were to go back to 1.0.5 and put a parachute outside a cargo bay, for example, it wouldn't deploy why the bay doors are shut because it thinks it is inside.

The second issue is that they added that 'stowed' mechanism intentionally to the wheels (because deploying the wheels in a cargo bay would cause issues), inadvertently invoking the above issue.  Funny thing is, they have improved inside/outside detection in 1.1, a lot, but for some reason while it works well for the parachutes now, the wheels it doesn't.

However, what I said originally is true, adding that stowed mechanism to the wheels was an intentional work around to problems with the wheels.  When those wheels are fixed, it is supposed to be removed according to what I've seen.  That could have been bad information but it was coming from some fairly reliable sources.  Obviously I'm not a dev so I can't promise you anything.

Edited July 27, 2016 by Alshain

[regex]

1 hour ago, Kerbart said:

Wasn't a considerable amount of work spent on fuel flow in the last release? And now it's already being reworked? Or was that prep work for what's being done now?

It doesn't really matter because the resource handling is being rewritten.  Certainly some code will still be useful but a lot is apparently being thrown out the window for caching, which has the potential to increase performance.

[John FX]

7 hours ago, taniwha said:

I hope that helps a bit.

To be honest not much but that is more my fault than yours, I`m sure it will be far easier to understand when I can right click and rotate it in 3D. I assume it`s various closest approaches.

As a player I don`t need much of what was being shown, what I really need is a simple way to be able to pick an arbitrary point in the future (say 20 days or periapsis or when I cross the orbit line) and to know the positions of my craft and my target at that arbitrary point. This would greatly improve getting intercepts.

If I just failed to understand and that is indeed what I was looking at then that`s *awesome*, otherwise all I need to know as a player is "What is my position and target position at time X" (ideally with a time slider) alongside "Where will I be when my target is at position X/ where will my target be when I am at position X" (ideally with some ability to pick a future point on my trajectory and that of my target) and the same after my planned nodes.

[NathanKell]

14 hours ago, Red Iron Crown said:

Is it root part agnostic? Will radial flow be enabled by default with fuel lines only for crossing stage boundaries? Am I asking too many questions?

Equal percent everywhere sounds great, rockets are about to get a lot more stable even if we don't fiddle with individual tank priority.

1. Yes.

2. Yes, although I think you mean crossing crossfeed boundaries. Stage boundaries don't matter for crossfeed (unless the boundary is a decoupler without crossfeed), they matter for setting priority.

3. No.

4. Yep!

 

2 hours ago, Kerbart said:

Wasn't a considerable amount of work spent on fuel flow in the last release? And now it's already being reworked? Or was that prep work for what's being done now?

As the dev notes literally say, yep, that work is used in this overhaul.

[Mat2ch]

Hey,

that's all great news

But, when talking about resources, will the asymetric flameout be fixed then, too?

[Archgeek]

7 hours ago, swjr-swis said:

It remains a problem that batteries, monoprop, and xenon tanks on deployable payloads keep getting drained without letting us have any control over it. Unless we want to manually lock/unlock each individual tank, which is a pain in the behind and prone to serious error

For monoprop and xenon, that's not actually quite true.  It uses a mode [STAGE_PRIORITY] that engages in decoupler-counting shenanigans, with weird results if you try to get fancy:

 

[Wahgineer]

What about porkjets rocket part overhaul?

[Superfluous J]

Hey you know what we've not heard about? Porkjet and the new rocket parts.

Oh wait.

Spoiler

18 hours ago, Laguna said:

Some weeks ago, during one of the Squadcasts before 1.1.3 came out, Mu and NathanKell said that Porkjet was almost done with the rocket part revamp, and that "they look better than his plane parts" (I watched it live and that is a direct quote).

 

 

[HvP]

11 hours ago, John FX said:

...

and what exactly are the eight points representing?

Well, here's what I think I'm seeing. Could be off base here but...

Reading from the inner orbit with the empty squares, starting at the 12 o'clock position, the square represents a point of furthest separation from the position along the connecting line to the object represented by the crossed-diamond icon on the outer orbit at nearly 6 o'clock.

Moving clockwise to the 3 o'clock position on the inner orbit the square is furthest from the diamond at the 9 o'clock position (possibly a full orbit later?) At 6 o'clock on the inner orbit the square is now furthest from the diamond at 11 o'clock on the outer orbit (another orbit later?)

Next, there are three close approaches including intersects in which the square and diamond appear to overlap in succession at 7 o'clock. Another furthest distance is represented by the line stretching from about 8 o'clock across to the 2 o'clock position on the outer orbit. Finally, at about 11 o'clock on the inner orbital line (another orbit later?), the square has a closest approach with the diamond shown by the line connecting it to the diamond at 11 o'clock on the outer orbit.

What's missing in the diagram is a time component so I'm not sure how many orbital cycles are represented... if I'm interpreting this correctly. I do not know what the line angle intersecting a point on the orbit in the second diagram represents.

Edited July 27, 2016 by HvP

[legoclone09]

49 minutes ago, awsumindyman said:

What about porkjets rocket part overhaul?

A few weeks ago on a SQUADcast it was said to be almost done.

HYPE!

[AlphaMensae]

33 minutes ago, 5thHorseman said:

Hey you know what we've not heard about? Porkjet and the new rocket parts.

Oh wait.

  Reveal hidden contents

 

 

I forgot to add this, on last week's Squadcast, I asked if there was any furthur update they could share on Porkjet's revamp, and Mu actually replied, giving the usual "Our policy is we don't talk about future features".

So, there's that.

 

[StrandedonEarth]

Chugga-chugga-chugga....

It's getting there, keep up the hard work Squadders!

 

Edited July 27, 2016 by StrandedonEarth

[taniwha]

8 hours ago, monstah said:

It seems to me that the points are being calculated based on the relative positions and orientations of the orbits alone, without regard to where, on the orbit, the target would actualy be. Is that the case?

Correct, this is purely the geometry of the two orbits. Time and thus vessel/body positions is not considered.

 

8 hours ago, monstah said:

If so, how do you go from there to getting the actual closest approach between bodies, and not that of the orbits?

I have no intention of getting the actual closest approach. KSP's "closest approach" markers for celestial bodies are actually buggy: they show the closest approach when you have no chance of intercepting the body that orbit, and then show only one intercept when you do have a chance, but don't change name to "intercept" in that circumstance.

 

3 hours ago, John FX said:

As a player I don`t need much of what was being shown, what I really need is a simple way to be able to pick an arbitrary point in the future (say 20 days or periapsis or when I cross the orbit line) and to know the positions of my craft and my target at that arbitrary point. This would greatly improve getting intercepts.

The information my pictures show is just that: where your vessel will be when it is as close to (or as far from (less useful for vessel targets)) the target's orbit as it will get. From that, the time and thus the target's position can be determined.

30 minutes ago, HvP said:

Well, here's what I think I'm seeing. Could be off base here but...

Your description is pretty accurate, though I'm not certain everything is a maximum (I haven't measured). However, if you look at that little cluster at 7 o'clock, you will find that the diamond in the middle of the cluster is offset a little from the box (the two on either side are centered): it is where the two orbits get as far apart as they will between the two diamonds that are centered.

Time, and thus which orbit, is not a factor. It's all points where the orbits themselves (not the objects on those orbits) are at their closest or furthest. From those points, the time when an object on that orbit is at that point can be determined, and from that the position of the object on the other orbit can be determined. In KSP, you may have noticed that, depending on the circumstances) the intercept markers move very little but the target position markers move a lot as you burn: this is because the intercept marker is dictated by geometry but the target position marker is dictated by time (ie, when your vessel gets to that intercept marker).

[RoverDude]

Yes, the antenna feature is a difficulty toggle for new games and on a per save basis.  Tho its so awesome I have no idea why you would turn it off

[KerbMav]

4 hours ago, NathanKell said:

1. Yes.

2. Yes, although I think you mean crossing crossfeed boundaries. Stage boundaries don't matter for crossfeed (unless the boundary is a decoupler without crossfeed), they matter for setting priority.

3. No.

4. Yep!

So, until a part of a vessel hits a decoupler, the fuel will be drained from that part/stage equally from each tank?

e.g. Three tanks stacked will not drain from the top one to the bottom one but basically be treated like one whole tank?

[smjjames]

10 hours ago, Capt Snuggler said:

Please can we see what @Porkjet is up to?

I need pretty pictures for my eyes please.

Theres a thread in the modding section where someone is experimenting with the new metallic shader or something in Unity, you'll get a bit of an idea there.

[NathanKell]

@KerbMav Until a section of parts hits a part that doesn't crossfeed. Structural plates don't crossfeed, and they aren't decouplers. But yes, within a set they will drain equally, although if tanks at multiple priorities are in a set, those with highest priority form their own first-draining set and so forth.

 

Consider the Kerbal X. Without interference, it will act as it does now, except that within each booster stack (and within the core, once you start draining from it), tanks will drain equally. If you increase the priority of, say, the lower tanks in all stacks, they will drain before the upper tanks. Finally, if you increase priority of the core tanks above the boosters' priority the Mainsail will drain from them first.

 

That solves an issue that has dogged spaceplanes for some time: the payload is set to decouple and thus the payload's tanks would drain first. You can use the priority modifiers to make the payload's tanks drain after all other tanks.

[smjjames]

10 hours ago, Majorjim said:

Can anyone confirm if we will, yet again, have to redesign craft after the rocket parts update? 

Well... I'm sure it won't be as major as the 1.1 update....

But, I'm sure SQUAD will try to take that into consideration, but theres always going to be some configurations that will have to be redesigned, some won't.