Devnote Tuesday: Smooth Transitions

[cantab]

Indeed. If the technique can be implemented for SOI transitions a similar thing should work for planetary surfaces. Set a "buffer zone" around each planet a kilometre or two above the highest point or the amosphere. If the craft would be inside that buffer zone on a frame, instead calculate when it would enter it, put it there and drop to 1x speed. No other timewarp limits required and no more warping through atmospheres.

On an unrelated note,

Also, working on the license system… almost there.

This has come a few times with basically no detailed information and it has me seriously worried. It sounds suspiciously like an activation or anti-piracy system, with all the limitations, intrusiveness, and generally spoiling things for customers without stopping pirates that that brings with it. I don't want a KSP that disables itself if I haven't connected to the internet in a week or interferes with me having multiple copies of the game with different mods and I really fear Squad could be sucked into exactly that.

[basic.syntax]

there is also a new system in place which sets a time warp limit when approaching an SOI transition.

The word "system" may refer to their new Timewarp To feature, mentioned in previous Devnotes. Its not completely clear from this wording, but, if my guess is right, the slowdown would only occur if you had clicked to Timewarp To the next node.

[regex]

The word "system" may refer to their new Timewarp To feature, mentioned in previous Devnotes. Its not completely clear from this wording, but, if my guess is right, the slowdown would only occur if you had clicked to Timewarp To the next node.

In any case, however, there is also a new system in place which sets a time warp limit when approaching an SOI transition. This was something I added before this new fix, and even though it isn’t strictly necessary anymore, it is quite nice to have anyway, as it highlights the SOI transition event, and lets you know something important is happening.

By leaving out the bolded parts you obscure the actual description of the feature to make your argument. It is quite clear, in context, that this system is not voluntary, and isn't even really necessary.

Time warp clamps need to die.

Before someone claims otherwise, I'm not mad or up in arms about this (well, I'm not pitchforking about it, anyway), it's just something that has annoyed me since I started really playing this game (yes, from 0.20). Time warp clamps make no sense in KSP, most especially now.

Edited March 25, 2015 by regex

[NoMrBond]

This has come a few times with basically no detailed information and it has me seriously worried. It sounds suspiciously like an activation or anti-piracy system, with all the limitations, intrusiveness, and generally spoiling things for customers without stopping pirates that that brings with it. I don't want a KSP that disables itself if I haven't connected to the internet in a week or interferes with me having multiple copies of the game with different mods and I really fear Squad could be sucked into exactly that.

I thought this was part of KerbalEdu for managing (multiple computer) installations in the classroom environment?

That's what sprung to mind anyway, maybe I'm misremembering though.

[Pecan]

The pictures Max shows off during Squadcast are posted to our social media immediately afterwards and find their way to every corner of the community within minutes, at least in my experience. If you don't want to see the entirety of Squadcast that's fine, but I think providing transcripts goes a bit far, especially because Squadcast is not scripted. That said, I love the Squadcast summaries that pop up every week here on the forums, perhaps that's an alternative to watching the livestream as well

Media is also a bit wider than just Squadcast here, we need to plan for people wanting to make release videos for KSP, or stream it just before release: how do you get pre-release copies to those people? What content can we allow and when can we do that? All those things need to be made clear so everyone plays by the same, fair rules.

So ... no.

Videos, streams and pre-release for people that do videos and streams.

Nothing for anyone that doesn't want to watch videos and streams.

I get it.

[basic.syntax]

By leaving out the bolded parts you obscure the actual description of the feature to make your argument. It is quite clear, in context, that this system is not voluntary, and isn't even really necessary.

I agree that what is described is not voluntary: in the context of the word "system." I admitted I am guessing on the intent of the word "system," it would be nice to see some Squad clarification on this point. But I don't see a contradiction to my guess, in the full context. The word "system," which could refer to Timewarp To, was something added before the SoI transition change. It has approaching-SoI slowdown, built into it. Another clue I take from a previous devnote, when the feature was handed off to QA: "This includes features like the timewarp-to system"

I agree with you that time warp clamps near planets can be annoying. I don't fully understand the need for their layerings of different multipliers at different altitudes.

[Superfluous J]

The pictures Max shows off during Squadcast are posted to our social media immediately afterwards and find their way to every corner of the community within minutes

So ... no.

Videos, streams and pre-release for people that do videos and streams.

Nothing for anyone that doesn't want to watch videos and streams.

I get it.

I don't think you do. "Social Media" =/= "Video." "Social Media" encompasses everything from KSP TV to the forums to YouTube to Reddit.

While I don't want Maxmaps dropping a hint about dV in a buried post on Reddit that we don't see here for 3 days, I really think that hating on them for putting stuff on their official Twitch channel before it shows up on their official forums is okay.

[Starwaster]

+1 to SOI time warp limits on SOI.

I've missed a few because I zipped through two SOIs too quickly and could have used a safety net.

[Dodgey]

By leaving out the bolded parts you obscure the actual description of the feature to make your argument. It is quite clear, in context, that this system is not voluntary, and isn't even really necessary.

Time warp clamps need to die.

Before someone claims otherwise, I'm not mad or up in arms about this (well, I'm not pitchforking about it, anyway), it's just something that has annoyed me since I started really playing this game (yes, from 0.20). Time warp clamps make no sense in KSP, most especially now.

I always thought that the time warp clamps were due to errors in calculating orbits at high time warp. I'm sure you know the bug of being able to warp through a planet At high time warp.

[Superfluous J]

I always thought that the time warp clamps were due to errors in calculating orbits at high time warp. I'm sure you know the bug of being able to warp through a planet At high time warp.

On rails and with no encounters with anything, an orbit is perfectly accurate at any time warp. Literally you can just jump the game forward 47 billion years and 18 seconds and know to the millimeter where your ship will be.

Time warp constraints should be a factor of periapsis, altitude, and next SOI change, like so:

• If your* periapsis is not within the atmosphere or hitting the ground, you should be albe to just jump forward an orbit, or any time warp speed up to that, because you KNOW you are 100% safe to do so.
  
• If your* orbit encounters an SOI boundary, the game should at least slow down a little to let you get ready. If - like regex - you literally don't care then you should be able to hit the "." key to indicate "no, I don't care abot that" and keep warping.
  
• If your* orbit encounters air or ground, then time warp should slow as you approach, much like it does now for altitude changes but in this case it's ONLY if your periapsis is low enough. If your periapsis is 70km over Kerbin and your apoapsis is under any potential Mun encounter, a bajillion times time warp should be possible.
  

*"Your" in this case is every ship. The game should track every ship with potential SOIs and slow down to warn you of their changes, like KAC does. It should also know which ships will NEVER have an SOI change and IGNORE them for all calculations, only checking where the math says they'll be when necessary.

Edited March 26, 2015 by 5thHorseman

[regex]

I'm sure you know the bug of being able to warp through a planet At high time warp.

E: and seriously, let the player smack into the planet. I'm a big fan of letting the player be as idiotic as they want to be.

I see no reason why the SOI boundary code couldn't be creatively applied to the warping through planets bug, you're really only checking distance to origin, as I understand it.

Edited March 26, 2015 by regex

[cpast]

I see no reason why the SOI boundary code couldn't be creatively applied to the warping through planets bug, you're really only checking distance to origin, as I understand it.

E: and seriously, let the player smack into the planet. I'm a big fan of letting the player be as idiotic as they want to be.

That may or may not work, depending on the SOI change code. How does the code know you should have changed SOI? Does it detect that you *did* change SOI (and so step back through the full trajectory), or is there some more complicated way? If the former, you can't use it for planets, and it won't stop you from timewarping through a tiny bit of an SOI without a forced slowdown (if you would enter and leave it in the course of a single tick, I think it wouldn't notice that you should have changed SOIs).

The issue with the planet isn't that the player will smack into it; it's that the player *won't*. I have had missions where I was approaching Kerbin at high speed and max warp, on a trajectory that intersected the ground, in which I passed from the altitude with no timewarp restrictions *through* Kerbin within the span of a tick. I should have smacked into Kerbin, but I was apparently flying fast enough to go through a planet without stopping.

To expand on what 5thHorseman said: When you're in a closed orbit that's above the atmosphere and doesn't enter any other SOIs, there is a closed-form expression for your location and velocity at any given time. The orbital parameters need not change (and I don't think they do); there's no need to even bother storing the calculated location for use in future calculations, because you can throw it out and recalculate position from the orbital elements (which didn't change) and time at the next tick. Rails orbits, if they're implemented decently, cannot go unstable.

[regex]

That may or may not work, depending on the SOI change code. How does the code know you should have changed SOI?

Did no one but me read Harv's part of the dev notes? KSP already checks for SOI transition and planet intersection, and Harv stated it will slow down the timewarp on SOI boundary approach.

SOI is basically distance from origin; there is no real reason the same method for SOI transition can't be used to determine if you smack into a planet, or the planet's atmosphere for that matter, since both of those things on the scaled space level are essentially the distance from origin E: which is a simple trigonometric function. After that it's a simple exercise in letting the player be as idiotic as they want, damn the consequences, or treating them like they don't know what they're doing and slowing down warp if something catastrophic would happen. Any of the boundary checking functions can take advantage of the SOI boundary prediction code to either let the player crash at full timewarp or be allowed maximum timewarp with slowdowns before any boundary transition, as 5thHorseman suggests.

Edited March 26, 2015 by regex

[kofeyh]

Unless they've been doing something silly with GC, the way that you reduce garbage collections is by reducing the amount of garbage you produce - so it's kind of implied that they've been improving on their memory usage (probably by reducing unnecessary allocations or introducing object pools or something similar).

It's not so much "doing something silly with GC", it's that there is virtually no GC. Assuming the removal of collection from a game (that does not actively unload textures) is a good thing, isn't actually a good thing.

This is a very bad thing unless it's being sorted out elsewhere. Because at present the game currently has some bad memory leaks; without improved memory management, I foresee that that behaviour might actually get worse.

I think most people who encounter this in 0.90 would rather there WAS some degree of clean up. Try doing a number of scene changes and watch the memory usage. It's not.. optimal.

- - - Updated - - -

Indeed--once you've reduced the garbage to collect, you can improve performance further by reducing the garbage collection itself.

True. But it's one thing to reduce garbage collection when you are reasonably efficiently loading and unloading assets. It's a little different if there isn't a lot of optimisation; or, well, really any unloading to speak of.

KSP just keeps on allocating memory until it hits the 32bit address limit and crashes. There's no consideration yet, as I understand it, to dynamically load or unload assets in-game.

I'm not going misconstrue what Mu or HarvesteR have said, all the same. If loading and unloading is more efficient and is doing at least some clean-up - great. If they're just removing it to address 'stuttering', then that's a little different.

Nothing is really being said about optimisation of the game and texture management beyond a further discussion about DDS formatted assets. Which suggests 1.0 certainly won't be unloading much of anything.

Edited March 26, 2015 by kofeyh

[Crzyrndm]

How did it get to the GC being removed from:

...lots of little tweaks to reduce the game’s CPU load and garbage collection...

I think there is a bit of misunderstanding here

[kofeyh]

I think there is a bit of misunderstanding here

Possibly? It's such a vague statement it's hard to know what it means. I'm hopeful that it improves things. It's just not entirely clear how GC is being improved. So it reads more like little tweaks to reduce CPU load.

My point was I hope that doesn't mean virtual removal as there isn't a huge amount done now.

[Crzyrndm]

If it's a vague statement then don't go blowing it out of proportion with random speculation.

[cantab]

Regarding unloading, keep in mind that unloading the ship parts serves little purpose. The game doesn't have and can't reasonably have anything to stop you putting every part in physics range. Dynamic loading on boot would make the game start up quicker, at the risk of causing lag in the VAB. It also means the game wants to be able to dynamically reduce texture resolution to stay in the RAM limit, otherwise you get crashes during play - *far* worse IMHO than crashes on game start.

The planets and the Space Centre, on the other hand, are great candidates for unloading. but again for this to be *useful* the game wants that dynamic texture resolution reduction. And adding such a feature seems like a lot of work to solve a problem, the 4 GB memory limit, that once the memory leaks are fixed will only affected modded games. This could provide some benefit since the player only needs to have one planet fully loaded at a time. But then I don't know if any changes are needed for situations like being on Vall with Jool, Laythe, and Tylo all appearing in the sky.

Such an approach, without the measures to stay in the RAM limit, could also make things less predictable for modded players. Imagine being halfway through a career, upgrading the VAB, and suddenly you're getting crashes when you try and launch rockets because the upgraded VAB needs more RAM and that combined with your parts packs and visual enhancements pushes you over the limit.

Edited March 26, 2015 by cantab

[Gkirmathal]

@Cantab, what you describe should not pose a problem if KSP does not use an AND / OR like system.

The client could analyse on startup, all parts/textures and their allocated locations on the HD sectors. Use 'a database' for these locations, so streaming the respective data from HD to RAM/videoram would be possible when it is needed.

This could on startup give an accurate number of your max memory footprint, or if it goes over the 32bit ram limit. Then one can build in features to prevent it, like not being able to start a game, or warn the user of their impending doom

About lag in the VAB, don't use dynamic loading.

Only load all parts when entering the Editor. This would indeed increase the scene loading time, but as KSP could know where what to load as from the above, it would also limit it.

Exiting the editor unloads all parts/textues and only loads what is needed for the ship/scene you changed focus to.

Planets I fully agree on!

I also think more LOD levels would also help here. No need to have LOD0 when you are soo far away you cannot make out any details.

But heck, I think this is not how Unity could work from what info I could find on it. So read my idea just as an idle hope

[KerbMav]

Only load all parts when entering the Editor. This would indeed increase the scene loading time, but as KSP could know where what to load as from the above, it would also limit it.

Exiting the editor unloads all parts/textues and only loads what is needed for the ship/scene you changed focus to.

So five minute breaks after every failed launch? Naah ...

[godefroi]

Garbage Collection (known as GC) is not related at all to dynamic loading and unloading of assets. At least, not directly. Garbage collection is the process by which memory that was used but is now unused is returned to the pool of "free" memory. This process takes time, and therefore, some non-zero percentage of the work that KSP is doing is going to memory management instead of drawing planets and explosions on the screen. In order to reduce this percentage of "wasted" time, the best option is to generate less "garbage", that is, to allocate fewer objects on the heap, or, failing that, allocate more short-lived objects, as they're faster to collect.

[Gkirmathal]

So five minute breaks after every failed launch? Naah ...

That would be with the current system indeed and I think you will share the idea that that needs to be changed for something like this te work

[Jumpyyoza]

So glad to hear about the fixed SOI transition bug. I really wished that there would be a patch that would make sure the game doesn't lie about wether or not I have a Minmus encounter. Thanks Squad!!

[Wallygator]

I really had a really really hard time understanding Harvester's comments. So I "Harvested" the essential bits and summarised them as follows... (based on a bit of calculus of statement)

(beginning of not quote marks) This week was devoted to bug fixing. We haven’t been able to run builds as well as we like. I’ve been mostly running around tying loose ends that came up during integration of recent features. I have been able to implement one thing (crossing SOI boundaries without having to worry so much about warping) and there will be a new system in place which sets a time warp limit when approaching an SOI transition (end of not quote marks)

If I miss-interpreted the communication, then I ask forgiveness.

If I got the above correct, then its fair to assume things are not going so well...

CRITICALLY IMPORTANT NOTE ---> The above comments are my own interpretation and NOT in any way to be construed as a communication from the squad dev team or Harvester.. so there!

Edited March 27, 2015 by Wallygator

[basic.syntax]

I would not get too "down" about interpretations of progress in the previous week. I think development must logically have faced some temporary downtime, due to the moving of server hardware. Progress was probably progressing at a normal rate, by the time the devnote was posted. [oops EDIT:] by now, "Hopefully things will settle down over the next few days."

Edited March 27, 2015 by basic.syntax