Devnote Tuesday: Fuel Flow

[Alshain]

19 minutes ago, AlamoVampire said:

i am disconcerted with the lack of information on the cannot deploy while stowed issue. specifically the portion of the issue where 0 (zero) indication is provided by the game that once a cargo bay even so much as twitches anything that can deploy and is affixed outside NO LONGER WORKS. this is an area of extreme concern to me as half my fleet remains grounded until this issue is cleared. Having landing gear rendered inoperable with no indication after cargo deployment means I risk a STS-107 level disaster during landing because my gear refuse to work. I think I saw some sort of mention of this last week, but lack of information THIS week is less than encouraging. Anyone, regular member, moderator or ya know, dev with solid word on this please enlighten me?

That particular restriction was added due to complications of wheels clipping through parts and especially cargo bays.  If the wheels get fixed as expected, then presumably that restriction will be removed.  It is not an intended long-term feature, nor is it a bug as it was intentionally added.

[Apollo13]

Wheels are still on the development agenda: Brian (Arsonide) polished off the tail end of the wheel upgrade. A good part of his time was spent verifying that many of the ‘kraken drives’ submitted to us by community members using the old wheels no longer function anymore. We regret to inform you that they are indeed fixed.

Does this wheel fix also include a fix to the exploding landing gear?

Edited July 27, 2016 by Apollo13

[AlamoVampire]

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 THIS is as intended. 

or this:

[Majorjim!]

What happened to the rocket parts update?

[AlamoVampire]

@Majorjim good question

[Superfluous J]

18 minutes ago, Majorjim said:

What happened to the rocket parts update?

 

4 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).  Since then, as per their policy, no one from Squad has said another word about it, nor will they, so we're just going to have to wait 'til 1.2 comes out, unless we get a teaser pic closer to release.

Interestingly, the same thing is going on with the new telemetry system.  For several weeks the devnotes had updates about it, and Roverdude even appeared on one of the Squadcasts to talk more about it.  Now, Roverdude is working on the code optimizations, and not a word is being said anymore on the telemetry system.

I think this all means tha both things are completed or near-complete, so Squad goes tight-lipped about it.

I bolded the important parts.

[StarStreak2109]

Great devnotes. Am looking very much forward to this.

[EBOSHI]

I look forward to result of the clean up of the cord.

Does the enlightenment activity of the game development seem to lead to the growth of the team?

 

I pray for the success of all the members of the team from the other side of the earth.

[Streetwind]

4 hours ago, Laguna said:

Interestingly, the same thing is going on with the new telemetry system.  For several weeks the devnotes had updates about it, and Roverdude even appeared on one of the Squadcasts to talk more about it.  Now, Roverdude is working on the code optimizations, and not a word is being said anymore on the telemetry system.

I think this all means tha both things are completed or near-complete, so Squad goes tight-lipped about it.

I regret to inform you that these devnotes do indeed mention ongoing work on the antenna system...

"With that out of the way Brian moved on to patching a few issues with Vectrosity (a tool used to for example render the orbit lines), and helping Bob (RoverDude) with the implementation of the Antenna network systems." - Squad

 

I'm also not sure that silence on a topic necessarily means that it's done and ready to deploy. The rocketry part revamp isn't just an art asset drop-in replacement, there are gameplay changes attached to it as well, which has snowballing effects throughout the game. For instance, last I heard it's planned to normalize tank dry masses for monopropellant and xenon to the same 1/9th as regular tanks currently use, as opposed to being all over the place. On the surface it's a simple tweak, changing a few plain text numbers in a few config files. But, that means the amount of fuel contained in these tanks will change. That in turn means all of the stock example craft need at least a cursory test and QA pass to check if they're still working as intended. It also breaks a tutorial where you are asked to set a RCS tank to exactly 100 units, which is no longer possible due to the way you can only tweak tank amounts in 5% steps, and these steps now no longer falling directly on 100. So that tutorial needs to be rewritten. And then that tutorial needs to go through testing and QA again. Also, the Dawn engine will require a balance pass, because the xenon tank dry mass is especialy atrocious right now, and normalizing it will be a huge buff. That balance pass also needs to go through testing and QA. All that (and maybe more) for the most minute of tweaks.

This part revamp is not a simple side feature to be chucked into any update. In fact, it's entirely possible that it will be its own update entirely, and not come in 1.2, which appears to be dealing with higher priority stuff instead: a delayed feature that was meant for 1.1 but didn't make it, a set of critical bugfixes new systems introduced/revamped in 1.1, a Unity version bump the devs really want but wasn't considered stable yet when 1.1 released, a code cleanup probably quite necessary after the yearlong mega-sprint to port to Unity 5, a performance optimization pass that was likely shifted up in priority by the console releases, and so on and so forth.

On the other hand, if my hunch is wrong and we do get the part revamp in 1.2 after all, I certainly won't be complaining!

[evileye.x]

10 hours ago, SQUAD said:

Especially bugs on consoles are providing a challenge, as players can’t provide us with the same level of debug information as PC players can.

This sound concerning. As a member of supreme PC master race, me afraid that supporting consoles may draw too much efforts from team instead of making THE GAME itself.

Because everybody knows that console version is like... a demo for those sofa lovers. It's like a first dose, and only PC with mods (hundreds of mods) can give you moar... 

And I really appreciate SQUAD team putting a lot of effort to make KSP a stable, strong platform, because content-wise community already did so much amazing things, I think it is possible to play for years and always there's a way to put something new in your game.

But if sofa guys will not get hooked up then .... at least SQUAD got their money, which is good and really well-deserved. And if they will, then... again SQUAD will get some more money for PC version as well. Again, good!

 

[John FX]

Recently we talked about Bill’s (Taniwha) efforts of getting KSP to more correctly display intersections in orbits.

OK, sounds good.

He’s been busy prototyping various solutions and this week he got the prototype code to find all possible points of interest

still sounds good

(between two and eight, always in pairs) when the points are not too close to each other.

Wut? This is the line that loses me.

A picture says more than a thousand words, and Bill has provided two: the first shows the eight points

and what exactly are the eight points representing?

for orbits resembling hitting Gilly from moderately high above Eve, the second shows the available six points on an intercept with a highly elliptical orbit

Again, what am I looking at?

Edited July 27, 2016 by John FX

[Curveball Anders]

I really like that Squad seems to stick to putting most of the effort into correcting old coding sins, updating old algorithms and polishing existing features instead of chasing new, bright and blingy stuff.

I jealously wish that all developers was allowed to do that on a regular basis by their bean counters and higher ups.

[taniwha]

19 minutes ago, John FX said:

(between two and eight, always in pairs) when the points are not too close to each other.

Wut? This is the line that loses me.

Due to the periodic nature of orbits, a closest approach always has a corresponding furthest separation. Of course, open trajectories (hyperbolas) will break this rule as at least one furthest separation will be missing due to it being out past infinity.

21 minutes ago, John FX said:

and what exactly are the eight points representing?

[first image] Two fairly similar orbits: 1.0 (semi latus rectum), 0.6 (eccentricity) for one, 0.45, 0.8 for the second. The orbits are coplanar with a bit of argument of periapsis for the second to get the cluster of intercepts.

Four closest approaches and four farthest separations (note, that's local to the approach/separation, not global to the orbits). That little cluster of three points in the lower left is actually two closest approaches (actually, intersections: you don't get any closer, ever) with a furthest separation in between the two. You then get one more furthest separation in the upper left. And that's just for the connections that do not cross an orbit. You then have another 4 connections crisscrossing the orbits: two closest approaches and two furthest separations.

The octahedrons mark the points on one orbit while the cubes mark the corresponding points on the second (target) orbit. The lines help keep track of which point is which. Yes, in total, there are 16 points, but as the points on the two orbits are logically connected, I count the two physical points as one logical point (thus 8).

26 minutes ago, John FX said:

Again, what am I looking at?

[second image] 1.0, 0.4 for the first orbit, 1.0, 0.98 for the second (very large) orbit. Think low Kerbin orbit vs  Minmus transfer orbit. Perspective makes it look reasonable. The first is rotated 254 degrees, the second is inclined 60 degrees to the first with an argument of periapsis of 160. It's a test case that caused my algorithm some problems until I gave up trying to pre-filter the orbit-crossing intercepts: it could not see that intercept with the nearly vertical line (upper middle).

I hope that helps a bit.

[swjr-swis]

All the work being done sounds good. I have a question concerning this part:

 

10 hours ago, SQUAD said:

All-vessel flow is the old mode you know well from electric charge and monopropellant, and crossfeed replaces both jet and rocket engine flow modes.

The changes and new features of rocket fuel flow are going to be extremely welcome, but is there any way to also implement optional staging/crossfeed boundaries for electricity, monoprop, and xenon flow? Eg. by a per-part toggle that changes the fuel flow mode between all-vessel as now, and crossfeed as in jet/rocket fuel. I really want those (all!) resources to obey crossfeed/stage boundaries when I need them to.

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 (forgetting to unlock a battery on a deployable sat before staging/decoupling is lethal).

Alternatively, if the above is somehow impossible: can we at the very least get the lock/unlock/toggle lock part actions of batteries and tanks available for action groups? Anything other than having to remember to go through the entire set of individual resources manually every time.

[Capt Snuggler]

Please can we see what @Porkjet is up to?

I need pretty pictures for my eyes please.

[Majorjim!]

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

[evileye.x]

22 minutes ago, Majorjim said:

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

You say it so like it is something bad...

[adsii1970]

32 minutes 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 (forgetting to unlock a battery on a deployable sat before staging/decoupling is lethal).

Alternatively, if the above is somehow impossible: can we at the very least get the lock/unlock/toggle lock part actions of batteries and tanks available for action groups? Anything other than having to remember to go through the entire set of individual resources manually every time.

[edited by adsii1970 for content, highlighted text]

I had to read your proposal several times before it sank in (I have yet to finish my first cup of coffee for the morning, sorry). As I began to understand what you were saying (the portion I highlighted in red), it simply makes sense to have this option for both batteries, tanks, and even ore tanks.

This is what has been needed for some time - a way to control the outflow/inflow of tanks besides the manual right click method. It would provide tremendous flexibility (and have some disastrous consequences for those who do not pay attention) in craft design. It would also allow for a tank or battery to be used as a "reserve" in larger craft. There are probably a lot of other benefits, but right now, and only having 3/4ths of a cup of coffee, I cannot think of them...

[Majorjim!]

32 minutes ago, evileye.x said:

You say it so like it is something bad...

Well... Yeah. The game is released, past version 1.0 Ect Ect Ect..

 

[evileye.x]

1 minute ago, Majorjim said:

Well... Yeah. The game is released, past version 1.0 Ect Ect Ect..

 

Oh, I just clicked link in your sig... Now I see. Amazing work btw. My way to play is way different - I play in career mode, each time I start with different mods, so scrap all my old crafts anyway.

[monstah]

3 hours ago, taniwha said:

Due to the periodic nature of orbits, a closest approach always has a corresponding furthest separation. Of course, open trajectories (hyperbolas) will break this rule as at least one furthest separation will be missing due to it being out past infinity.

[first image] Two fairly similar orbits: 1.0 (semi latus rectum), 0.6 (eccentricity) for one, 0.45, 0.8 for the second. The orbits are coplanar with a bit of argument of periapsis for the second to get the cluster of intercepts.

Four closest approaches and four farthest separations (note, that's local to the approach/separation, not global to the orbits). That little cluster of three points in the lower left is actually two closest approaches (actually, intersections: you don't get any closer, ever) with a furthest separation in between the two. You then get one more furthest separation in the upper left. And that's just for the connections that do not cross an orbit. You then have another 4 connections crisscrossing the orbits: two closest approaches and two furthest separations.

The octahedrons mark the points on one orbit while the cubes mark the corresponding points on the second (target) orbit. The lines help keep track of which point is which. Yes, in total, there are 16 points, but as the points on the two orbits are logically connected, I count the two physical points as one logical point (thus 8).

[second image] 1.0, 0.4 for the first orbit, 1.0, 0.98 for the second (very large) orbit. Think low Kerbin orbit vs  Minmus transfer orbit. Perspective makes it look reasonable. The first is rotated 254 degrees, the second is inclined 60 degrees to the first with an argument of periapsis of 160. It's a test case that caused my algorithm some problems until I gave up trying to pre-filter the orbit-crossing intercepts: it could not see that intercept with the nearly vertical line (upper middle).

I hope that helps a bit.

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? If so, how do you go from there to getting the actual closest approach between bodies, and not that of the orbits?

[Majorjim!]

6 minutes ago, evileye.x said:

Oh, I just clicked link in your sig... Now I see. Amazing work btw. My way to play is way different - I play in career mode, each time I start with different mods, so scrap all my old crafts anyway.

Cheers mate, I appreciate that as yeah I spent a long time making my craft and it's frustrating to have to make them over and over again. I have been working on one groups of craft for a year..

[Redneck]

any chance we can get a good reflection shader that doesnt kill frame rates?

[regex]

2 hours ago, adsii1970 said:

This is what has been needed for some time - a way to control the outflow/inflow of tanks besides the manual right click method.

I wrote a mod for this once to help with drop-tanks after the recent fuel flow change.  It was stupid simple to implement.  LGG picked it up when I burnt out, Tank Lock Redux, IIRC.

[OrbitalBuzzsaw]

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