Wheffle

@Gordon Dry It looks like you have a lot of mods installed. It's very well possible that OSP is interacting badly with another mod, and it's especially suspicious since it seems to be tied to the M700 and the scanning altitude. If you can reproduce the freeze with just OSP installed, I can definitely take a look and fix it if it's just an OSP problem. If not, it's a needle in a haystack situation, but if you can reproduce it with OSP plus one other mod that might be the culprit (are you using a scaling mod? maybe that?), then I will take a look and see what I can see. The logs don't say much right before the crash, but there are no obvious errors. That's unfortunate. @Enceos To keep it within the scope of the mod (which I try to keep smallish and succinct) I would probably implement a simpler system which obscures planets that have been visited, but once they are visited by something with a functioning antenna, the obscuring overlay would be removed. I think it would be ok to have a preliminary basic terrain transmission as well, which would go ahead and unlock the resource overlays as well. However, from what Dmagic said, it seems like it would be best to implement the obscurity (?) would be to hack the scaled terrain textures, which I don't know much about or how doable it is, so it would require some research or help. As far as supporting other mods, I'll have to worry about that if and when I get the basic system in place. Sounds like a cool idea though.

This mod makes everything so beautiful and that makes me happy. I was wondering what people are doing about the stock resource overlay getting obscured by clouds (mainly on Eve). I know you can turn the clouds off with Alt + 0 (I believe), but is there a hook or anything that a modder can use to turn the clouds off automatically under certain circumstances?

@Enceos It's been proposed before, and I think it's a cool idea. Technically speaking it wouldn't be too difficult (*shouldn't be too difficult). I've held off on it for now because A) I hadn't fleshed out the original scope of my mod yet (I think it's pretty much done now, though), and B) I'm undecided on details design-wise of the implementation (like whether planets should be obscured before they are visisted or if you have to explicitly survey planets to clear the obscurity). I can always add in settings to tweak it how you like, but that's also twice as much work for me. I'm open to have a discussion about it. What do you think?

Was able to find a little bit of info on this and figure out the rest. For anyone who is interested, DMagic explains it a bit here. I'll explain what I discovered as well in case it's important to anyone: Having an antenna transmit an instance of ScienceData that has the "triggered" boolean parameter set to 'true' will trigger a callback method upon transmission completion (or failure). You can use GameEvents.OnTriggeredDataTransmission to add your method to the list of methods that will receive the callback. The callback hands you the instance of ScienceData that was sent, the vessel it was sent from and a bool that is true if the transmission failed. As far as I can tell, the R&D system will ignore a triggered ScienceData altogether, so the actual parameters of the ScienceData (amount, ID, title, etc.) don't matter, and any science added and completion messages have to be done yourself.

OSP 2.1 update - Science! Just pushed out another update. The surveyor now gathers data as it scans, which have to be transmitted back to the KSC for the overlays to be revealed. Also, you get science! Read the OP and changelog for more info. I'm not 100% sure if previous versions are compatible, but this last update is targeted at 1.1.2, so it definitely is.

Just released another little patch. Fixed some annoying bugs I missed in the last two releases, and added a bit more info to the M700's context menu (altitude parameters for scanning the current body). Check out the changelog in the OP or on Spacedock for more details.

When you scan a planet in stock with the orbital scanner, it gives you a science bonus. I would like to replicate that behavior. I've been looking into transmitting science experiments and such, but I can't really tell how the orbital scanner module is doing it. There is no experiment definition for it, and as far as I can tell you can't create and hand a transmitter ScienceData without having an ID to go with it, which you get from the ScienceSubject class, which you get from the ScienceExperiment class, which comes ultimately from the science definitions. How is the orbital scanner transmitting science without a science definition? Is it OK to build an instance of ScienceData from scratch and throw an ID in it that hasn't been defined? I suppose there could be a lot of manual overriding going on with the whole transmission process and science gaining process, but seeing as how it works with any antenna (and requires an antenna in the first place), I doubt it.

@Alshain Yikes. That's rage quit material.

To be fair, just the latest update finally made this mod passable (in my opinion). Great time to join the party Personally I do enjoy the stock system (besides the heinous abomination that is the insta-reveal stock orbital survey, which distressed me so much it drove me to straight days of frantic sleepless coding that resulted in OSP). It's definitely not perfect, and I've never used a rover to scout. That sounds painful, like just about every contract mission that seems to expect you to use a rover.

Got a small patch out that fixed some bugs that I didn't find at 4am this morning (unsurprisingly). I also added a "start survey" button so that a deployed M700 won't always be scanning no matter what. It feels a little nicer that way. That might not be a bad idea. I am planning on updating in the next few weeks or so to make the survey scanner gather science data so you don't miss out vs using the stock survey system. An option to shroud unexplored plants could be cool and I will definitely look into it!

Super duper update 2.0! With school winding down and having been playing KSP 1.1, I've been driven to the edge of madness once more. I binge-coded this update over the last couple of days, and this mod is finally what I originally envisioned it to be when I started it. Scanning now functions a lot more like SCANsat, but it is integrated (sneakily, perhaps a bit hack-ishly) with the stock resource system and its overlays. As your scanning vessel progresses in its orbit, the resource and biome overlays are revealed in real time. It's stupid late right now and I should have tested it a bit more and waited till tomorrow to push the release, but what the heck. Let me know what y'all think and if you find any bugs.

Updated for KSP 1.1. Haven't extensively tested it, but it seems to be working fine. As always, hit me up for any bugs. KerbalStuff doesn't exist anymore, and I'm too lazy to migrate to the new SpaceDock for now. I will eventually. Use Curse until then. Edit Got the spacedock link up, and apparently it should also be on CKAN once again.

Recompiled for KSP 1.1 but I didn't really test it.

Yeah, about that. I've been very busy with school and work, and finals are coming up, so I haven't had time to opt-in for the beta and sit down and figure things out. School will be ramping up until the end of April, so the best I can do is promise I will take a look after that. If anyone wants to dig in to the source code themselves, please feel free. PM me with any questions.

As far as I have tested it, it seems to work fine. (let me know if you find bugs)

So far it seems to be working in 1.0.5 as is. If anyone finds any bugs just let me know.

It's one of those quirks that I've known about for years but continue to brain fart on. I might blame it on having to use scripting languages like Matlab for classes a lot right now, or it just might be my brain being stubborn. I have a love-hate relationship with GML. My first programming was done with GML when I was young, rather sneakily teaching me some basics without me really knowing it. There's value in that. It does drive me nuts very often though. They have improved over the years though, as they now treat arrays more intelligently, and they actually have an 'undefined' data type, pointers (used with a very small set of functions related to graphics) and enums. Up an onwards! lol. Anyway, I actually got a small 2D gravity simulation working that computes the orbit all at once KSP-style and allows you to perform prograde and retrograde velocity changes. I'm using very hacky methods for producing the orbital path, so it breaks in extreme orbits (steep falls and such), but it's a start! I was surprised actually how involved the math is for orbital mechanics, which made me take some shortcuts (I guess, rocket science isn't easy?). I might go back and do it properly if I feel up to it. For anyone interested: My Janky 2D Orbital Simulator (windows)

Good eye with the bitwise operator issue. I've been using GML for a while, super brain fart there. Thanks for all the helpful replies! Edit: So yeah, with that bitwise operator mishap, looks like gravity was linear based on radius. After fixing that and tweaking my gravity constant, everything seems to be modeling correctly! The problem at its heart seemed to be the lack of inverse square law being applied.

So it was quite silly not to put any kind of code up. I apologize for that. I'm actually using Game Maker: Studio, but here's the pseudo-code: //script for getting force magnitude of gravity for a ship/planet pair public double get_gravity_force(planet, ship) { var G = 0.001; //constant I chose var x1 = planet.x; var y1 = planet.y; var x2 = ship.x; var y2 = ship.y; var r2 = (point_distance(x1, y1, x2, y2))^2; if (r2 == 0) return 0; //ignoring ship mass (G*m1*m2), this might be causing issues return (G*planet.mass/r2); } //script that runs every step for the ship //ship has local variables "x", "y", "v" and "direction" { //get gravity force magnitude and direction var fg = get_gravity_force(planet, this); var fg_dir = point_direction(x, y, planet.x, planet.y); //find x offset caused by current velocity and gravity var xx = v*(cos(direction)) + fg*cos(fg_dir)); var yy = v*(sin(direction)) + fg*sin(fg_dir)); //change direction and velocity for next step direction = point_direction(x, y, x+xx, y+yy); v = point_distance(x, y, x+xx, y+yy); //update position x = x + xx; y = y + yy; } "point_direction" and "point_distance" are provided scripts from the IDE, and the IDE actually provides scripts not used in this pseudo-code for the trigonometry, which I'm using.

So I decided on a whim to see if I could program a simple 2D model of a satellite orbiting a large body. It's very simple code that calculates the force of gravity every step on the ship and applies the force to its current velocity vector. I altered the gravity constant so that calculations wouldn't involve giant numbers and I'm also ignoring the mass of the satellite, I figured "G*m1*m2" is a constant anyway. For a relatively circular orbit, it came out looking nice: There are clearly some irregularities in the orbit. So I pushed the "ship" into an elliptical orbit, and I got this pattern: So what's causing the orbit to "flower petal" like that? Does that happen in nature? Is it a result of modeling orbits on a two dimensions vs three? Are the shortcuts from my calculations causing problems? I suppose the body itself should technically be wobbling a bit. How does KSP get around this kind of issue?

Is there a way to grab the stock resource overlay texture for a planet? I know it depends on a cutoff value, color and overlay style when it is generated, and I can't find a class that is accessible that will generate a resource overlay texture for you. I might just be missing it. I looked through SCANsat but it looks like it might be generating its own overlay textures from scratch (I think).

The mod only changes values that are already present in the .cfg files. I don't think it will break anything if you port a ship over to a vanilla install, but the values (number of sections, section height, etc.) might revert to their default values, especially if you load it up in the editor. I can't say for sure though.

You can make inter-stage fairings with stock fairings, but a lot of people don't like how they implemented it. You just put a fairing base where you want it to start, and you can end the final section by connecting it to a part above it. It's kind of wonky sometimes, and they fall apart if you're trying to do an apollo-style launch (pull the lander out of the fairings with the crew capsule).

I noticed the phantom torque/wiggling that service bays cause usually happens when parts get attached to parts outside the bay accidentally. For example, my ship wiggled and shattered to pieces because a probe core inside the bay was somehow attached to a heat shield outside the bay, instead of to the bay's floor like it looked like it was.

I'm not a very seasoned coder, and much less so in C Sharp, and even less so with KSP modding. Some systems in KSP are easy to mod and are obviously set up for modding, like part modules and such. Others seem, to my untrained eyes, locked up very tight. Specifically I'm looking into intercepting method calls from stock classes and running my own methods either before or after. I believe that's what a hook is, correct? Is this possible? More specifically, I'm trying to catch the calls that turn on the resource overlays and either modify the textures or give them new textures. I'm having a hard time finding a way to do this without doing some kind techno circus routine involving checking texture changes every game update. Thanks in advance.