[1.2.1] RoverScience Revisted (2.2.0) - Better, interactive science for rovers!

[Fobok]

KottabosGames mod reviews are definitely good. I skipped this before because, well, I can barely make landers function yet, let alone rovers. Still, after that video, I think I'm adding it to my list for 1.2. (I'm not starting my 1.2 save until final release and a number of mods are updated, though.)

[theSpeare]

4 hours ago, RB101 said:

Just to ask?

Would it be possible to make the rove brain cleanable by a high level (4 star+) scientist or engineer (at a reduced science cost?) so that it can be reused without having to build new rovers, but still having to send maintenance missions?

This would add some interaction between driving the rovers around and eva activities?

This is definitely possible, however I'm holding off until I figure out how I'm going to deal with players just slapping on an engineer/scientist and virtually making science grabs infinite. Added to the issue tracker as a potential feature. Curious: do you find that the analyzedDecay cost is a bit high? Making this cheaper might alleviate this need.

[LabRats]

An exception is preventing all types of saves (persistent, quicksave, and autosave). I've had it happen in multiple scenes, each NOT having the rover science part. In one scene there were not any wheels of any kind loaded in physics range. I have not even used the part yet. The only unloaded rover I have was made long before installing the mod.

Unfortunately, I restarted the game already and do not have the full log. I just have the related section I google'd.

If I try loading the mod again, I will try to get a full log.

[LOG 19:22:33.354] Attempting to save anomalies analyzed
[EXC 19:22:33.357] NullReferenceException: Object reference not set to an instance of an object
	RoverScience.RoverScienceScenario.saveAnomaliesAnalyzed (.ConfigNode node)
	RoverScience.RoverScienceScenario.OnSave (.ConfigNode node)
	ScenarioModule.Save (.ConfigNode node)
	ProtoScenarioModule..ctor (.ScenarioModule module)
	ScenarioRunner.GetUpdatedProtoModules ()
	Game.Updated ()
	QuickSaveLoad.doSave (System.String filename)
	QuickSaveLoad.quickSave (Boolean saveAs)
	QuickSaveLoad.Update ()

 

Also posted as an "Issue" on Github.

Love the idea of the mod.

[theSpeare]

Finally.

Update 2.1.3 - fix for NullReference thrown due to RoverScienceScenario executing save operations (and therefore trying to access RoverScience) when player did not have the roverBrain equipped on a vessel. This was gamebreaking and I've finally fixed it after some very long-winded, stupid effort.

Grab the new version here, or on CKAN:

https://github.com/theSpeare/RoverScience-Revisit/releases/tag/2.1.3

Thanks to @LabRats for bringing this to attention. I'll be doing some more testing today when I get time to make sure no other errors are thrown. I will not be doing major features until KSP 1.2 is released, as there is an annoying change in how KSP1.2 saves persistence/quicksave files that I would rather adapt to first before writing more.

Please please if you find any other major problems, report them here or on GitHub.

[DracoSilverpath]

Mod looks great! Can't wait to see it up on CKAN

[theSpeare]

Just now, DracoSilverpath said:

Mod looks great! Can't wait to see it up on CKAN

Already up on CKAN

[DracoSilverpath]

2 minutes ago, theSpeare said:

Already up on CKAN

sure about that? I just refreshed and re-started my CKAN, and its not there~ least not under 1.2 compatibility anyways...

[theSpeare]

ah right that makes sense. I'm not currently offering the 1.2 version on CKAN, sorry. I'll be waiting until the full release of KSP1.2

[Bombaatu]

Are the upgrade costs configurable? Paying 1000 Science to be able to do one additional analysis seems overly punishing to me.

[theSpeare]

10 hours ago, Bombaatu said:

Are the upgrade costs configurable? Paying 1000 Science to be able to do one additional analysis seems overly punishing to me.

At the moment they are not configurable, however this is under plans (I plan to refactor the code before adding external configuration through .cfg files and so forth.) However before then, can I get any suggestions?

With your proposal please bear in mind:

1. The upgrade works for all and future rovers. Paying 1000 for one additional analysis will work across future rovers, and that extra analysis for one or two next rovers will pay the cost off quickly.

2. The original design idea that brought about the decay limit was to encourage players to keep sending out rovers. I didn't want people to send a rover out to one body and max out on science without ever doing another rover mission.

3. I have pushed a new decay curve that's far less punishing than before: see the image here:

With these in mind can anyone suggest better values for costing? I'd really appreciate a second opinion.

Edited September 22, 2016 by theSpeare

[DracoSilverpath]

38 minutes ago, theSpeare said:

At the moment they are not configurable, however this is under plans (I plan to refactor the code before adding external configuration through .cfg files and so forth.) However before then, can I get any suggestions?

With your proposal please bear in mind:

1. The upgrade works for all and future rovers. Paying 1000 for one additional analysis will work across future rovers, and that extra analysis for one or two next rovers will pay the cost off quickly.

2. The original design idea that brought about the decay limit was to encourage players to keep sending out rovers. I didn't want people to send a rover out to one body and max out on science without ever doing another rover mission.

3. I have pushed a new decay curve that's far less punishing than before: see the image here:

With these in mind can anyone suggest better values for costing? I'd really appreciate a second opinion.

Awesome stuff there! My question would be...what is the theoretical limit on the amount of science a person could get from 1 rover, and what is the probable amount they will actually take the time to get. I assume its also body-dependent, so I'd personally factor it based on perhaps Mun and Minmus and maybe Duna. So, as an example, if the limit was say....1000 from 1 rover on Mun, then I'd likely set the 1k value to say...750 or so, giving people extra scienceif they go for the min-max, and also letting them get an upgrade in the process, while at the same time not completely punishing players for not going the absolute most-optimal route and either getting them very close to an upgrade, or getting it and just a small amount extra as incentive. I hope that makes some sort of sense....

[theSpeare]

Ah, I sort of get it. So make the upgrade cost be 75% of the total science you can get from the Mun (in this example). That way they earn enough to upgrade for future missions elsewhere AND extra, IF they min-max. I like this idea. I'm not completely sure what the maximum amount you can get off the Mun (the science values KSP use are still admittedly a bit of a mystery to me, and I use the values:

baseValue = 20000
scienceCap = 20000

for my Experiment Definition. Perhaps I'll do some debugging tonight and cheat some science values into the experiments and see what the maximum I could truly get.

Thanks for the discussion; I like this train of thought as I never intended for the upgrades to be a traditional you will get these eventually but rather as an alternative. I wanted the players to weigh the benefits - if it was a bit much for their playstyle, then I wanted it to be completely ok for them to just ignore it and send another rover elsewhere etc.

[DStaal]

One quick thought from my initial testing: If the system throws away an analysis because it doesn't think it's worth it, can we not have that count against the number of analysis it can do?  It seems a bit punishing to click 'analyze' and have it say 'sorry, no science for you - oh, and you've used up all your free chances now as well.'  Either give out a minimum 0.01 science or something, or opt those out of the total count.

[DracoSilverpath]

6 hours ago, DStaal said:

One quick thought from my initial testing: If the system throws away an analysis because it doesn't think it's worth it, can we not have that count against the number of analysis it can do?  It seems a bit punishing to click 'analyze' and have it say 'sorry, no science for you - oh, and you've used up all your free chances now as well.'  Either give out a minimum 0.01 science or something, or opt those out of the total count.

That's a good point, I think this is a good idea as well!

[karamazovnew]

Here's some food for thought, I hope this provides some ideas.

- create multiple mirrors for every biome in the game. These will not actually be on the planets, just placeholders for the stock experiments mechanic.

- each mirror would be the value of the anomaly: Very Low, Low, Normal, High, Very High. Better names would be Common, Uncommon, Valuable, Rare, Exotic (or others).

- as you roam the planet, the scanner will check not the landing position, but the place of the last experiment done in a biome (not just scanned). When the scanner creates an anomaly, instead of using diminishing returns, it will just decrease the chance to get good ones. This chance will improve as you travel further from your last experiment made. In effect, at the start, you'll find interesting rocks everywhere. But after a long time and many experiments done, it will stop be worth your time if you don't travel far away. But even so, you might still get that 1% chance to see a good rock 10 meters away from your old Mun base. 

- when you enter a hotspot, the corresponding mirror biome is revealed and you can do the actual stock (or DMagic) experiments. This means that a fully equipped rover/craft would be worth a LOT more than a cart on wheels with just a thermometer. 

- as long as the experiments for that biome are properly configured for each experiment, you can then rely on the stock mechanic of dimishing returns. For example, just measuring the pressure around the anomaly might be cool the first time, but doing the ablation experiment would be worth doing multiple times. One-time-use experiments should yield no science.  A config file would help us decide if we want 10 or 100 or 1000 high value rocks before we can consider a biome "cleared". And a science multiplier would help us decide just how much science we can get from that biome (all types of anomalies considered). Check out how Scansat does the whole partial scan data transmission.

- Data values should be kept very low for the full experiments. Otherwise, the ScienceLabs would just be even more overpowered. 

- Upgrades to the rover system should stick to the current range, prediction, but also sensitivity. Sensitivity would mean that even if the system creates 100 possible anomalies around you, you'd only be shown a few, the others would be missed by the low quality camera. Prediction and range would work as they do now.

- Distances between anomalies should be much greater and be biome dependant. This would allow you to make Icy Poles scares, while small planetoids could be quite rich. One aspect to consider is the difficulty of traversing rough terrain. Minmus's Flats for example would give you bad science, while the more dangerous Slopes would yield more. But smaller planets should yield more than large gravity ones, where your rover is harder to tip over.

- The best way to achieve this is to create a fake resource for the anomaly probability (all 5 of them). The Rover scanner would invisibly work just as a resource scanner and the percentage found would give the chance to spawn the actual anomalies. That would be an easy way to control the distance between anomalies. 

- This shouldn't be restricted to rovers (stuff with wheels). Kerbals should have this option as well, acting as a starting Rover with no upgrades. You can create a carriable (with KIS) scanner for them, or just a simple right click menu button called "Scan for shiny!". A crew report and a surface sample would be cool and a good reason to hop around the landing site instead of just launching back in 2 minutes. Of course, it shouldn't be called Rover Science then, but something like "Real Science" or "Surface Science" or whatever.

This would revolutionize the way we do missions, all of them. 

Edited September 23, 2016 by karamazovnew

[theSpeare]

@DStaal @DracoSilverpath

Great idea. I'll have it no longer add to the amount of times analyzed. Pretty quick change, so this has now been pushed to the dev branch.

 

@karamazovnew

Oh jeez! I appreciate the really long post. Most of these ideas are pretty big and will mean a massive rewrite for a lot of the code in RoverScience, so if I decide to take it on it might not be for awhile unfortunately. There are a few ideas that I would really like to take on very soon though:

1. I really like the idea of higher chance to generate big science based on distance from previously analyzed science spots. If the player wishes to find something more interesting (or more chance of finding something more interesting) they should travel far. I think it's about time I replace the current landing spot system anyway, as it doesn't really show naturally to the player and for the most part can just be ignored. I think with this I will also be increasing the surface limit so that if players decide to rocket boost to a science spot then they may. I digress though. I will explore this further and see what comes up.

2. I kinda like the idea of having science generation be affected by specific biomes. It's easy to grab biome names and to compare against them, so I might expose this as a cfg file and have biome values be affected by multiplier (for simplicity's sake).

MUN
{
body_multiplier = 1.0
  BIOMES
  {
    icyflat = 1.0
    slopes = 2.0
  }
}

Will be much easier to share different configurations too.

3. Surface Science is something I've had in the back of my mind for ages now and I planned to have it either be a separate mod or as somewhat of a significant expansion to this one. This won't be coming for awhile since I'll be focusing on polishing RoverScience before adding on this big feature.

[Identitools]

Wonderful mod, but i have one question, didn't tried it but i think this is possible to just make one big launch with TONS of rovers in it and then dispatching them on the body used to milk science. Since they are individual rovers the analysis limit is pointless.

This is a little exploity but can you confirm this is possible? Any plans to make this "not viable"?

I think of putting another analysis cap, globally and by biomes.

[theSpeare]

This is possible as far as I know but won't be attempting to block it until I come up with an acceptable solution to stop it. Thanks for bringing it up though

[DStaal]

I'm not sure that's an exploit that needs to be limited.  I mean, if we were to actually drop a swarm of rovers on Mars, we'd expect to be able to get a lot of science from that - more actually than individual rovers, since they could work together.  And if someone actually goes to the trouble of building a ship with a tons of rovers, landing it, and then piloting each one to various science points, I say more power to them for going through all that work.  They went to an extraordinary amount of effort - let them get the rewards.

[DracoSilverpath]

3 minutes ago, DStaal said:

I'm not sure that's an exploit that needs to be limited.  I mean, if we were to actually drop a swarm of rovers on Mars, we'd expect to be able to get a lot of science from that - more actually than individual rovers, since they could work together.  And if someone actually goes to the trouble of building a ship with a tons of rovers, landing it, and then piloting each one to various science points, I say more power to them for going through all that work.  They went to an extraordinary amount of effort - let them get the rewards.

I completely agree with you on this as well

[theSpeare]

@DStaal @DracoSilverpath

This is mostly why I haven't really bothered coming up with a solution for this. Thanks for the input. 

[akron]

I really hope I don't get yelled at by @theSpeare for posting this sneak preview of the new Rover Brain parts  I just couldn't wait anymore

Radial attach:

Front Attach:

EDIT: Unity Screen shot

Edited September 23, 2016 by akron

[SpaceBadger007]

23 minutes ago, akron said:

I really hope I don't get yelled at by @theSpeare for posting this sneak preview of the new Rover Brain parts  I just couldn't wait anymore

Radial attach:

Front Attach:

EDIT: Unity Screen shot

OMGOMGOMGOMGOMGOMGOMGOMG IT LOOK AMAAAAAAAAAAAAAAAAAAAAAAAAAAZING!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (whoop whoop!)

[Identitools]

What are the others strange looking parts?

[DStaal]

Most of the other parts are from Probes Plus, linked in akron's signature.  (Though IIRC, at least one is from DMagic.)

Looking really good, by the way, @akron. 

On the tons-of-tiny-rovers thing, the one other thing I'd say is that as it stands the mod does push somewhat towards that - each rover provides very limited reuse (and typically in a fairly small area, once you begin searching), so the encouragement is to send lots of disposable rovers.  Which is one of your stated goals, after all - the question is what you want to aim for, exactly.  I can see a few tweaks that would bring the time-per-rover up, meaning that huge numbers wouldn't be as desirable, if you want.  It's all a balance question.

Regardless, this mod makes sending an automated rover vs an automated probe a more balanced (at the very least) question.  In stock, it's almost never worth sending a rover without a couple of Kerbals.