Devnote Tuesday: "Point sharp end towards space"

[Xavven]

Are you sure? Did Maxmap post a response on redit? (I couldn't help it. I'm sorry. Well, just a little, but it counts...)

LoL! My parents used to tell me, "don't tempt fate" when I got close to getting myself punished for bad behavior. Hint

Regarding the calculations for the engineering concerns (like "hey, this fuel tank isn't connected to any engines!") and whatnot, I like the ideas presented in this thread about only calculating before launch, but I wanted to add another idea: what about only calculating if no parts have been added/tweaked/translated/rotated for 5 seconds?

[Wallygator]

Snip from Ted... "Additionally, I’ve been spending the past day setting up an OSX testbed here in order to further address any OSX issues that our players are encountering. Having rarely used OSX/Apple products before, I’ve been struggling with the Windows/Linux mindset but thankfully seem to be shaking it."

So, how long has the OSX build been available without a formal test platform available? My fears and assumptions seem to be confirmed. Regardless, thank you for being brave, admitting the issue and taking the correct first steps to a full recovery. You can do it! ;-)

That was music to my ears.

[Darnok]

Since temperature is going to be a thing... parts will melt during re-entry?

[riT-k0MA]

Jim (Romfarer): I just wanted to clear up some misconceptions about the Engineer’s Report design concern feature. Last week I said I was concerned about performance on some of the tests. The design concern feature is not a list of parts a vessel has and has not. It is a set of tests which analyze your vessel for possible issues you may run into. For example a big part of these tests are dealing with resource flow and will prompt when you have resource containers which are not being drained, consumers (such as engines) not getting the fuel they need, etc. And for every of these tests the parts in question are highlighted. This means the tests have to run every time you attach and detach a part and in the case of stack resource flow the system has to check for every resource container, and then trace back from the consumers which of these containers are not being drained.

Why not just implement an "Engineer's Report"/"Engineer's Inspection" button so that the tests are only performed when the user wants them performed?

The way it's currently described to work seems a lot like validating a textfield as the user presses each key.

[DocMoriarty]

The docking UI is really useless. What would rock though would be if 'Select as Target' on a docking port would actually select the docking port as target. That is the target marker on the navball should then refer to this docking port and distance should be shown as distance to this docking port, or actually between the docking port and the docking port or other part that is selected by 'Control from Here'. Then the navball would make docking really much easier. So drop the docking UI and fix these bugs in interpreting the settings 'Select as Target' & 'Control from Here' and a lot of people will be happy. This should also help with the new docking tutorial since then you only need to explain that in the final docking phase only the 'to target' and the 'forward' icon on the navball need to be on top of each other and bingo you have a correct docking vector.

Edited February 11, 2015 by DocMoriarty

[sarbian]

Okay, okay. Everybody gets it. Folks would prefer that more development news and teases were posted here first. Seriously. We get it. Now please stop flogging that dead horse and discuss the news itself rather than its source.

The first post talk about Reddit so it does seems to be on subject.

Reddit and Something Awful gets more attention than the official forum and the only reaction we get are from mods.

Good news on the ISP. The RCS module was updated too I guess ?

[OrtwinS]

I love waking up on Wednesdays and reading dev notes in bed .

I second the observations made about this forum being supposed to be the primary source of dev-revelations.

Love the ISP fix.

[White Owl]

Right now I'm thinking about ways to illustrate the new aerodynamics in a preview video. It'll be fun!

[MircoMars]

OKay about the engineering feature: can we deactivate the check and use only when needed? I don't want a constant check for fuel flow slowing down my VAB to a slide show. even if it's only after every time I placed, removed or tweaked a part... I really suspect worse case here, but I don't want to wait half a minute everytime I compare two stage-subassemblies.

I'd rather have a "Komputer Simulation": my rocket spawns in a room looking like a tng-holodeck and I have control over gravity, atmo etc while seeing nice readouts to help me improve my design. And all a bit quicker than loading my whole savegame.

[Corw]

OKay about the engineering feature: can we deactivate the check and use only when needed? I don't want a constant check for fuel flow slowing down my VAB to a slide show. even if it's only after every time I placed, removed or tweaked a part... I really suspect worse case here, but I don't want to wait half a minute everytime I compare two stage-subassemblies.

I'd rather have a "Komputer Simulation": my rocket spawns in a room looking like a tng-holodeck and I have control over gravity, atmo etc while seeing nice readouts to help me improve my design. And all a bit quicker than loading my whole savegame.

You are assuming way too much. There is not a single hint that new feature is CPU intensive or implemented in a way that is crippling your ability to play (example: low priority background threads anyone?)

Give Squad some credit, they are not morons that have seen source code yesterday for the first time. Quit bitching about hypothetical bugs.

[pizzaoverhead]

The old infiniglide issue is now a thing of the past.

I’ve also gone over the Engines code, and tweaked them so that now throttle regulates the fuel flow rate, instead of the final thrust.

I’ve done a complete revision of the old Chase camera mode.

I have reworked the atmospheric model into something a little more based on reality

I’ve been spending the past day setting up an OSX testbed here in order to further address any OSX issues that our players are encountering.

Excellent news! Good to see these much-requested features making it into the game.

I thought of adding a little key binding reminder during flight, sort of what you get in fighting games, just a screen that lets you see the key bindings you currently have assigned in a case sensitive manner

Another useful way of displaying this is to show a keyboard image, with keys that have functions assigned highlighted. This allows users to see what keys they have free to bind to new controls, or what keys are active in any given mode:

With regards to additions to docking mode, the Navball docking alignment indicator mod gives the most stock-alike way of doing this:

Edited February 11, 2015 by pizzaoverhead

[KerbMav]

<b>Felipe (HarvesteR):</b>I’ve also gone over the Engines code, and tweaked them so that now throttle regulates the fuel flow rate, instead of the final thrust. That means fuel flow stays constant, and as Isp changes as you leave the atmosphere, thrust output increases (as opposed to thrust staying constant and fuel consumption changing).

Good!

So, the maximum thrust will be achieved in vacuum and be the same as advertised in the descriptions of all engines?

The sea-level ISP on Laythe, Duna and Eve would be different from Kerbin anyway, so the only gameplay constant is thrust in vacuum.

Any special treatment for jet engines?

<b>Felipe (HarvesteR):</b>Since version 0.18 and the addition of docking, we’ve had this docking control mode which very few players ever got around to using. I didn’t remove that, but I did come up with a more elegant way to implement the control binding switching, so we could do away with all those duplicate input mappings on the settings screen. Now, there is only one input mapping for pitch, yaw, roll and linear translations, and the docking mode mapping is done using the secondary key bindings and a new state toggling system which is simpler and more flexible than the old way. So much more flexible, in fact, that you can now use docking mode as an alternate control scheme in any way you want.

<b>DocMoriarty:</b>The docking UI is really useless. What would rock though would be if 'Select as Target' on a docking port would actually select the docking port as target. That is the target marker on the navball should then refer to this docking port and distance should be shown as distance to this docking port, or actually between the docking port and the docking port or other part that is selected by 'Control from Here'.

If the docking UI would do something else than just change the way my keys work - i.e. different from what I am used to 96% of the time I play KSP - then it would have a reason for its existence.

Dedicated rover controls can be configured separately in the settings menu, so no need for mis-using the docking UI for this.

Showing distances between the two selected docking ports and actually using the little monitor in the UI to display alignment and relative movement (a.k.a. Docking Port Alignment Indicator) is what I would (have) expected from it, but instead all I got was a weird remapping of my controls, although WASDQE and IJKLHN worked just fine in the flight UI. (The default settings suggesting to use the same keys for rotation and translation is weird too - it often makes sense to do both simultanously.)

<b>Marco (Samssonart):</b>so I thought of adding a little key binding reminder during flight, sort of what you get in fighting games, just a screen that lets you see the key bindings you currently have assigned in a case sensitive manner,

Optional please!

<b>Jim (Romfarer):</b>This means the tests have to run every time you attach and detach a part

Every time means the player will be confronted with lots of red and warnings while only starting to build his craft.

An "Ask Wernher" button?

Edited February 11, 2015 by KerbMav

[Starwaster]

The docking UI is really useless. What would rock though would be if 'Select as Target' on a docking port would actually select the docking port as target. That is the target marker on the navball should then refer to this docking port and distance should be shown as distance to this docking port, or actually between the docking port and the docking port or other part that is selected by 'Control from Here'. Then the navball would make docking really much easier. So drop the docking UI and fix these bugs in interpreting the settings 'Select as Target' & 'Control from Here' and a lot of people will be happy. This should also help with the new docking tutorial since then you only need to explain that in the final docking phase only the 'to target' and the 'forward' icon on the navball need to be on top of each other and bingo you have a correct docking vector.

It already does what you say it should.

Try taking a decently long ship (10 meters or so) with a docking port that you have targeted with a second ship. Set the first one spinning on an axis perpendicular to the docking port's orientation axis. You'll see it moving back and forth across the navball.

As for the range indicator, it only has one significant figure of accuracy. So the problem isn't that it doesn't update. It just doesn't have enough accuracy.

[micha]

You are assuming way too much. There is not a single hint that new feature is CPU intensive

Considering there have now been 2 devnotes which alluded to the fact that the Engineering Report is in need of optimising, I would say that yes, there have been hints that performance is possibly an issue. Quote:

Last week I said I was concerned about performance on some of the tests.

Regardless, I definitely do NOT want it to keep pestering me about problems about my craft when I'm only half-way through building it. While I don't know what the final form of the Report will take, people commenting here are just stating what they don't want to see. And quite a lot of people seem to prefer it to be something that's done on request, rather than automatically. That is all.

From what I've heard about it it seems to consist of two separate parts anyway:

1) Stats about the craft you're building (mass, dV, etc)

2) Possible issues with the craft (missing fuel tanks, no solar panels, blocked crew hatches, etc)

1 should be recalculated constantly, as Kerbal Engineering Report does (and PLEASE let us be able to hide the readout; not everybody plays on a high-res screen).

2 should be on-demand (and PLEASE let us turn it off if it's not on-demand, such as if it pops up when hitting "launch". Some designs are "broken" on purpose, such as launching station/ship modules).

[MartGonzo]

Jim (Romfarer): I just wanted to clear up some misconceptions about the Engineer’s Report design concern feature. Last week I said I was concerned about performance on some of the tests. The design concern feature is not a list of parts a vessel has and has not. It is a set of tests which analyze your vessel for possible issues you may run into. For example a big part of these tests are dealing with resource flow and will prompt when you have resource containers which are not being drained, consumers (such as engines) not getting the fuel they need, etc. And for every of these tests the parts in question are highlighted. This means the tests have to run every time you attach and detach a part and in the case of stack resource flow the system has to check for every resource container, and then trace back from the consumers which of these containers are not being drained.

I'm no programmer but why run tests with every part change?

wouldn't it make more sense to just do it when the player presses the launch button?

[sarbian]

Considering there have now been 2 devnotes which alluded to the fact that the Engineering Report is in need of optimising, I would say that yes, there have been hints that performance is possibly an issue.

In flight the engines modules already do related complex call 25 time per second to draw fuel. While I have no doubt the check are more complex I doubt they'll have such a large impact.

As other suggest a slight delay between adding/removing a part and the update may lower the impact when you keep moving a part or adding stuff like struts.

[Corw]

Considering there have now been 2 devnotes which alluded to the fact that the Engineering Report is in need of optimising, I would say that yes, there have been hints that performance is possibly an issue.

It may be an issue but you are assuming it will be released before optimized.

I'm no programmer but why run tests with every part change?

wouldn't it make more sense to just do it when the player presses the launch button?

If it is not too taxing on the CPU, why not? Check KER, it is constantly updating info as you build. Does it choke you GUI? No.

[Red Iron Crown]

If it is not too taxing on the CPU, why not? Check KER, it is constantly updating info as you build. Does it choke you GUI? No.

Interestingly, KER includes a setting to reduce the update frequency on more modest processors. Adjusting this made a noticeable difference on my old potato-PC, the simulation code can be non-trivial for complex craft on weaker machines.

[Corw]

Interestingly, KER includes a setting to reduce the update frequency on more modest processors. Adjusting this made a noticeable difference on my old potato-PC, the simulation code can be non-trivial for complex craft on weaker machines.

I understand that. I have first hand experience with things like this. I believe the KER is periodically making the computation (once in a second?) no matter if you have changed anything or not (but I may be wrong about this) while new feature will be run only on part change. And as you have said, KER was felt on your "potato PC", I never noticed it on 5 year old machine.

What I do not understand is why so many people are assuming Squad to make an utter failure from this feature?

[MartGonzo]

I understand that. I have first hand experience with things like this. I believe the KER is periodically making the computation (once in a second?) no matter if you have changed anything or not (but I may be wrong about this) while new feature will be run only on part change. And as you have said, KER was felt on your "potato PC", I never noticed it on 5 year old machine.

What I do not understand is why so many people are assuming Squad to make an utter failure from this feature?

I don't think anyones expecting an utter failure, it's just that when a significant number of the posts on this forum are about juggling the extremely limited CPU and memory resources, it seems like an odd way of going about things to add in unnecessary background checks when it would work perfectly well by implementing an engineers report button or something similar.

[monstah]

And for every of these tests the parts in question are highlighted. This means the tests have to run every time you attach and detach a part and in the case of stack resource flow the system has to check for every resource container, and then trace back from the consumers which of these containers are not being drained.

Please, no! Not only this will drain CPU resources, it will be a pain in the ass while you are just designing your ship.

I use SQL editors at work, first thing I do is turn off "automatically check query validity", otherwise it will constantly remind me of global syntax errors... on a query I'm still writing.

Make it so it checks when we tell it to check by clicking a button, or automatically prior to ship launch (or both), so it's not annoying during construction.

Otherwise, very nice. Loved to hear about the key bindings. Translation mode is indeed useless as it is.

- - - Updated - - -

Apearently this has been discussed already... well, I agree with Gonzo above.

[TMS]

All sounds good. Improved chase cam, better ISP calcs, better lift values.

Also sounding the note of caution on the improved chase cam. The mod by Baha never really felt intuitive when in orbit and (until a usable docking GUI is developed) retaining the fixed-point chase cam would probably be desirable for newer players.

Great set of notes. Thanks.

[Corw]

I don't think anyones expecting an utter failure, it's just that when a significant number of the posts on this forum are about juggling the extremely limited CPU and memory resources, it seems like an odd way of going about things to add in unnecessary background checks when it would work perfectly well by implementing an engineers report button or something similar.

But that is the thing. The CPU heavy stuff is flying the rocket. That stuff is not done while you are building it. Open the task manager and check out the CPU use in VAB and in flight. But first of all trust the developer to make the right call. He has the information and he is doing the tests. If it is too heavy to be done all the time he will make it on demand. But don't bash him for the mistakes he did not make.

[MartGonzo]

But that is the thing. The CPU heavy stuff is flying the rocket. That stuff is not done while you are building it. Open the task manager and check out the CPU use in VAB and in flight. But first of all trust the developer to make the right call. He has the information and he is doing the tests. If it is too heavy to be done all the time he will make it on demand. But don't bash him for the mistakes he did not make.

true but I don't see any advantage in constantly running background checks in the VAB when a single check on demand would work just as well with less resource usage.

I don't know where you got the idea I was bashing anyone, I thought we were discussing the implementation of concepts.

[razark]

...discuss the news itself rather than its source.

It's a discussion of the content of the devnotes post.

And if being told by Squad to sit down and shut up because the forums don't matter isn't news, then I don't know what is.

Edited February 11, 2015 by razark