Jump to content

Devnote Tuesday: Joe was censored!


SQUAD
 Share

Recommended Posts

tumblr_inline_o1y4ewTX5s1rr2wit_540.jpg

Hello everyone!

The biggest talking point this week comes from Paris, France, as Ted and Kasper (KasperVld) sacrificed their weekend and Mexican holiday on Monday to attend the iGamer conference there. For Ted this trip came after a long working week which included his own tasks as well as a set of interviews for British media in London earlier last week. Both happenings were related to science in games and we’re very happy to be regarded as an example of how games can naturally familiarize kids with advanced scientific concepts. Playing games is a natural way of learning and it’s great to see so many people embrace this.

The Paris convention was a fantastic experience where Ted and Kasper got to meet fans, introduce many new people to the game and answer questions about the dev team, the game and even actual rocket science. Of course, explaining this in French proved to be a tall task, but with a little sign language, weird sounds and the translation services offered by KSPTV streamer and Minions character effects animator Richard Adenot on Saturday they managed to pull it off. Kids seemed especially drawn to the games, and flying around the Kerbals on EVA in particular. On Monday the two then met with Sarbian (maintainer of the Mechjeb mod) for a lunch, and headed over to the French space agency CNES for a meeting there. All in all a very busy schedule, but the trip was well worth it.

Back to development then: Felipe (HarvesteR) spent another week devoted to fixing bugs that popped up in QA, and has been mostly focussed on wheels, with one particularly ambitious test which consisted of a rover driving into the cargo bay of an aircraft, then flying that aircraft to the island airfield to drive the rover around around.

First time around a few worrying bugs were found, mostly related to landing detection and with cargo bays (“not again!”). The way wheel landing detection works is different from other parts: wheel colliders don’t actually touch the surface. Rather, the wheels raycast downwards to ‘feel’ for it, and based on what they find, and the known wheel parameters, they compute the appropriate reaction forces for each wheel to simulate forward and lateral friction, drive/brake torque, slip, etcetera. That in turn means that wheels need their own logic to detect when they’re landed, which is then further complicated because ‘landed’ in KSP doesn’t necessarily mean you’re touching terrain. You could be landed on a landed part, which would mean you are landed yourself.

Hopefully you’re still with us. Back to the case of driving a rover onto an airplane, by now you can imagine how things can get tricky in this sort of situation: at no point did the wheels come off the surface, so they think they’re still landed. However, as the aircraft takes off that landed state needs to change, because in the same way the rover is landed on the aircraft the aircraft itself is also in contact with the rover. The aircraft sees the rover is landed and therefore assumes that it is landed as well. Quite a knot to untangle.

Eventually Felipe managed to overcome this bug, and the same scenario now as expected. It’s possible to drive a rover into a cargo craft, close the cargo bay doors and fly off, then land somewhere else, back it out of the cargo bay, and drive off!

Last week we talked about doing traction control. Felipe had tweaked the engine power to the strength of the gravity of the celestial body you were driving on, but in testing this simple way of doing things turned out to be less reliable than expected. Back to the drawing board then. Now, the motors use a system that is much more analogous to real life traction control systems. They observe the wheel’s speed in comparison to the actual ground velocity under the tires, and based on that, each wheel is independently able to check if it’s slipping or not. If it is, the drive output is quickly modulated to compensate for it, so as soon as a wheel starts losing grip, the motor cuts out so it can get a footing again. As with the previous solution, you can tweak the traction control or turn it off completely with potentially horrible results!

Changes to the steering system have been made as well: the limitations on steering that were necessary due to the way the old wheel system was set up have been removed, and if you steer too hard it’s very likely that you’ll end up over- or understeering. Combine that with the tweakable traction control and, well, you guys will probably come up with whole new ways to crash rovers.

In QA testing we’re slowly nearing the end of the Unity 5 part of it all, and Steve (Squelch) and Mathew (sal_vager) as well as the rest of the QA team have slowly started the process of selecting the ‘old’ 1.0.5 bugs that need fixing for 1.1. We’re not forgetting about these in the slightest, and we hope to see a good number of them fixed soon™.

An area we haven’t yet touched on in this week’s devnotes is the user interface. For a long time the UI overhaul dominated the devnotes, and although it’s now taking a backseat to other tasks there’s a good reason to come back to it shortly, as a very crafty person found an album Felipe uploaded to imgur some time ago which shows the new right-click menus and a few other small UI tweaks. We didn’t intend for these screenshots to go out, but we’re very happy to see that you all like the changes regardless. Well done on uncovering these shots, cunning person who shall not be named!

On to the new features for 1.1 then: Daniel (danRosas) has created new achievement graphics for the consoles, Bob (RoverDude) continues work on the antenna relay system that we really want to squeeze into the update, and Dave (TriggerAu) is hard at work preparing the content for KSPedia. The count for the KSPedia content is currently at 120 basic screens, all of which have their text done but some of which are still lacking images. This week he and Mike (Mu) will focus on extending the content, and implementing some more functionality into the system.

The contracts system is definitely Brian’s (Arsonide) area of expertise, and it’s an area of the game that is under constant development. For update 1.1 the single objective World’s First contracts will be merged into the Explore contract line. Note that this does not include the automatic milestones, just the contracts. There was some overlap between these two contract types, and the Explore contracts would pick a celestial body at random. This led to many situations in which the Explore contracts would get ‘skipped’: the player would for example land on Mun before they had accepted the Explore contract for Mun, which would then never show up.

Exploration contracts can now appear multiple times per planet, with anywhere between one and three much more varied objectives. They adjust intelligently if any objectives happen to be skipped, and they also make use of the player weighted planets system we talked about in previous devnotes, albeit with some constraints to keep within their intelligent linear progression.

Tangible progress is also being made on the console releases of KSP: the certification process is about to start which means Joe (Dr Turkey) is finally on the home stretch in this area. That’s good, because there’s a lot of other things to focus on: an increasing amount of meetings we can’t talk about yet, finishing the planning of the final stages of the 1.1 update, the first stages of planning for the 1.2 update, invoicing, media for upcoming events such as the DICE awards and SXSW gaming (…)*

* at this point Joe’s story was ruthlessly cut short and censored by Kasper.

Link to comment
Share on other sites

The way wheel landing detection works is different from other parts: wheel colliders don’t actually touch the surface. Rather, the wheels raycast downwards to ‘feel’ for it, and based on what they find, and the known wheel parameters, they compute the appropriate reaction forces for each wheel to simulate forward and lateral friction, drive/brake torque, slip, etcetera. That in turn means that wheels need their own logic to detect when they’re landed

Where in here does it say why the wheels need their own logic to detect when they're landed? Shouldn't raycasting in the direction of gravity projected onto the perpendicular plane of a parts movement be enough to detect if a part is landed? Or is it just done differently for different parts for efficiency reasons?

Link to comment
Share on other sites

A question to the Devs.

Regarding the wheels, is it possible under the new system to have multiple wheels per part? Currently I use Kerbal Foundries to make these modded parts work (there's 8 rollers on each wheel), but since that will likely break in 1.1 and dev has halted it would be nice to switch back to stock like the rest of my robotics themed wheels. There's also this example of a part I have but haven't been able to get the 2 wheels working how I want http://i.imgur.com/qOR6gUd.gifv

Edited by ZodiusInfuser
Link to comment
Share on other sites

20 minutes ago, SQUAD said:

finishing the planning of the final stages of the 1.1 update, the first stages of planning for the 1.2 update, 

Whoa now, let's not get ahead of ourselves! I was hoping that 1.1 would be out by my birthday, but no such luck. Oh well. Really have high hopes for Unity 5, 64-bit Windows, maybe bigger ships without bogging down the system? :)

Link to comment
Share on other sites

24 minutes ago, SQUAD said:
 

Exploration contracts can now appear multiple times per planet, with anywhere between one and three much more varied objectives. They adjust intelligently if any objectives happen to be skipped, and they also make use of the player weighted planets system we talked about in previous devnotes, albeit with some constraints to keep within their intelligent linear progression.

Nice.  That will make for some more interesting player-driven gameplay.

Link to comment
Share on other sites

13 minutes ago, Tipped said:

 

Where in here does it say why the wheels need their own logic to detect when they're landed? Shouldn't raycasting in the direction of gravity projected onto the perpendicular plane of a parts movement be enough to detect if a part is landed? Or is it just done differently for different parts for efficiency reasons?

Parts don't use raycasting to detect collisions. For normal colliders, collision events are sent up directly from the physics engine, and parts listen for those to manage their collision states. 

Wheels, on the other hand, are a totally different thing. The wheel raycast is the main source of contact information, so it needs an entirely separate ground detection logic.

Mind though, that the ground detection logic I'm talking about is KSP's own logic, used to figure out vessel situations and so on. The wheels have their own internal 'grounded' flag used in the wheel simulation. The code I wrote here was essentially the 'bridge' between those two things.

 

Cheers

 

Link to comment
Share on other sites

Quote

Eventually Felipe managed to overcome this bug, and the same scenario now as expected. It’s possible to drive a rover into a cargo craft, close the cargo bay doors and fly off, then land somewhere else, back it out of the cargo bay, and drive off!

Was the bug preventing the plane from taking off somehow? I mean, I get how having the situation be correct is critical, but I don't see how it would prevent the plane from taking off....

Link to comment
Share on other sites

23 minutes ago, Tipped said:

Where in here does it say why the wheels need their own logic to detect when they're landed? Shouldn't raycasting in the direction of gravity projected onto the perpendicular plane of a parts movement be enough to detect if a part is landed? Or is it just done differently for different parts for efficiency reasons?

Like HarvesteR said:

5 minutes ago, HarvesteR said:

Mind though, that the ground detection logic I'm talking about is KSP's own logic, used to figure out vessel situations and so on.

Always remember: KSP uses a lot of custom mechanics, as many of the standard ones in Unity aren't enough to have such a large scale game.  The way some of these are done is simply ingenious.

Link to comment
Share on other sites

46 minutes ago, SQUAD said:

For update 1.1 the single objective World’s First contracts will be merged into the Explore contract line.

This is great! Whether this was your own intuition or it was listening to the community, or both, career mode should tighten up a bit with these tweaks you are doing. Looking forward to 1.1! Thanks!

Link to comment
Share on other sites

7 minutes ago, fireblade274 said:

Putting rovers inside cargobays; it sounds like some cargo straps would be a great help for keeping those things in place for multiple transportation's :wink:

1.2 getting started twooooo ooohhh

Meanwhile at Squad...

Devote Tuesday - Feb. 9th  DRAFT

Introducing KSP 1.0.6...

Link to comment
Share on other sites

20 minutes ago, Red Iron Crown said:

Sounds like a wheelie good update.

I'll get my coat.

it does sound like it's getting nicely rounded off. 

 

33 minutes ago, SQUAD said:

It’s possible to drive a rover into a cargo craft, close the cargo bay doors and fly off, then land somewhere else, back it out of the cargo bay, and drive off!

In this scenario was the rover just loose in the cargo bay? or docked?  Do the changes mean that a rover which is docked inside a cargo bay (or even a container made out of panels) will no longer clip through the container once in flight, which is something that often happens atm.
Are wheels any more or less sensitive to being clipped? Mostly talking about having the wheel mounting clipped into something, not the actual wheel.  But there are some nice designs out there which involve putting two wheels so they're slightly clipped (or at least right next to each other).  Will that cause any odd interactions now?

35 minutes ago, SQUAD said:

In QA testing we’re slowly nearing the end of the Unity 5 part of it all, and Steve (Squelch) and Mathew (sal_vager) as well as the rest of the QA team have slowly started the process of selecting the ‘old’ 1.0.5 bugs that need fixing for 1.1. We’re not forgetting about these in the slightest, and we hope to see a good number of them fixed soon™.

Hooray!! *quietly slides a note about the stutter bug across the table

 

Link to comment
Share on other sites

6 minutes ago, katateochi said:

Hooray!! *quietly slides a note about the stutter bug across the table

ALSO PQS OCEAN LAG PLEEEEEASE!

Sorry for the all-caps but my computer would be very appreciative.  Thx.

Edited by regex
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.

 Share

×
×
  • Create New...