[KSP 1.3.1] Bon Voyage 0.13.2.1 - Make your wheels rolling! 2017-10-15

[ThatHomelessGuy]

Can we get something like this for boats and ocean floor crawlers? Or maybe a set of rover options for navigation eg : Terra/amphibious/marine/submarine/bottomfeeder letting us turn on any rules that apply and thus allowing the rover to choose navigation methods. I realise amphibious/marine vehicles might be hard to determine propulsion/bouyancy but it would be nice if I could send my amphibious vehicles across rivers and fjords instead of waiting hours or days for them to work their way round. I mean I don't mind sending them to the banks and then manually making the crossing and it's nice to break it up and actually drive some of my rovers but It would also be nice to let them self navigate when the vehicle is capable. Currently I use the north pole as a crossroads for the continents on kerbin but If It didn't take forever to cross some of the seas I'd be making straighter lines to the destinations.

And you know unmanned rovers on Eve. Nasa would use remotely capable amphibious vehicles.

Also I haven't tried it yet but can you put mini rovers with the module onto the same deployment/delivery rover and deploy them?

[RealGecko]

3 minutes ago, ThatHomelessGuy said:

Can we get something like this for boats and ocean floor crawlers?

It's been discussed already, read the thread.

4 minutes ago, ThatHomelessGuy said:

Also I haven't tried it yet but can you put mini rovers with the module onto the same deployment/delivery rover and deploy them?

If your minirover is docked to the main one, thus making both one vehicle then yes

[ThatHomelessGuy]

4 minutes ago, RealGecko said:

It's been discussed already, read the thread.

If your minirover is docked to the main one, thus making both one vehicle then yes

I think you misunderstood. I'm asking can you put multiple mini rover(S) on a single rover each with their own module attached and still have the deployment rover with it's own module I probably should have been more clear. Will the multiple modules interfere with each other? I figured it was assumed they would be docked and not simply tethered as that would obviously cause issues with the tethered rovers outside of physics range. (where the module does it's magic)

[RealGecko]

1 minute ago, ThatHomelessGuy said:

I'm asking can you put multiple mini rover(S) on a single rover each with their own module attached and still have the deployment rover with it's own module I probably should have been more clear.

Ah yes, there's a problem I forgot to mention in the OP: multiple BV modules are absolutely useless, as only one of them will work, the closest to the root part I presume

The module detection code needs to be revamped in some way, it's really ugly now. And I presume I need to add some checks for multiple BVs onboard.

I predict that it will work like this:

1. your main rover is a root and it has BV
2. subrover docks with main rover, it has BV too
3. as main rover is a root, subrover's BV is completely ignored, you can activate it but it will not drive

Try this out at runway, I bet you'll find solution for this trickery

[ThatHomelessGuy]

18 minutes ago, RealGecko said:

Ah yes, there's a problem I forgot to mention in the OP: multiple BV modules are absolutely useless, as only one of them will work, the closest to the root part I presume

The module detection code needs to be revamped in some way, it's really ugly now. And I presume I need to add some checks for multiple BVs onboard.

I predict that it will work like this:

1. your main rover is a root and it has BV
2. subrover docks with main rover, it has BV too
3. as main rover is a root, subrover's BV is completely ignored, you can activate it but it will not drive

Try this out at runway, I bet you'll find solution for this trickery

Thanks so It's safe to just stick the module on the command probe of each rover and assume the nearest to the root controlling part will be the active module and "safe" to use.

I was more concerned about it just not functioning at all with more than one or with them all trying to pull off the same job at once. I'll try some experiments later when I get a chance. Now I want to simply tether 2 vehicles and then send them in opposite directions just to see what happens when you load 2 tethered vessels that are connected but not loaded together

 

[RealGecko]

2 minutes ago, ThatHomelessGuy said:

Now I want to simply tether 2 vehicles and then send them in opposite directions just to see what happens when you load 2 tethered vessels that are connected but not loaded together

If they're not one vessel, then they will go to opposite directions

[ThatHomelessGuy]

1 hour ago, RealGecko said:

If they're not one vessel, then they will go to opposite directions

Right but what if the game considers them still tethered with a limited tether but separate vehicles like a tow rope or grapple and you try and load one what will happen?
Time to SCIENCE!!!!!!!

 

[Chakat Firepaw]

A thought I had for handling insufficient power production:  Have it result in a reduced speed, (representing regular stops to charge batteries).

The logic would be along the lines of:

1. Determine power required (P_r)
2. Determine power production (P_p)
3. If P_p < P_r then
4. Check if batteries can power full speed for a set time, (say 5min).
5. If so, travel speed is max speed * P_p/P_r, if not return "rover is incapable of extended operations."

 

[RealGecko]

BV does not interfere with batteries in any manner for reason. Many people use life support systems, some of then AFAIK calculate power in background. So, nobody wants to end up in situation when kerbonauts die because of lack of electricity drained by wheels controlled by BV. That's why I created such a tricky system. Logic behind is like this:

• if your wheels consume 35% of overall power production, it means you have 65% left for other systems and you never run out of electricity
• if your rover is solar powered it will idle at night, meaning no drain by wheels at all, so only LS systems or maybe something else will drain your power and if something bad will happen BV is not involved.

So we assume that if power production is suffitient, then rover can be moved without interfering with current electric charge at all.

And by the way: moving at lower speeds increase your power consumption, meanwhile moving at ~max speed wheels power drain will be near zero. Wheels consumption curve in KSP is really tricky and I don't want to overwhelm BV logic too much.

And also in next release there will be some serious average speed reduction, it's a trade off for making your operations happen in background. I want to be closer to reality, while keeping mod as simple and as not CPU hungry as possible

[Eklykti]

Thank you for this mod, now rovers can be much more playable without having to drive around manually for hours.

One thing that was already mentioned is that it would be good to recognize other power sources besides solar panels. For example, there are fuel cells with ModuleResourceConverter that produce ElectricCharge as one of their OUTPUT_RESOURCEs. I didn't try the stock ones, but, for example, Alkaline Fuel Cell Mini(setiMiniAFC) from SETI probe parts certainly doesn't work.

[RealGecko]

Just now, Eklykti said:

For example, there are fuel cells

I think it's bad idea. As I already mentioned just in previous post: BV won't calculate any resources in background, and fuel cells produce electricity by cost of LfOx. Stock RTG's are defenitely working, that was tested and I'll also add support for nuclear reactors from USI and Near Future in next release

[WintericeUK]

Jebediah, Valentina and Bob return from their six day polar expedition during which they thoroughly tested their Bon Voyage auto-drive systems...

Their responses?

Jeb - "It's awesome! I want one for boats too!"

Bob - "Very useful, I was able to spend more time on science as a result!"

Valentina - "Out of the way, nobody get between me and the showers! Oh, the BV? Worked a charm, now MOVE!"

 

[Melfice]

Right.

Might be an unhappy combination of mods, I don't know.
But letting an automated rover come close to your active vessel does NOT only tank your framerate. It turns the automated rover into a deadly, deadly, dead-accurate projectile homing in on your craft.

I'm sure there's nothing to be done about that, and it's not a huge issue for me, but... just a heads up, assuming this happens for everybody.

[Chakat Firepaw]

On 28/10/2016 at 0:31 AM, RealGecko said:

BV does not interfere with batteries in any manner for reason. Many people use life support systems, some of then AFAIK calculate power in background. So, nobody wants to end up in situation when kerbonauts die because of lack of electricity drained by wheels controlled by BV. That's why I created such a tricky system. Logic behind is like this:

That would just mean that the stops happen before the battery is drained, rather than when it's down to dregs.  Not a detail that really needs to be modelled, (does it really matter if the rover spends a day driving for 2 minutes then charging for 4 or driving for 4 minutes then charging for 8?).

On 28/10/2016 at 0:31 AM, RealGecko said:

• if your wheels consume 35% of overall power production, it means you have 65% left for other systems and you never run out of electricity
• if your rover is solar powered it will idle at night, meaning no drain by wheels at all, so only LS systems or maybe something else will drain your power and if something bad will happen BV is not involved.

So we assume that if power production is suffitient, then rover can be moved without interfering with current electric charge at all.

My suggestion doesn't involve actually draining the batteries.  It's an assumption about what is going on to determine an average speed.  If the rover is only spending half its time moving, it spends half the power and goes half as far.

The only thing my idea would do with the batteries is ask "how much power can they hold?"

On 28/10/2016 at 0:31 AM, RealGecko said:

And by the way: moving at lower speeds increase your power consumption, meanwhile moving at ~max speed wheels power drain will be near zero. Wheels consumption curve in KSP is really tricky and I don't want to overwhelm BV logic too much.

You misunderstand, my idea isn't based on having the rover drive at lower speeds but on having the rover spend less time actually driving.  Since all of that is happening in the background, it's simply easier for the mod to simply work with the average speed.

If there was a desire to make starting and stopping less efficient it could simply be done with a fudge factor, say something like (P_p/P_r)^1.2 rather than simply (P_p/P_r).

[RealGecko]

7 hours ago, Chakat Firepaw said:

If there was a desire to make starting and stopping less efficient it could simply be done with a fudge factor, say something like (P_p/P_r)^1.2 rather than simply (P_p/P_r).

Yeah, you're right, I really do not understand

[RealGecko]

20 hours ago, Melfice said:

It turns the automated rover into a deadly, deadly, dead-accurate projectile homing in on your craft.

Whoooaah! Something is changed in KSP 1.2, I tested it out and it is FUN, incoming rover hits active vessel like a NUKE

[Chakat Firepaw]

4 hours ago, RealGecko said:

Yeah, you're right, I really do not understand

Well, the simple way without the fudge factor is:  If you have half the power generation you need, you are spending half the time moving, therefore you move half as fast over the long term.

The fudge factor would be to account for the need to do things like accelerate up to speed after each stop, find safe 'parking spots', adjust position to keep solar panels exposed, etc, which means you actually spend a bit less than half the time moving.  The example I have involved raising the 'power fraction' to an exponent slightly higher than one.  Specifically, I used 1.2 as the example which would mean that having half the power would mean an average speed of just under 44% of the full power speed.

[RealGecko]

16 minutes ago, Chakat Firepaw said:

The fudge factor would be to account for the need to do things like accelerate up to speed after each stop, find safe 'parking spots', adjust position to keep solar panels exposed, etc, which means you actually spend a bit less than half the time moving ... average speed of just under 44% of the full power speed.

Yeaaaah, now I understand, exactly how it was in The Dunian The Martian

OK, but it won't be added in the next release for sure, as I need to think out this idea.

Some serious changes regarding average speed are coming:

• Serious average speed penalties at twighlight and at night time for manned rovers
• 80% speed penalty for unmanned rovers

Santa is packing gifts already

[RealGecko]

Version 0.11.0 - Massive Breakthrough

• New part, created by @Enceos - thanks, dude, it's great
• Icon is now colorized, made by Madebyoliver and licensed under Creative Commons BY 3.0
• Moved BV part to Space Exploration science node, where RoveMax Model S2 is
• Parts that can contain BV module are not hardcoded anymore - add them everywhere with MM
• Duplicate parts on the same vessel are ignored - try to guess which one is not
• Code cleanup
• KSP skin for UI available
• Dewarp done in two steps: instant to 50x and then gradual to 1x
• Solar powered rovers will idle when Sun is 0 degrees above the horizon, no more stucking at poles - yeeeeee
• Serious average speed penalties at twighlight and at night time for manned rovers - 0.25 at night, 0.50 when sun is 5 degrees above the horizon, 0.75 when 10 degrees
• Some colors in arrival report - nyā
• Added toolbar support, fixed wrapper, no Contract Configurator conflict
• Switching to vessel with interface button will go without scene reload if vessel is already loaded
• 80% speed penalty for unmanned rovers - who said it will be easy?
• UI and label are hidden if game is paused
• Label is hidden when all hidden (F2)
• Fixed crazy torpedoes nuking active vessel, rover simply won't move closer than 2400 meters to active vessel - simple and clean
• Fixed argument out of range caused sometimes and rover voyage end - yes, again
• Route visualized with red line - but it disappears sometimes
• Route always visualized for active rover if exists
• Target can be set to active navigation point - don't forget to activate navigation to that point first
• Added support for USI nuclear reactors
• Added support for NFE fission reactors - nuke your day

[Enceos]

@RealGecko Wow! So many new cool features and fixes. Time to roll my rovers to the poles!

[Enceos]

@RealGecko Love Oliver's work, but it happened that he chose pastel colors of almost exactly the same hue the toolbar uses.

[RealGecko]

58 minutes ago, Enceos said:

Love Oliver's work, but it happened that he chose pastel colors of almost exactly the same hue the toolbar uses.

Yeah, I tried to recolor icon, but failed miserably

However it looks pretty dam cool on Blizzy's Toolbar

[MAFman]

Is there a way to edit BV so that it drives my rover while I have it active, not just when I'm looking at it from the tracking station? Currently, when I tell it to go somewhere, and switch to the 'roving' rover, it just sits there with controls locked...Also, I found the pathfinding doesn't actually mark any of the tiles as unwalkable, leading to the rover going over mountains and through the ocean...

[RealGecko]

10 hours ago, MAFman said:

Is there a way to edit BV so that it drives my rover while I have it active

Mechjeb rover autopilot drives rovers in real time.

10 hours ago, MAFman said:

I found the pathfinding doesn't actually mark any of the tiles as unwalkable

If pathfinding decided that every tile is passable, routes would look like straight lines, but they're not. Read the thread, I explained how it works.

[Mikki]

@RealGecko

Great mod, this is really helpfull! I guess rover must be landed to use BV?

Edited November 19, 2016 by Mikki
typo8D