theSpeare

Once you upgrade, every rover (future, past and present) will carry the upgrade. This is for KSP 1.1.3.

Update 2.1.4 - New part models (and textures) by @akron New part models Model and texturing by KSPForum akron. Wonderful work and wonderful guy. Thanks! The old placeholder is now removed, please take care with your currently deployed rovers. MiniAVC Implementation Added MiniAVC support. Will compare with GitHub pushed version file. Initial Minor Balancing Pass Changed so that amount of times analyzed does not increase for generated science that is too low. There will be more balancing to come as discussion continues in the forum page. EDIT: front page has been updated with new images showing off these parts

@DStaal Science Spots that are generated far away from your rover have a distance bonus multiplier. This simply means that driving to Science Spots far away will be rewarding, however since it's only a multiplier you might just be getting multiplying a small value (this is where prediction comes in handy). Another benefit to range adjustment is being able to adapt to any terrain (perhaps you're in a small crater, or next to a steep slope). I think this one is my fault; I haven't really emphasized this on the readme. Maybe I'll just have it written down on the RoverScience console. @DracoSilverpath I kinda like this idea. I might use this as inspiration and implement something similar. Thanks for the idea. I think in general I need to make the prediction accuracy upgrade way more interactive.

@akron how dare you! Nah it's perfectly fine, you have every right to show off the beautiful parts you made. How is the orientation work coming along? As soon as that's done I'm gonna tweak the costs and other part values and then release it immediately with the latest dev branch. @DStaal I don't really mind so much. If players are gonna put in the effort to send fleets of rovers then that's great. At the moment RoverScience already makes far more science per rover (three analyses can return quite a bit of science right?) than any traditional probe by itself; which is, i think, a great incentive to actually send rovers. In stock there's almost zero practical use for rovers rather than just landing probes as you have mentioned. Again in terms of balance it's not really at the top of my list; I'm far more concerned with the current upgrade costs, and if the upgrades are actually effective/worth-it for players who prefer that play style. I imagine at the moment prediction accuracy should be the most sought-out upgrade. The mod was designed with risk/decision-making in mind so that every time a spot comes up (especially when it's distant), you look at the prediction and you think: "hmm... is it going to be worth it driving all the way there?" I think I need a better system for prediction though. At the moment if you have 60% prediction confidence, the mod will just do a random roll and if you hit 60% the prediction will read what the actual potential is. Here's the could-be-better part: if you fail the 60% roll check, you will get a random prediction. I made this with the intention of misleading the player if they had low prediction confidence, but at the moment it feels more of a static mechanic rather than a dynamic interactive one. Any ideas? Hi, sorry i missed a page while writing a reply. CTRL+R+S is a little bit finicky at the moment but it helps if you press down those keys in that order. (CTRL then R then S). Then it should work. I will be adding a button to the game's stock toolbar (which will appear only if you have the part). For the time being you may also assign the roverBrain to a custom action. This is pretty much why I was a little bit disappointed when the stock science system first came out. The whole biome thing is neat but felt very mechanical and not very interesting by itself. I thought about how much I liked building unmanned rovers and got upset that there really was no need for actual rovers, but just probes. Cue RoverScience! I hope I've accomplished some ways of making rovers actually viable (interesting).

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

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 @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.

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.

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.

Alright, this helps a lot. Thanks @hab136 and @Sigma88

@hab136 oh neat, thank you for the detailed explanation. So the version files I will need are: 1. One inside my packaged release zip file 2. One somewhere in my GitHub repo, for miniAVC to check against. Furthermore, if I work exclusively on my master branch, I should publish my zip file FIRST, then push to Github with the new version file. (Or as you recommended, work on a dev branch first, which I should probably be doing anyway). In that case my version file should look something like this: { "NAME":"RoverScience", "URL":"https://github.com/theSpeare/RoverScience-Revisit/RoverScience.version", "DOWNLOAD":"https://github.com/theSpeare/RoverScience-Revisit/releases", "VERSION": { "MAJOR":2, "MINOR":1, "PATCH":3, "BUILD":0 }, "KSP_VERSION": { "MAJOR":1, "MINOR":1, "PATCH":3 } } (out of curiosity, what can the GitHub implementation do?)

How does miniAVC compare against the latest GitHub release if it's packaged within a zip file? Will I have to adopt a specific tag naming system?

Forgive me for dumb questions: so the GitHub feature for MiniAVC can automatically detect new packaged releases? If so, then MiniAVC would just be one-time initial setup, e.g. no constant maintenance of the version file every time I push a release?

Hey, I might have missed this somewhere but is there a way I can just have MiniAVC check my mod version via SpaceDock?

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

Already up on CKAN

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.

Thank you Nah, it was in reference to this: Apparently GetComponent calls are no longer free (if I understand correctly) and every call will create a new reference which will pile up over time. Arsonide developed a way of caching the call to save resources. I still have to do this on my plugin; need to get around to doing it and testing that nothing's broken. Let me know how yours goes.

@neitsa great job! Just a note on your GetComponent calls; apparently it's no longer free in KSP1.1+ as mentioned here: I'm still guilty of this, but just thought it could come in handy for you

Is this with 1.2 or 1.1?

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.

KSP 1.2 Pre-release compatibility. https://github.com/theSpeare/RoverScience-Revisit/releases/tag/2.2.0-B1 I've made some progress on compatibility. The plugin seems to be working fine so I pushed this "patch" really quickly to get RoverScience compatible with 1.2-pre. Some rewriting had to be done to readjust to the some new KSP quirks. I haven't tested it thoroughly so please be careful with your saves. Please please please report any problems that you encounter and include your output_log.txt. EDIT: CKAN integration should be complete soon (but will only work for 1.1.3). I will not bother with CKAN integration for KSP 1.2 until the pre-release is over. For those who want pre-release versions of RoverScience, please follow the GitHub release page.

I came over to post my source, but it looks like you already got the idea! Let me know if I can help you. From the looks of things it's the probably the positioning that's the issue. dw though, if udk_lethal_d0se is helping you, you're in good hands.

Update 2.1.2 GUI Polish & New Upgrade Type Made GUI prettier. Now with colours and revised text to improve understandability. Added new upgrade: "analyzedDecay". Upgrading this will increase the number of times a player may analyze before suffering science loss. Quickloading and quicksaving will now restore window positions. GUI position and display status is now saved in persistence & quicksave. Updated mod page. Much cleaner explanation of this mod, with new updated images. As usual any feedback / feature requests appreciated. Thank you to everyone for supporting and staying with me while I update this mod You guys make it worth it.

Updated to 2.1! https://github.com/theSpeare/RoverScience-Revisit/releases/ Interesting Rocks Rock models are now spawned at Science Spots. Two different models are included; more will be added later. Credit to udk_lethal_dose for the idea. Textures are a bit big; will look at compressing these further. Anomalies Anomalies are now recognized! Credit to etmoonshade for the idea. ScienceSpots will generate at anomalies once rovers are within 100m and no other scienceSpots are active. Anomalies provide a flat 300 science points (500, if you're lucky). However you can only analyze an anomaly ONCE. Most anomalies have been charted, except for two Duna ones that do not appear above ground anymore. Go send your rovers out to those anomalies!