Devnote Tuesday: The Mother of all Merges

[HafCoJoe]

OMG! Mr. Turkey we share the same real name. It's great to have you around man. :) You're part turkey?! Huh. Have you ever heard of the show Fulllmetal Alchemist...

[Rithsom]

Great Devnotes as usual! I can see that you guys are very busy with 1.1 development.

Also, I would be okay if 1.1 doesn't get released this year, after all we just got a new update a week ago! Edited November 18, 2015 by Rthsom

[NFUN]

[quote name='pellinor']To be honest, I wouldn't bet too much on features. Rather something on the business side of things, like the console ports, 3d printing service, or a completely different game.[/QUOTE]

With people leaving the team to move on to other things, I don't think it'll be another game.

[federicoaa]

Something I notices in redaction. When you write "That approach always bothered me" you refer to felipe or to whoever wrote the post?

[Guest]

Moral of the story kids: don't work on multiple versions at once. Not really. Really excited!!!!!

[2001kraft]

Nice stuff guys. Nice stuff.

I would absolutely love the dev team if they did [I]not[/I] rush the development under any circumstance. Just keep it feature-complete, Unity 5, bug-less. Make it pure, make it perfect. It's like your second 1.0 release after all.

[kiwi1960]

errrr..... you lost me at "Hello everyone"! I will just take your word for it that something big, major and very complicated took place.

More power to Squad. (sounds like you guys need it!)

Would I be right in thinking that Squad is almost as complicated as NASA is trying to build an Apollo moon lander, with launcher, from scratch?

Dammit man.... talk in a language us rocketeers can understand. :)

Its not rocket science.... is it?

:)

Kia Kaha .... (Maori for STAY STRONG!)

[Keldor]

Wouldn't the depth map be floating point in any remotely modern GPU implementation? In that case, doing a 1/z transformation is superfluous, since floats are pseudo-logarithmic in the first place and can cover a vast range without loosing precision for small numbers. Should be 3.4E-38 to 3.4E+38 for single precision, which is enough to cover both universe scale and subatomic scale in the same coordinate system. Since floating point is essentially scientific notation for computers, you get about 6-7 digits of precision at all scales.

1/z was common historically when depth buffers were integer, for what it's worth, though the reciprocal operation is expensive, or at least was back in the days where 1 TFlops wasn't the norm for mid-range GPUs. Edited November 18, 2015 by Keldor

[KerbMav]

[quote name='r4pt0r']What is the good doctors area of expertice? Is he a coder? or more business end like max was?[/QUOTE]

Just The Doctor ... a Doctor ... on christmas ... QUICK! Everybody get out of London!

[fireblade274]

[quote name='KerbMav']I did not get even half of the first half - but ... ok ... :D

So, the new producer will spoil our christmas by delaying 1.1 yes? :wink:
My totally irrelevant opinion: Get 1.1 done, completely, especially 64bit and stuff, if not christmas (strange time to release anyway, since 1.1.1 and 1.1.2 wont be worked on during the holidays, yes? :wink: ) than early January 2016; but I think releasing without some [I]promised[/I] content ... nyaah ...[/QUOTE]

You took the words right out of my mouth lol

[Virtualgenius]

Give us the whole package even if you have delay a couple of weeks

[Streetwind]

What I want out of 1.1 is the ability to cram more than 3 GB worth of memory in via 64 bit, and the reworked antennas/comms systems. My plans for my next career savegame hinge on that! :P So whatever you do - please don't cut these features for a faster release. I'm willing to take a delay over a longer wait for the next version.

(And for the love of Jool, at least take one day off per week, you workaholics!)

[StarStreak2109]

Dear Squad Team, dear Community,

first of all, let me say that I take it for a sign of "You know when you have been playing too much KSP, when you eagerly wait for devnotes every tuesday...". Anyway, again I was not disappointed. While the whole programming stuff was naturally way over my head it was good to see that development is progressing at nice pace. This is of course the point to thank the whole dev team for all the awesome work they are doing with KSP. Right now I cannot think of a game where I put in such long hours building rockets and space stations, flying to other worlds and learning by the way sciency stuff.

Normally I am also the type to say: "Please finish the product to its full envisioned potential and take your time while doing it, finding as many bugs as possible!" But in this special case, I am not going to follow this path. Right now, the game is in my humble opinion at a cross roads. While the last updates have eliminated certain bugs and added new features - I have yet to try out 1.0.5 - the game for me at least has gotten ever more unstable since 0.25. This of course has also to do with the plethora of mods I like to use, but at the end of the day, that is one of the highlights of the game isn't it?!

In 0.24.2 I was able to use 64 bit, which ran quite stable with the occasional unexplained crash. Since then I have learned how to optimise the game to save ram while keeping my favourite mods by pruning unneeded parts, compressing or converting textures and using D3D11. But it always seems to run right at the edge of running out of memory and most often, after landing my craft back on Kerbin and trying to recover it, I have to reload the game after a crash.

The other week I said I am going to put KSP aside and play a bit Anno2205 while waiting for 1.1. I found I am quite addicted to KSP, despite the bugs and the crashing...

Hence my conclusion is that if it is sensible from a development point of view, I could wait for certain additional features if it was possible to get 1.1 sooner, being able to return to a stable 64bit game with better memory management and wait for the additional features turning up in 1.1.1 etc. This also since I fully expect that a number of mods will take some extra time after 1.1 release to get up to speed again, because this is presumed to be severely mod breaking, after what I read so far.

Anyway, this all is just my personal opinion. Of course whatever you decide is your prerogative and will be welcomed just as well.

Keep up the good work and looking forward to next Tuesday!!!

Warm regards from Germany!
Sebastian

[SpaceNomad]

[quote name='blizzy78']Hate to say it, but have you been rebasing [B]regularly[/B]? 390 conflicts sounds like a hell of a mess that shouldn't have happened in the first place. You can't just rebase at the end of a large chunk of work, you need to rebase regularly, say daily. Yes, you will be getting conflicts, but only a few per rebase, not a huge pile.[/QUOTE]

Exactly, what I was thinking. From what I got, they merged two lines of development going rather indepently for the last 6 months. From my experience this will have resulted in quite a few bugs that haven't been caught. It's inevitable that during a 3-days merge something is dropped under the table and lost. We are all just [s]human[/s] kerbal. Unfortunately, by rebasing and thus effectively changing the past in git it might be really hard or even impossible to detect now. Merging might have been the better option in this case.

Anyway, this is spilled milk now. We can't change the past like in git ;) I'm sincerely hoping that I'm just overly pessimistic and it did not cause that many hidden problems.

[nanobot]

In the worst case they will to have to go over the entire specification and check every feature again to make sure nothing is lost. But yes, the 1.0.5 changes could have been pulled into the 1.1 branch regularly (obviously not the other way around). Either way, now they know better for Unity 6 ;)

[ratchet freak]

[quote name='Hobbes Novakoff']So, dynamic loading eventually? My question is, what are you dynamically loading? The building interiors and such I see the point of, but planets and parts are going to always have to be loaded, as the game has no idea if a craft will appear out of nowhere the contains a part that isn't loaded yet, or if your craft will suddenly warp off to another planet.[/QUOTE]

You don't need to keep the 4k height map, biomes and texture loaded for all planets (only the one you are orbiting), instead you can only keep a low res texture loaded for all bodies and only load the "details" of the planet when you enter the SoI, you don't even need to load the biomes unless there is a biome sensitive science part on the craft. And you can delay loading even that until the science happens.

Same with parts; only keep a low poly model and low res texture loaded for all parts and only load the high res high poly when that part is on a craft that is appraoching. Crafts don't appear out of nowhere, you approach them quite slowly unless you are in very high timewarp, only when you switch to them from the tracking station is it suddenly needed but that's an opportunity for a small loading transition using a pan from that map screen to the craft to buy some time.

[quote name='Keldor']Wouldn't the depth map be floating point in any remotely modern GPU implementation? In that case, doing a 1/z transformation is superfluous, since floats are pseudo-logarithmic in the first place and can cover a vast range without loosing precision for small numbers. Should be 3.4E-38 to 3.4E+38 for single precision, which is enough to cover both universe scale and subatomic scale in the same coordinate system. Since floating point is essentially scientific notation for computers, you get about 6-7 digits of precision at all scales.

1/z was common historically when depth buffers were integer, for what it's worth, though the reciprocal operation is expensive, or at least was back in the days where 1 TFlops wasn't the norm for mid-range GPUs.[/QUOTE]

The depth stored in a depth buffer is often just an int (which gets rescaled to a 0-1 floating point in the shaders) unless you (explicitly) specify a floating point depth texture. BTW that should be the approach but I don't know if unity allows it.

[One-Way Films]

What I think about this weeks devnotes;

[B]A)[/B] Guys, take a tea break every once in a while xD
[B]B)[/B] Take as long as you want with 1.1. Some will complain but everyone (even the inpatient) will thank you when 1.1 is a fleshed-out masterpiece. I'll happily wait another 6 months if it's needed.
[B]C)[/B] I'll be watching you on Squadcast, doctor. *backs away into shadows*
[B]D) [/B]As I said in B, take as long as you want. Don't cut anything unless our lives depend on it xD

Thanks for being dedicated devs, lads. Thank you for listening to your community and asking for feedback on a regular basis.

[KerbMav]

[quote name='SQUAD']and a very old bug was fixed in the process: small orbits on distant planets would be visible if you were zoomed in on any planet which wasn’t particularly hard on the eyes, but did affect performance. Orbits you could never see were wasting CPU time to render as tiny blips. That should be fixed now. If you zoom in to Kerbin, you should only see orbits belonging to the Kerbin system. If you zoom out, planets will fade in, but not their moons, until you zoom into them.[/QUOTE]

Feeling a bit cheeky - so you are sure this only removes the rendering of the orbit, not the in background on rails calculations registering SOI changes and stuff? :P :wink:

[Masetto]

64-bit, Unity 5, and then, next up, dynamic asset-management.

Really looking forward to all of it, and appreciate the hard work. It'll be finished when it's finished, right?

You guys are awesome, and this game is going to be even more incredible than I'd initially thought (which is saying a lot). Edited November 18, 2015 by Masetto

[KasperVld]

[quote name='blizzy78']Hate to say it, but have you been rebasing [B]regularly[/B]? 390 conflicts sounds like a hell of a mess that shouldn't have happened in the first place. You can't just rebase at the end of a large chunk of work, you need to rebase regularly, say daily. Yes, you will be getting conflicts, but only a few per rebase, not a huge pile.[/QUOTE]
The problem with this is that the code was written for two different versions of the Unity engine: KSP 1.0.x runs on Unity 4, whereas KSP 1.1.x will run on Unity 5. That's the reason the development was separated for so long. I can't go into technical details, because I don't know them. From what I understand the developers felt that one big rebase would be more reliable than many smaller rebases along the way.

[Pestilence]

[quote name='RazorWolf19']... Nobody is going to complain about bugfixes optimizations; ...[/QUOTE]

You must read a different forum than I do.
--pest

[softweir]

[quote name='Keldor']Wouldn't the depth map be floating point in any remotely modern GPU implementation? In that case, doing a 1/z transformation is superfluous, since floats are pseudo-logarithmic in the first place and can cover a vast range without loosing precision for small numbers. Should be 3.4E-38 to 3.4E+38 for single precision, which is enough to cover both universe scale and subatomic scale in the same coordinate system. Since floating point is essentially scientific notation for computers, you get about 6-7 digits of precision at all scales.

1/z was common historically when depth buffers were integer, for what it's worth, though the reciprocal operation is expensive, or at least was back in the days where 1 TFlops wasn't the norm for mid-range GPUs.[/QUOTE]

IIUC, GPU floats are fairly small. Scaling planets down to ships requires more precision than these small floats provide and you would end up with flickering because some objects would scale to the same Z-depth. HarvesteR's scaling algorithm avoids that. I believe this is [url=https://www.mvps.org/directx/articles/using_w-buffers.htm][u]W-buffering[/u][/url].

[Generalstarwars333]

What exactly will 1.1 bring to the game, partwise? I can understand the coding stuff mmight be exciting to some, but since mmy experience with that stuff is basically confined to scratch and code combat, it's essentially all greek to me. Will there be more new parts? More SCIENCE! parts? MOAR BOOSTERS?

[klgraham1013]

[quote name='SQUAD']Fixing these issues meant Felipe and other developers worked through the weekend and yesterday’s Mexican national holiday.[/QUOTE]

Please, don't do this. If you truly make your own deadlines, than you deserve time off. You deserve time off, even if it pushes a deadline. Don't be like every other game company and assume "crunch" is a necessary part of life. People are more important than products. Edited November 18, 2015 by klgraham1013

[Sophistry]

[quote name='klgraham1013']Please, don't do this. If you truly make your own deadlines, than you deserve time off. You deserve time off, even if it pushes a deadline. Don't be like every other game company and assume "crunch" is a necessary part of life. People are more important than products.[/QUOTE]

Well, they could REALLY have been having a party in the office and doing a bit of work in order to avoid Great Aunt Ethel who smells of wee and still pinches their cheeks, or something else like that...