theSpeare

Hi, thank you so much for your feedback! 1. The cooldown has been removed since pre-release 2. It is now replaced by a system that reduces the science gain PER analysis that you do (From 0-3 analyses it does not decay.). 2. This is VERY weird. I'm assuming it's because the value that's been put into AddData() was just off or something. Can you please send your KSP.log that's in your installation folder? 3. It looks like you analyzed a science spot on Kerbin. The reduction factor for Kerbin science is VERY high. Try sending your rover out to the Mun. Pretty much anywhere not-Kerbin. That's probably why #2 occurred - because the value must have been way too low, or something like that. I've added a limit now, where if the data is below 0.1, the data isn't allowed in and the data is scrapped. 4. The minimum distance for a science spot is 25 meters, and the maximum is 75. Do you think 25 is way too close? I'll raise it to 40 and raise maximum to 90.

Cheers! I really appreciate it. Don't hesitate to give any feedback

Pre-release 3 complete, pushed to Github. OP updated with the new pre-release download link. Changelog as follows: This is the last pre-release (unless some major issues pop up) so I'm gonna need the help I can get! Let me know what you think so far, especially if there's anything that feels particularly broken or horrible. Thank you guys so much again, I wouldn't be releasing a plugin I'm happy with without you guys.

I've been a little busy but alas, I am in the progress of completing issue #19. Shouldn't take too long. I've made a few changes with the science/potential curve and left the analysis decay curve alone. I will hopefully be letting out pre-release 3 by tonight. After, I'll just let you guys send the last bit of feedback to see if everything is going okay, and then I can release fully to the showcase forum and up into SpacePort for proper packaging without all the source file mumbo-jumbo. Last stretch guys, thanks so much for the help!

Never occurred to me to compile it actually, I just assumed it was all right to begin with. Come to think of it now, I don't see how .ToString() would be doing better than (string) in this situation :S I'll just download your fix since it seems NathanKell hasn't uploaded your fix yet Cheers to stupid_chris as well

Still having problems. But I noticed something - if I took off my parachutes the problem would no longer occur. I have RealChutes, and after looking at isShielded() method I'm beginning to believe it IS RealChutes. The (string) cast must be the problem? public bool IsShielded(Vector3 direction) { if ((object)parachute != null) { ModuleParachute p = parachute; if(p.deploymentState == ModuleParachute.deploymentStates.DEPLOYED || p.deploymentState == ModuleParachute.deploymentStates.SEMIDEPLOYED) return false; } if ((object)realChute != null) { string mainDeployState = (string)rCType.GetField("depState").GetValue(realChute); string secDeployState = (string)rCType.GetField("secDepState").GetValue(realChute); if ((mainDeployState + secDeployState).Contains("DEPLOYED")) // LOW, PRE, or just DEPLOYED return false; } Ray ray = new Ray(part.transform.position + direction.normalized * adjustCollider, direction.normalized); RaycastHit[] hits = Physics.RaycastAll (ray, 10); foreach (RaycastHit hit in hits) { if(hit.rigidbody != null && hit.collider != part.collider) { return true; } } return false; } EDIT: So yeah, it WAS the (string) cast that was making problems. I really don't know why it seems like I'm the only one suffering this problem. I switched (string)rCType.GetField("depState").GetValue(realChute); For example, to: rCType.GetField("depState").GetValue(realChute).ToString(); and it solved my problem. No more exceptions being thrown. Let me know if I've opened another problem with this solution, please, NathanKell.

Hey, I started seeing an InvalidCastException just being thrown non-stop on my way out of the atmosphere, and checking the output_log I found this: InvalidCastException: Cannot cast from source type to destination type. at DeadlyReentry.ModuleAeroReentry.IsShielded (Vector3 direction) [0x00000] in <filename unknown>:0 at DeadlyReentry.ModuleAeroReentry.ReentryHeat (Vector3 velocity) [0x00000] in <filename unknown>:0 at DeadlyReentry.ModuleAeroReentry.FixedUpdate () [0x00000] in <filename unknown>:0 Any ideas? Plugins installed: Toolbar JSI RPM ALCOR ForceIVA Engineer EnhancedNavBall Ferram KJR MCE Final Frontier StretchyTank RealChute 6S

Ah yes, it's very possible to do so. Thanks Ralathon. The only thing you have to worry about is the orientation of your hullcam part, because it may not point forward as its UP orientation. If it does, then that's great, but otherwise you're gonna have to use another command part that points forward, otherwise the heading is going to be messed up.

Still not sure what you mean, sorry :S Bobcat rovers I'm guessing don't use ModuleWheel which means at this moment they don't. I will try to go for compatibility after release, as it shouldn't be too hard as long as they have a "groundcontact" bool I can use.

Cheers, the monitor view thing might not be a thing I'd want to go in. I'd prefer to actually draw maybe glowing spheres on the map that designate the science points. But that'll only come when I decide to go with the feature of spawning more than one science spot at a time. At the moment (see milestone Pre-release 3) I will just be working on GUI touch-ups, balancing of the science values returned (just a bit lower again), and then once pre-release 3 is tested fine by me and you guys, I shall do an official release. Thank you so much for your help I might not be able to get pre-release 3 out tonight, but maybe tomorrow instead. Stay tuned.

Sure thing! Can you please clarify what you are having trouble with? Are you just unable to analyze at all, etc? The readme is here and it should answer a few questions if you feel like reading through it. Otherwise, here's the brief explanation for how to use the plugin: To do science with a rover, you must have a vessel with at least one wheel in contact with the ground. Wherever you land first with your wheels will establish a landing spot. Science is analyzed from science spots. To find a science spot you simply have to drive around. However, the farther you are from the landing spot the higher the chance of finding a science spot. Once a science spot has been found, the terminal will show the distance and bearing to the spot; heading and rel. heading will be shown as well. Simply drive to the spot (within 3m) and information will be shown about the spot. Once you are above the spot, you can just press analyze, and then if you're happy with the potential science, click confirm. If you're having trouble getting to the spot itself, make sure you orient the Rover Brain part properly such that the pointy protrusion on the model points FORWARD. Once you want to begin driving around, simply "control from here" with the rover part's right-click, or you can press the "reorient" button on the GUI. For a better demonstration for how the part should be oriented, please look at the readme as it contains pictures. Thank you

Alright, I'll play around with those values. Cheers. EDIT: I'll try pushing out another release tonight

How often are you finding the 2% "very high" spots? From my testing I've found 14% ones a little too frequently, so in this case I might leave the 2% and lower the 14% to maybe 7%, and that will probably take care of it. Perhaps even change the "normal" to a little lower, that way the normal potential becomes even more favorable if you're not up for travelling extra distances. Yeah, I'm keen to release soon as this pre-release development stage isn't really getting much feedback. I'd just like to get the balance to somewhere where it sounds sensible and then later fight over about the values. At the moment I guess my primary concern is functionality - if it's bug free, easy to set up and understand, and somewhat balanced, then it's going to be released! Much thanks for your detailed feedback.

Added as issue #18 Added as issue#19 Thanks for this. I was just gonna keep it as "TURN LEFT" and "TURN RIGHT" as a simplification thing for the code (lazy) but now that there's someone who actually requests it I don't have an excuse! This should be renamed to "Total dist. traveled searching for next spot". It's an intended behavior. I wanted to represent how long someone's driven for one spot, rather than in total for the entire mission. Issue #20 At the moment I'm not too fussed on trying to figure this out. Before implementation of something like this I'd have to spend a day or two with design brainstorm/solution before jumping into this. Something like this large enough that it'll have to be a future feature. Right now I'm considering this as a "well, you love to build rovers, so here's another reason to use them over other science solutions". Definitely. This is one of the things that I need most help with. Here's the issue which is very open to discussion. Right now the percentages are: 2% (400, 700); 14% (150, 400); 45% (70, 150); 70% (20, 70); else (0, 10); And the scalar values to reduce these are: Kerbin: 0.01 Sun: 0 Mun: 0.3 Minmus: 0.2 default: 1 For example, at 14% chance, the maximum science to be received from the Mun would be 400*0.3 = 120. It'd be 210 at the very highest (only 2% chance). This HOWEVER does not take into account the amount of times you can analyze! This means, with an unhindered science output over three analyses (before it begins to decay) the maximum you'd get from 14% would be 360 science. This is a little crazy, but there's a little bit of a struggle here for me: That 14% is something I'd ideally know as "difficult to get"; those high potential spots don't come up all the time, but you can keep driving to get them if you're really that motivated. Which is where my stance comes in: if the player is willing to drive repeatedly over and over again to really soak up those high potentials, then are they not deserving of that high science output? And I mean high, I don't mean an extra 10% science or so. Something that's really worth the effort. So the question for balancing, at least in my perspective, is should the 14% or 2% chance be changed for balancing? Maybe it's too easy to find that 14% high potential spots? The only way my perspective would hold true is if that high potential spot is sufficiently difficult enough to get, and the normal potentials are very common. Cheers so much for your feedback, it helps immensely. I currently have very little to work with, and I'm hesitant to release until the balancing is done.

Alright, I can probably fit an extra "GUI" button. I'll add it in as a future feature as it's not something I'm overly concerned about. What I really need are playtesters so I can push this out for full release.

The 'must be in orbit' is just for resetting the rover's penalties on excessive analyses. When I implement it, you can still grab its data, slap it on a lab and boost it (hopefully) for transmission. The only behavior I want to change is the ability for the rover brain part to be cleaned (probably automatic since I can't seem to touch the lab API for my purposes). But this is farther down the line anyway. Thank you very much! It'd help a lot if you playtest with the latest pre-release and give me feedback (and bug reports). Preferably on the github page so it's easier to track, but here's just as great.

Someone suggested this idea as well. I may do this but instead do it where the science spots just start spawning at a higher minimum distance each time. Thoughts on this and on the current system?

GitHub has been updated and there is Pre-release 2 is now up. Here is the summary: Huzzah! Analysis delay has been deleted; which means you no longer have to wait after every analysis. Now you can analyse to your heart's content - but be careful as the more you analyze, the less you'll get each time. The science returned is modified by a scalar which remains at 1 for the first three attempts, and everything after that will start to experience a decay. Moved part techRequired to fieldScience where the first rover wheels appear. If you install this version you must unlock that node! It's the same node that contains the rover wheels so make sure you check, click the Rover Brain part and research it. The other changes are not so important; just a few things moved here and about. P.S. Kudos to Rockstar04 for the discussion under issue #11, helping abolish the analysis delay. Also thanks to Horus at KSP forums for active testing.

@Horus Cheers, really appreciate the help and feedback. The 30 day rover lock is going to be changed and pretty much removed. Essentially the new system will be where the science you get will be reduced each time you analyze. This way you have to really make sure you get those high values before analyzing, because eventually you'll be getting close to 0 values! In the future I may combine this with a science lab so you can clean it, but you must be in orbit. It's a little out of the way for a rover to dock, but it's a challenge if you REALLY want to reuse your rover. This means I can keep the science cap at around 1500~2000, but you still won't be able to get it all without sending another rover and such. I don't want to necessarily halt rover movement completely, but I may do a "percentage until done" thing. That's neat, but it'll be coming as a post-release feature as that's a bit more aesthetic than functional. @SaplingPick To my knowledge there are only two GUI textures. The one I'm using now is the one that I remember mechjeb uses a lot. I could switch to the KER style where it's not really transparent. The problem with this is that since the rover terminal could potentially take up such a large portion of the screen, I'd like it to be a little see-through rather than just a block. If you have any suggestions for which GUI skin I can use, I'd be glad to look it up.

Is there a global "time" value? Something like MET but instead as a more universal clock that would have started when you started your game. Seems a lot more reliable than MET for some things. EDIT: Did some poking around and found Planetarium.GetUniversalTime ();

Hi, your first issue has already been fixed in the latest commit. It'll be in the next pre-release. Essentially what's happening is you can't analyze because there's a time you have to wait between analysis times. Since the variable holding the "time since last release" was initiated as 0, if you've never analyzed before (as in, first launching a vehicle), then a check of "current MET" - "previous time" != 30 days. If that makes sense. It's been fixed anyway, but the problem is the time delay check won't change at all if the MET hasn't started yet (no launch detected yet). For now you can fix this by simply timewarping full runs down to 0. Note the message on the terminal "Must wait until next analysis can be made". The second bit doesn't make much sense. The total distance calculated doesn't really play into anything with the science though - it's just a neat thing I like to show the player. I'm not sure though why it's not working for you. Maybe just wait until the next release. Please upload your .craft file though so I can test it. Also by science gap if you mean the analyze delay then no, it's locked per vessel. So yeah, technically you can send a crapload of rovers to the same spot and analyze the crap out of the land but you'll be driving each one of them anyway. Later I'll be adding a body-locked delay to prevent this exploit. Please let me know how you find the mod after these issues and likewise sorry about them in the first place. I'll try to get an update out asap.

I don't think it'd be a problem. RoverScience uses its own part "Rover Brain" which appears on the first node of the tech tree. I'm just reusing the stock models because I'm still developing my own. Not entirely sure what you mean?

Cheers. Guys, any feedback would be appreciated, especially with how it plays. I may revise the analyze cooldown and replace it with a "maximum x times analyze use before very very long cooldown" method instead. 'x' can probably then be upgraded with science. I think this is a better solution and will be less of a "grinding" method. This way the player will have, say, "five" attempts to get as much science as he can from a surface. He can either choose to go with "normal" values or really push for those high end values - but that's to their dedication.

Yeah, these screenshots are a little outdated - those numbers are already rounded off and bearings are rounded to one decimal place. Not exactly sure how many hours it is as I'm working off MET. It's not THAT long if you just timewarp through it, but it's enough to make you hesitate before analyzing straight away.

ALPHA PRE-RELEASE RoverScience is a KSP plugin that attempts to add more interactive functionality to the science system FOR rovers. The rover can be either manned, or unmanned (the former will be revised eventually). Firstly, RoverScience will not function unless the Rover Terminal is opened. This is done through the right-click menu of the Rover Brain part. To do science with a rover, you must have a vessel with at least one wheel in contact with the ground. Wherever you land first with your wheels will establish a landing spot. Science is analyzed from science spots. To find a science spot you simply have to drive around; however, the farther you are from the landing spot the higher the chance of finding a science spot. Once a science spot has been found, the terminal will show the distance and bearing to the spot; heading and rel. heading will be shown as well. Simply drive to the spot (within 3m) and information will be shown about the spot. Please avoid using more than one RoverBrain on the same vessel! This is not supported yet - a very rough method has been used to prevent spamming of this part. For more information check the readme (little outdated). There's a lot of important little bits to remember, so please read the bottom half of it. This is a pre-release intended for playtesting. Feedback is greatly appreciated. The plugin is more or less almost finished; it just requires some balancing and then new features can come in the future. Installation Instructions: Please download the latest pre-release. Just hit the green button that says "RoverScience-pX.X.rar - no more downloading the entire source! DOWNLOAD HERE Source code on Github Please submit issues to github page. Much thanks to the community of KSP modders, who have been very patient, very kind and very helpful. This is my first major C# project and I'm still learning. The code may be messy in some places and I apologize. But nothing will ever describe my gratitude to those who helped - particularly malkuth, whose inbox I have no doubt spammed with questions. This is a wonderful community, and I thank you all once again. This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.