KSP Loading... Preview: Breaking Ground - Robotics

[MechBFP]

1 minute ago, schwank said:

Not sure if this is in the works, but it would be great to have some telescoping parts, stuff that can extend from being "packed away". 

 

So we can build long deployable arms and probe extensions.

You can somewhat do this with hinges although it is a lot more janky and not as space saving.  

Pistons also would work for that, depending on how long they can extend.

[Rejected Spawn]

I'll have you all know I'm building elevators as soon as I get the time to play around with the robot parts. I don't even care if they're supposed to be possible with the new parts, I'm building them! [ScreamingKerbalWavingAWrench.jpg] (would provide actual pic but my photoshop skill is on the level of a cat chewing on a crayon)

[Fearless Son]

Know what else I want to do with these parts?  I want to make hinges for attaching different rover parts together.  For example, I might have a "drive" section of a rover, with a "trailer" section it attaches to that can maintain a loose hinged connection.  That way I can undertake some awesome surface expeditions (which I expect to do more of with the new surface anomalies you can investigate for more science) with modular trailer components for crew or scientific experiments or extendable solar panels for more efficient recharging.

I think that would be really neat, and something I would expect NASA to do in future missions to the Moon or Mars.

[basic.syntax]

42 minutes ago, Fearless Son said:

surface expeditions

Not to discourage your efforts, but whether it's worth the trouble of taking an elaborate rover, for some other players, depends on the distance between surface features. Some won't want to spend half an hour or more driving across a largely featureless landscape, to get to the next point of interest. These new surface features are a step in the right direction, though. Next I would like to see an expansion / overhaul of the "scatter" system, to dynamically landscape the terrain around the player with many more interesting things to see, on long drives. 

Other games might statically place thousands of objects to create an interesting landscape, but I don't know if the current game engine would support static placement of so many different kinds of objects. It would not matter how nice it looks, if such an update turned the game into a 1 FPS slide show.

[Fearless Son]

58 minutes ago, basic.syntax said:

Not to discourage your efforts, but whether it's worth the trouble of taking an elaborate rover, for some other players, depends on the distance between surface features. Some won't want to spend half an hour or more driving across a largely featureless landscape, to get to the next point of interest. These new surface features are a step in the right direction, though. Next I would like to see an expansion / overhaul of the "scatter" system, to dynamically landscape the terrain around the player with many more interesting things to see, on long drives. 

I might expect to see some contracts that play around with this concept that might make rovers useful.  For example, a "take sample readings at positions A, B, and C triangulated around this particular surface feature you already discovered," would be a good reason to keep a rover in play.  Assuming it can generate power, it doesn't have the limited mission duration that a "hopping" lander would have, and you can leave it alone until you need it again.

The other element to this is those deployable science stations that the update is adding.  From the sound of it, you set them down and they gradually build up science data over time.  We'll want to get a scientist out to the point we're placing the station, then later have the scientist return to collect data.  Might be worth keeping a rover by a surface base to enable trips to and from the sample site.

[Gargamel]

I'm just psyched for hinges.  My mega rovers I have designed for eve... well they just don't do well on hills.  16 some sets of wheels, and no suspension.   An articulated suspension system will be so nice to have. 

I'm also eager to see the explosion of new stuff you guys post.  This is gunna be good. 

[StrandedonEarth]

[Pthigrivi]

Another thing I'm excited for is being able to fold up engine nacelles behind a heat shield so I can keep the weight forward while aerobraking. 

...oh wait can we also have flexible fuel ducts plz thx.

Edited May 17, 2019 by Pthigrivi

[Superfluous J]

1 hour ago, Pthigrivi said:

...oh wait can we also have flexible fuel ducts plz thx.

I wonder what will happen if you connect a yellow fuel pipe or a strut across a hinge.

Or a rotor.

[RedSun Rocketry]

17 minutes ago, 5thHorseman said:

I wonder what will happen if you connect a yellow fuel pipe or a strut across a hinge.

Or a rotor.

I see three options.

1  you wont be able to

2 the pipe will stretch

3 the Kraken will punish you for you're Insolence

 

[Geonovast]

1 hour ago, 5thHorseman said:

I wonder what will happen if you connect a yellow fuel pipe or a strut across a hinge.

Or a rotor.

I don't think the fuel pipes will be an issue, they already seem to handle it.

Struts, however, just kept everything from moving until they broke and the thing snapped in half.  Hopefully at the worst, if it detects struts across a moving part, it will just snap the struts and not kerplody the whole thing.

[Loskene]

40 minutes ago, Geonovast said:

I don't think the fuel pipes will be an issue, they already seem to handle it.

Struts, however, just kept everything from moving until they broke and the thing snapped in half.  Hopefully at the worst, if it detects struts across a moving part, it will just snap the struts and not kerplody the whole thing.

Is that from the new build? They redid autostruts? Oh my. What happens when they rotate past the point where the fuel lines would cross the central core there?

[Poodmund]

9 hours ago, basic.syntax said:

Other games might statically place thousands of objects to create an interesting landscape, but I don't know if the current game engine would support static placement of so many different kinds of objects.

It does, in vanilla KSP... already, it pretty much always has done.

You can specify as many different scatter objects as you like, all different models, the effort and time just has to be put in to model and texture these objects and then specify the configuration of these for the specific body on question. The density of the scatter is also specified here so it would just be a case of ensuring that the density is low enough for all the scatter object specified that they do not overpopulate any certain region that they may all be evident in.

It's been possible for years to do this, as I say again, it just required time and effort to be put into doing it. I guess it was never seen as a priority.

[woeller]

3 hours ago, Loskene said:

Is that from the new build? They redid autostruts? Oh my. What happens when they rotate past the point where the fuel lines would cross the central core there?

No it‘s a mod called DockRotate

[basic.syntax]

38 minutes ago, Poodmund said:

You can specify as many different scatter objects as you like, all different models,

Does it support models 'with collision' ? Because I think that may be important for some classes of new objects... if you want to position a robotic sensor arm near the surface, as opposed to a generic placement / origin point. That's why I wanted to distinguish between hand-placed objects such as the new surface features, which may be more resource intensive, versus "scatter" objects. Small rocks, small debris, grass, flowers - should remain no-collision but I'm thinking if planet/moon surfaces get fleshed out with tons more features to make driving around more interesting, more objects with collision models becomes important, to create the sense of a "real" landscape.

[Poodmund]

1 hour ago, basic.syntax said:

Does it support models 'with collision' ? 

It can do, it's just it is not implemented in Vanilla for all instances of the stock scatter objects.

[steve_v]

1 hour ago, basic.syntax said:

objects with collision models becomes important, to create the sense of a "real" landscape.

Collision is absolutely important, both in the future and for the larger scatter objects we have already. Nothing destroys immersion quite like driving straight through a tree or a boulder.

I actually run with scatter off most of the time because the lack of collisions annoys me so much.
I had pegged it as just another aspect of the general "terrain looks like crap and always has" effect, but if we're going to get new terrain objects I certainly feel the old ones and the surfaces they sit on should get some love as well.

Edited May 17, 2019 by steve_v
Profanity filter is appallingly frustrating. I can have "crap" but not "ãrse"? W.T.A.F.

[Superfluous J]

3 hours ago, Poodmund said:

It does, in vanilla KSP... already, it pretty much always has done.

I don't know how it works now, but there was a time not so long ago (1.0ish) where just the normal 100% scatter would bog your computer down to the point where you needed to reboot because you couldn't close the game.

Granted that may have been a memory leak, but it was still nasty. I wonder how well KSP would do with terrain covered in scatter to any appreciable distance (far enough where pop-in wouldn't be super obvious).

[MechBFP]

I hope that the robotics parts can calculate TWR, so I can tell if I need bigger blades for properllers or helicopters. 

[Loskene]

10 hours ago, 5thHorseman said:

I don't know how it works now, but there was a time not so long ago (1.0ish) where just the normal 100% scatter would bog your computer down to the point where you needed to reboot because you couldn't close the game.

Granted that may have been a memory leak, but it was still nasty. I wonder how well KSP would do with terrain covered in scatter to any appreciable distance (far enough where pop-in wouldn't be super obvious).

Yeah that sounds like a memory leak, there've been a few bad ones in some builds. Normally garbage collection would take care of that but if it's being populated faster than it's being cleaned up for some reason ¯\_(ツ)_/¯

[GoldForest]

Do we know if the robot parts will allow fuel flow/crossfeed or will we need fuel pipes?

[Xurkitree]

20 hours ago, MechBFP said:

I hope that the robotics parts can calculate TWR, so I can tell if I need bigger blades for properllers or helicopters. 

Definitely not. Thrust is a very complex to calculate in such a situation, depending on the blade pitch, speed, air density etc etc. KSP won’t be doing which complicated math for TWR since it can wisely vary across designs.You’ll have to test it yourself.Another thing is that these hinges, not props and hinges aren’t engines, and you can’t make ksp use up resources calculate twr for a robotic arm where there’s no blades.

[Jasper_f]

I've been experimenting for the past two hours, and I cannot for the life of me use this reliably in a situation that matters for my playstyle. Ideally I would use this to align crafts in order to (1) transfer fuel, (2) move modules, or (3) transport cargo. For this purpose I created a very simple test module that I wanted to move with two identical rovers. Both use robotics to align their docking ports with the module. Docking of the first rover goes OK, but as soon as the second docks, it explodes and behaves as though in a 0G environment. This is in a completely stock install. Is anyone experiencing similar issues?

 

[To mods:] not sure if I should post this here, but thought it to be related.

 

 

 

[MechBFP]

53 minutes ago, Jasper_f said:

I've been experimenting for the past two hours, and I cannot for the life of me use this reliably in a situation that matters for my playstyle. Ideally I would use this to align crafts in order to (1) transfer fuel, (2) move modules, or (3) transport cargo. For this purpose I created a very simple test module that I wanted to move with two identical rovers. Both use robotics to align their docking ports with the module. Docking of the first rover goes OK, but as soon as the second docks, it explodes and behaves as though in a 0G environment. This is in a completely stock install. Is anyone experiencing similar issues?

 

[To mods:] not sure if I should post this here, but thought it to be related.

 

 

 

If it is reproducible then make a YouTube video and post a bug report. I’ll upvote it. 

[Jasper_f]

1 hour ago, MechBFP said:

If it is reproducible then make a YouTube video and post a bug report. I’ll upvote it.  

 

Yap. Here are two recordings: one with the situation I described, and the other a similar simple test with the Mk3 cargo bay. All done in a stock install of KSP v1.7.1.2539. Note that in the first scenario I can dock and re-dock a single craft, but as soon as I dock both the bug appears. This is opposite to the Mk3 cargo bay scenario, which destroys my rover immediately upon docking. Also happens when I try to connect to a docking port attached to the wing or fuselage.

 

Scenario #1: docking two rovers to a test cargo module using the new "Breaking ground" robotics.

 

Scenario #2: docking the same rover (with wheels slightly tucked in) to Mk3 cargo bay.

 

Edit: console output varies, but always appears to show the "Exception: NullReferenceException: Object reference not set to an instance of an object". Resulting either an explosion or parts of the rover to simply fly off into the sky. Will look into providing a bug report in the bug tracker.

 

Edited May 31, 2019 by Jasper_f