Is there a way to automate a rover to go from point A to point B while it's not the active vehicle?

[smjjames]

What the subject says. I know it's possible to automate launches and similar, but what about rovers?

[Kerbas_ad_astra]

You're not the only person interested in transferring vehicles automatically. I know that MechJeb does something like this for active vessels, but the issue that I imagine an inactive-vessel mover would have is the "in-between" stuff -- either the vehicle has to be poofed to its destination (maybe with some time delay) or it needs to find and follow a good path between A and B (and refuse to budge if it can't). The latter is less impossible in KSP than in the real world, as the environment is almost completely known, but even so, I don't think pathfinding is possible in general without human intervention (and peeking at MechJeb's rover autopilot code, it seems to me that it's basically a waypoint follower, depending on the user to set the path and monitor the situation for problems).

So poofing will probably be required, but what would be the difference between that and HyperEdit? I think something like ESLD Jump Beacons is the answer -- require an investment in some infrastructure (e.g. a vessel with a beacon at the destination) and place limitations on how the transfer can happen (e.g. limit distance based on beacon type, limit to areas with low ground slope). The Hangar mod offers what I think is the best kind of infrastructure to handle this stuff, so I've asked allista about it, but if allista's not interested in bringing it into Hangar, I might just make it a standalone addon myself.

[RainDreamer]

How about strapping some rockets on it and put it on ballistic orbit?

[Greenfire32]

I don't think it's even possible. Mods or not, the game doesn't really keep track of crafts that aren't currently active. Rover's would need physics applied to them and the planet would also have to be loaded at all times...I'm just not sure the core game is even capable of doing that.

Best case scenario would be the rover just...appears at the destination instead of actually driving there.

[tater]

Yeah, physics would need to be active in case it wrecks.

[Axelord FTW]

I don't think it's even possible. Mods or not, the game doesn't really keep track of crafts that aren't currently active. Rover's would need physics applied to them and the planet would also have to be loaded at all times...I'm just not sure the core game is even capable of doing that.

Best case scenario would be the rover just...appears at the destination instead of actually driving there.

Unsure.

Between the starting point and the target location, the distance is known.

Calculating the max speed of a rover is simple (or at least, easily compounded (weight, number of X wheels)

The travel time can thus be dictated.

You'd have to make Hyperedit or something similar do the grunt work based on the info (since X time has passed, place target vehicle at Y location).

It's be a buggy mess and focusing on the newly placed rover would probably result in it breaking or blowing up due to the probable change in inclines and the fact that it is now clipping through the ground.

With something like placeable waypoint/beacons, you could probably get something a bit more safe to work (ESLD Jump Beacons, as Kerbas_ad_astra said). You'd have to place those so the utility would be diminished but you'd probably get rid of the whole slanting/clipping issue.

[sarbian]

smjjames did not mention the need for the rover to move out of focus.

Mechjeb has a rover autopilot with waypoints and various intelligent controls.

[John FX]

smjjames did not mention the need for the rover to move out of focus.

Mechjeb has a rover autopilot with waypoints and various intelligent controls.

Although he did say if there was a way for the rover to do it when it is not the active vessel which does sort of imply out of focus.

"Is there a way to automate a rover to go from point A to point B while it's not the active vehicle?"

I would like to have such a feature because the thing that stops me putting an NTG on a rover and making it go 100km to a waypoint is that I would have to focus on it for the hours it would take.

[smjjames]

I did mean for the rover to go out of focus, not being the active vessel directly implies that it's not under my direct control and thus is not in focus.

[Cdr_Zeta]

Hello and hardy harr harr !!!

Yes in fact there is always a way...(!)...sorry...I aint spoiling...and let me tell you it does take some coding...well, I plan on even having a voiced computer to let me know what is going on as well - maybe I will call it the HAL9000...

When I get done with resources, some simple automation is on my list...there is actually a MOD out there..I have it installed...but I warn ya...there is a learning curve.

As an example, I am studying AI for automation using both software and hardware...not an easy task and my programming skills aint so great...there are programs called OpenCyc and Eclipse I am looking into as well...integrating HAL will be SO KOOL...if I can do it that is...

I should also mention, I am not talking about Voice Control, altho that is in the works as well...

Cmdr Zeta

[sarbian]

Although he did say if there was a way for the rover to do it when it is not the active vessel which does sort of imply out of focus.

"Is there a way to automate a rover to go from point A to point B while it's not the active vehicle?"

I would like to have such a feature because the thing that stops me putting an NTG on a rover and making it go 100km to a waypoint is that I would have to focus on it for the hours it would take.

Damn, I did not read the title

[smjjames]

Hello and hardy harr harr !!!

Yes in fact there is always a way...(!)...sorry...I aint spoiling...and let me tell you it does take some coding...well, I plan on even having a voiced computer to let me know what is going on as well - maybe I will call it the HAL9000...

When I get done with resources, some simple automation is on my list...there is actually a MOD out there..I have it installed...but I warn ya...there is a learning curve.

As an example, I am studying AI for automation using both software and hardware...not an easy task and my programming skills aint so great...there are programs called OpenCyc and Eclipse I am looking into as well...integrating HAL will be SO KOOL...if I can do it that is...

I should also mention, I am not talking about Voice Control, altho that is in the works as well...

Cmdr Zeta

What are you lauging at or are you doing an imitation of a pirate?

Voice control though really isn't what I mean. What I mean is having a rover (or other automated ground vehichle) do something automated (going from point A to point while I'm focused on another craft and the rover that is automated isn't even in the ~2.5km (think it might be 2km) loading distance or is going to leave that loading zone.

Edit: I know 'automated' could also mean that the rover do a whole host of other things, but I'm not thinking of anything further than going from point A to point B since any more than that gets into a whole host of complexities.

Edited March 5, 2015 by smjjames

[Cdr_Zeta]

Hi,

I understand...coding a repetiive task to go from Pt A to B is all and good as long as it is done out of warp when you know the Automation start and stop times; and that coding should be VERY simple; I havnt totally looked at it but if I am not mistaken, it is called: "kOS" or maybe Kerbal Operating System; I am devoting streams to it when and if I ever get there; there are remote parts that you attach to the vessel to script the vessel...; I have "kOS" as a MOD on my KSP I just havnt got to it yet.

Cmdr Zeta

[Dunbaratu]

kOS still can't fix the inherent problem in KSP of unloading the vessel when it gets far away. It *can* drive a rover that isn't the active vessel, but once it gets more than 2.5km away from the active vessel, it will stop moving unless you have modded the unload distance. And then even if you have, if you make the unload distance too long, you hit the space kraken problem that was the whole reason SQUAD had to make an unload distance in the first place.

[eddiew]

If the reason for the request relates to transfer, MKS has a logistics hub which can do it with 'drones'.

[Cdr_Zeta]

Hello,

I read about the drone thing; that is also interesting but doesnt drive a real ship/vessel; maybe coding both kOS and using this drone CFG together? I havnt looked at kOS I havnt a clue about vessel unloading; sounds like a persistent file communciation issue as well; porting the data to the persistent file (?); 2.5km isnt very far when ...wait what about Remote Tech?...Maybe use Remote Tech...maybe some combination of MODS pus kOS? I thought that you had to 'do a routine so that kOS would copy the controls/actions into a script; then the script is simply put into a loop and whallah...

Someday I will look at it; right now I am too resource-minded I need to stay in a work-flow...I am almost done I just seem to get into things too much and need to play this game lol !

Cmdr Zeta

[kahlzun]

There are also other mods which increase the physics distance, possibly without upper limit. Perhaps one of those would allow the rover to run while you're doing something else, somewhere else. You probably need to be within the same SOI, though..

[Dunbaratu]

2.5km isnt very far when ...wait what about Remote Tech?...Maybe use Remote Tech...maybe some combination of MODS pus kOS?

Sadly it's a hard thing for mods to change, given your goal of going 100km away. Some mods change the loading distance, but only by a small amount. A 100km loading distance is probably not going to be doable because of how the main stock game itself works.

The big reason there has to be a loading distance limit is because of how floating point numbers in computers store values. Small values near zero can be very precise, but the farther you get from zero the less precise they become. Trying to track the position of two ships that are fully operational with all the physics interactions going, that are located far apart from each other, means that they can't both be using small numbers. At least one of the ships has to be performing its position and velocity calculations using imprecise larger magnitude floating point numbers. The SQUAD devs found that when they tried to run the part versus part interactions (detecting collisions) on parts using numbers that big which cannot be precise, the system kept miscalculating the magnitude of their interactions due to the impossibility of storing their positions accurately with those big floating point numbers. Thus the parts kept being calculated as having "collided" with each other and your ship would explode very unfairly for no apparent reason.

This is what everyone's talking about with the "space Kraken" - its the mysterious monster that explodes your craft if you stray to far away from the origin of the frame of reference of the mathematics of your universe. SQUAD fixed it by recentering the universe origin to always be near your craft, not on the sun as was originally designed. But if there's two different vessels both loaded that are not near each other, then you can't have them BOTH be near the center of the universe, thus the loading limit being so small by default.

That's problem 1.

With rovers specifically, there's a second problem - terrain polygons.

When you are near the ground you see the terrain as being made up of polygons in a giant surface mesh. Each polygon being about 3 to 10 meters across (depending on your graphics detail settings). Now, imagine viewing the surface from space, high up - seeing entire continents in view. Try calculating how many polygons that is if each one is only covering 10 x 10 meters. Even a very modern high end graphics card would be choking to death on that.

Therefore terrain that is far away from the camera isn't *really* there - in the sense that those polygons aren't loaded. What you're looking at once the terrain is far from the camera is essentially a hologram with no physics on it *that objects would just pass right through*, made up of a proprietary mathematical heightmap algorithm SQUAD has for each planet. When you get closer to the ground, KSP takes sample points from that math algorithm and uses then to create the ground polygons based on calculating where the vertexes should be in the heightmap. When you leave the area, those polygons go away again.

The ground only really exists within about 7km of the camera. Those mountains off in the distance? They're not really there. They're holograms.

So that's a second problem with driving a rover that's 100km away from the camera. Not only is the rover itself not loaded, but even if it was, the ground on which it's sitting isn't loaded. It would fall through the holographic ground and into the planet.

- - - Updated - - -

tl;dr version - you can do some tricks to increase the loading range a bit - but not enough to be driving a rover that's 100km away from the camera. The terrain alone would make your GPU want to commit suicide.

[smjjames]

I see.

So, short of making it go suborbital or attaching a rocket to it and hoping it doesn't crash, you're pretty much left with some form of teleportation.

I've done suborbital (and low orbit) biome hoppers myself.

[Guest]

Maybe you could use a multi-player hack to run 2 or more instances of KSP at the same time. Then, you could keep the rover centered in one instance and control from another instance through a virtual network or something, just thinking out-loud here.