Jump to content

Devnote Tuesday: One One Three


SQUAD

Recommended Posts

On 6/14/2016 at 10:06 PM, SQUAD said:

Nathanael (NathanKell) split his attention across many areas of the game, fixing issues at the pace of… something insanely fast. A selection: fixed an issue introduced by the drift fix where acceleration would spike when transitioning between rotating and inertial reference frames (<100km to >100km orbits).

I may have missed this somewhere, but can we get an explanation of the difference between these orbits and why that was decided as the breakpoint?

Link to comment
Share on other sites

3 hours ago, Laguna said:

@KasperVld tweeted that there would be no devnotes today...because something else was coming...that being1.1.3.

This Thursday's Squadcast should be interesting. :)

 

 

Hmm, that sucks.  The throwaway patch that is still broken is not a good replacement for DevNotes, I don't know why they couldn't tell us more about 1.2.0.

Edited by Alshain
Link to comment
Share on other sites

@Alshain why throwaway?  better than waiting for 1.2 to implement those bugfixes, i think. For the short testing: on my end editor is much smoother now (deactevated crew) and no crashes so far - but yes wheels still are far from good.

Link to comment
Share on other sites

10 hours ago, KroShan said:

@Alshain why throwaway?  better than waiting for 1.2 to implement those bugfixes, i think. For the short testing: on my end editor is much smoother now (deactevated crew) and no crashes so far - but yes wheels still are far from good.

But you are waiting till 1.2 to get the game fixed.  It's still broken, we knew it would be.  I say throwaway because I won't even be playing it.  There is no point in wasting my time on it when we knew it would have massive game bugs before it even came out.

 

I just want to hear about how the development on 1.2 is going.  I don't know why releasing this patch would change that.

Edited by Alshain
Link to comment
Share on other sites

mhm - that's a point. Dispite the bugginess i had fun with 1.1 so far.
I also was shocked when 1.1 was released in a state which worked for me worse than the first prerelease. I hope the next engine upgrade helps and this comes to a good end. And hopefully it is possible to stick with Unity 5.4? for longer so that more bugs get fixed than introduced.

Link to comment
Share on other sites

Clouds can look cool as a backdrop, but if it was a random volumetric system, imagine lifting off right into a thick cloudbank, unable to see anything but your rocket :wink:  Oh nevermind, just timewarp until the weather is clear... lol  :wink: 

 

Link to comment
Share on other sites

6 minutes ago, basic.syntax said:

Clouds can look cool as a backdrop, but if it was a random volumetric system, imagine lifting off right into a thick cloudbank, unable to see anything but your rocket :wink:  Oh nevermind, just timewarp until the weather is clear... lol  :wink: 

 

Why?  The image of the rocket and ground below is unnecessary to fly it.  You have all the instrumentation you need, and the cloud layer isn't that thick.  It only exists in thick volumetric clouds between certain altitudes and then it clears again.

Edited by Alshain
Link to comment
Share on other sites

20 minutes ago, Alshain said:

Why?  The image of the rocket and ground below is unnecessary to fly it.  You have all the instrumentation you need, and the cloud layer isn't that thick.  It only exists in thick volumetric clouds between certain altitudes and then it clears again.

A clear view may be unnecessary, but cool... I like seeing the surrounding terrain fall away. It's no big deal to me tho, I would enjoy this and many other graphical enhancements that have been suggested over time.

Link to comment
Share on other sites

 

1 minute ago, basic.syntax said:

A clear view may be unnecessary, but cool... I like seeing the surrounding terrain fall away. It's no big deal to me tho, I would enjoy this and many other graphical enhancements that have been suggested over time.

I actually enjoy Rbray's clouds...the thicker the better! There's something about watching the craft pierce the cloud canopy... oh, and teetering through them....

Link to comment
Share on other sites

On June 14, 2016 at 5:18 PM, RoverDude said:

we've also ensured that you will not be put in a situation where your unmanned craft are 'bricked'

This has me curious. I also wonder, is it gonna be possible to set up maneuver nodes while coms are in range, and for probe cores to auto execute/stage to perform the maneuvers, even if they are out of antenna range? that would make the most sense to me. We all know how to set up maneuvers, and presumably, a sufficiently advanced probe core ought to be able to execute a maneuver remotely (at least a more advanced model... Early probe tech could be straight up remote controlled). Heck, we could even still get away with the same tiers of differing probe tech. A basic probe would still need full manual remote control. No line of sight, no control. The next tier could execute prograde and retrograde burns at prescribed times, for prescribed durations. If a maneuver node is beyond antenna range, then the normal and radial axes are disabled, and you can only do retro and prograde burns. More than sufficient for orbital capture.

The best part, is no one would need to learn anything they don't already know! We all know how to set a maneuver node. As long as we set it up before coms loss, we're good! You add the extra detail of remote coms, but you don't need to learn any new skills to do it, since it uses the existing system we all know!

Well, that's my $0.08
What? Inflation! ⤴︎
$0.02 won't buy nothing anymore! :sticktongue:

Link to comment
Share on other sites

3 hours ago, Jovus said:

Sooooo...

 

Does anyone want to explain the difference between <100km and >100km orbits, and why the difference exists yet?

I'm pretty sure this was discussed by @NathanKell in the last Squadcast.  I don't recall the exact answer right offhand, but I believe it has something to do with how the planet/solar system is rendered in comparison to your active ship.

Link to comment
Share on other sites

6 hours ago, Ignath said:

I'm pretty sure this was discussed by @NathanKell in the last Squadcast.  I don't recall the exact answer right offhand, but I believe it has something to do with how the planet/solar system is rendered in comparison to your active ship.

I believe it has more to do with how Krakensbane is implemented. For newer players Krakensbane is the name of the solution to the floating point errors that were occurring in KSP (the Kraken). Essentially what happens is that the game goes from treating Kerbin (or which ever body you are landed on)  as the origin to your ship as the origin, and i believe this change over occurs at orbits greater than 100km. As I'm sure you can imagine the math that goes into this sort of reference frame change is quite complicated and any small error in that math could lead to the loss of orbital altitude bug that was being reported. 

Edit: Ignath, its awesome to meet a fellow Minnesotan!

Edited by CaLVin-K
Link to comment
Share on other sites

17 minutes ago, CaLVin-K said:

I believe it has more to do with

You believe it has more to do with something other than what one of the devs described?  This is not krakensbane, that turns on at velocities over 750 m/s.  This is where the reference frame switches from rotating with the planet to not rotating. I'm on my phone at the moment so can't give more details but I'm sure someone will at some point. 

Link to comment
Share on other sites

4 minutes ago, Padishar said:

You believe it has more to do with something other than what one of the devs described?  This is not krakensbane, that turns on at velocities over 750 m/s.  This is where the reference frame switches from rotating with the planet to not rotating. I'm on my phone at the moment so can't give more details but I'm sure someone will at some point. 

Are you sure that Krakensbane is activated by speed. It was described to me as being activated by distance from your ship to the origin, which makes a lot more sense than velocity if you consider how floating point errors work. 

As to what the devs described, I read that as krakensbane, i.e. rotating, as in your ship is rotating (orbiting) around the plane. To an inertial reference frame, which is, you're ship isn't technically moving but everything else is in relation to it. 

Link to comment
Share on other sites

As I understand it, it's the threshold between inertial and non-inertial reference frames. Below 100 klicks, you're in a non-inertial, rotating reference frame, locked to the parent body (a planet). In other words, the terrain is moving at 0m/s (to the physics) and you move at whatever your Surface speed says. Above 100 klicks, you're in an inertial, non-rotating reference frame. I think it's locked to your ship. The inertial reference frame makes it so your ship moves at 0m/s (again, to the physics) and everything else within the physics bubble moves at whatever the relative velocity says.

The rotating reference frame allows for accurate vessel-terrain interactions which don't change based on the direction (since terrain is stationary), while the inertial one allows for accurate vessel-vessel interaction, as well as orbital simulation.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...