technogeeky

I won't lie and say I'm going as fast as I can, but I am going as fast as I can modulo real life and my weekend attempt to rescue stranded Kerbals. I'm switching to dev environment right now and will get to work!

This could be used for (rotational) station-keeping for scanning and communication satellites, could it not? You do not need the blessing of OP to contribute (if it is open source). You may or may not need the blessing of OP to take over the project. I may have a direct interest as the maintainer of SCANsat, but only if this can afford SCANsat some benefit (in terms of demanding more realistic requirements of scanning vessels). I didn't even know this existed until you bumped today.

Your appreciation has been noted and will be forwarded to the relevant authorities.

In the words of Capt. Jean-Luc Picard: Made it so.

I was worried about the line endings. I am totally happy to switch back to Windows line endings uniformly. I have three possible settings: Always Unix, Always Windows, and Leave As Is. As long as I don't use Leave As Is (which is what I was doing), I'm happy. So since that's a trivial thing to me, and it will make your life easier, I will uniformly move to Windows line endings in my next master.

Aha! I didn't see this before I responded. Perhaps I am vindicated (though, perhaps not). I haven't ever tried multiple vessel scanning. Shame on me!

I don't mind being wrong. I may be the future maintainer of SCANsat, but I am certainly not the author and more than 50% of the code has never seen my eyes. And I will switch back to my dev environment tonight, so I will check the code myself. And the following may be wrong, but I want to be sure I say what I mean to say carefully: 1.) In order to take advantage of background scanning, your active vessel must have some type of SCANsat sensor on it (even if it's just MapTraq). I relent and submit this statement instead of the previous one (which is weaker than my previous statement that the active vessel must have the same kind of scanner on it). I say this because I don't see a way for any of the SCANsat code to run when the active vessel is not even loading SCANsat in the first place. As for #2, I think you are probably right re: background vessels and resource consumption. I do know that the active vessel must have enough charge to survive the draining of the batteries; otherwise, SCANsat starts to display static on top of the small map (I'm not sure if the battery must be empty or nearly so, but I have seen the static happen when I forgot to deploy my panels). I do not really doubt that I'm wrong, and I started playing KSP about three or four days before 0.23.5 came out, so I don't have any base of experience on prior versions. Regardless of the above, I again ask: which version of SCANsat are you talking about? I presume from your lack including that information that you are using the latest official release (v5) and not my (v6rc). The only change that I'm aware of is that vessels can now be SpaceObjects (which did not exist prior to 0.23.5). I'm not sure why this would break anything related to multiple vessel scanning, but I will check tonight.

DMagic: Can we sync whatever is necessary to get both of us developing from the same master (ie, mine)? I presume that will mean adding back whatever is necessary to the .csproj and .sln files for you to build. I also converted everything to Unix-like line endings, and I think such a change will persist normally. You mentioned that you didn't expect to be able to debug and/or profile with ksp-devtools and Visual Studio, but I think you should be able to (without Professional, even). The worst case scenario is that you would have to use MonoDevelop for such things (which is a pretty bad case). But I was able to get profiling results (which I'm told actually do represent complete time intervals, and not just number of function calls -- modulo the RTDSC inaccuracies and recursive functions). And I was able to get the debugger working, and to add breakpoints and watches. I also want to do something to automate a few other processes (though I'm unsure exactly how to do them, but I think it's a good idea): 1. The building of the "first post" for the module, including re-building it for updated versions 2. The inclusion and appropriate copying/installation/removal of an example scanning vessel and several savegames/scenarios that needed to be tested. I have spoken with Pshwan (the original creator of the scanner calculator that I am working on simultaneously) and we tend to agree on a minimal set of scanning scenarios that need to be tested to ensure that both SCANsat and the calculator are working correctly. I believe that these would be included with the developmental version, copied to the appropriate places as long as you are building the Debug version (as opposed to the Release version), and removed afterwards. 3. Using those (or perhaps different) savegames to build / harvest / upload screenshots that would naturally be included in #1. That way, I can avoid the outcome that SCANsat (and other mods) fall victim to: having out of date screenshots which do not represent the full glory of the current mod version. 4. Get a Jenkins CI buildbot going, so users can see what development is going on (especially since you are a more prolific SCANsat developer than I am, at this point) and decide for themselves if they want to get dev versions. As for what I'd ask you to do most urgently... Either: 1.) Change your .csproj and/or .sln files so that you are building from Source *in place* OR at least change the target of your build to be GameData\SCANsat itself (ie, where SCANsat.dll goes). The default for me was ${ProjectDir}\build. As long as I have disabled "Local Copy" (which simply seems to copy all of the .dll files that are required to build SCANsat to that build directory), this setting would be almost perfectly valid -- even if "in place" means what it does for me: Kerbal Space Program\GameData\SCANsat\Source\build Except that this requires a post-build hook which copies SCANsat.dll to: Kerbal Space Program\GameData\SCANsat And then a second hook which deletes: Kerbal Space Program\GameData\SCANsat\Source\build\SCANsat.dll I don't like running any post-build hooks if I can avoid it, but I really don't like running ones which delete files. I'm OK with the ones which copy the .txt files (and soon, all of the images, models, textures, and config files). I'm OK with having two versions: one with xcopy for Windows, one with plain old cp for Linux. I'm sure some other hooks will be necessary to get my above list going smoothly, too. 2.) OR simply destroy/rebase/rebuild your copies of SCANsat with my latest one; modify my latest .csproj and .sln files to fit your desired deployment configuration (so I can clearly see your choices and don't make mistakes manipulating paths), and I will merge them into the master (either as they are, if possible, or under Windows Debug / Windows Release). I will note that it seems to be mandatory that I have the target directory of the SCANsat project (but not necessarily the .sln) be my GameData\SCANsat folder for debugging to work. I haven't tried symlinks for this scenario (though I suspect they would work) -- but I don't even know if I know enough Windows junction to setup a similar situation in Windows. You are the more experienced developer here, so tell me what I should/shouldn't do and what I can change to be most correct. But I would really like to be able to directly use git to directly import your code and changes (like, for example, your bigmap caching attempts). So far, I have done everything manually because of differences in these things (and in differences in Line endings). (Another reason for me doing things manually is because some of your changes were whitespace-only changes that despite all my attempts did not fall out the diffs.) Thanks, tg

This feels a little bit crass to ask, but MechJeb is the only example I know of: Did you guys write (or follow an existing) tutorial on getting a KSP addon to build in Jenkins? It looks like you are self-hosting a copy of Jenkins. Was this necessary to build, or can the (free?) hosted version of Jenkins handle the build? Thanks!

He means you do not want to have two different ModuleManager DLLs anywhere in your GameData folders. This could happen because you have two versions of MM in the same location: GameData\ModuleManager_1_5_6.dll GameData\ModuleManager_2_0_3.dll Or you could install some mod which includes module manager, and does not "properly" install it in GameData: GameData\SomeModThatRequiresMM\ModuleManager_1_5_6.dll GameData\ModuleManager_1_5_6.dll However: do not worry too much about this. I am almost certain that ModuleManager (of any recent version) detects when multiple copies of itself have been loaded and it warns you (at the Main Menu screen).

Also, in the name of correctness, you may wish to add two options to the poll in this thread: 1) I am a first-time ALCOR user with v0.8, but it seems responsive enough for me! 2) I am a first-time ALCOR user with v0.8, but it is not responsive enough for me.

It is possible, given the height-disadvantaged nature of our Kerbal brethren, that it should instead say PERSONAL STAFFS. Presumably any older Kerbal will need some assistance walking about on planetary EVAs; and perhaps they expect such staffs (I'm sure this should be staves) to break often -- so clearly an ample supply is needed. Then again, your suggestion does seem a great deal simpler.

I have also studied fractals in a very shallow and general sense; and, for a particular fractal and its associates (the Apollonian gasket and the associated mathematics -- see the pretty awesome set of papers by Lagarias (et. al.) ), in a very detailed and thorough sense. I like Haskell for similar-ish reasons. It's not necessarily easy to get started (it's not, in general). It's not necessarily easy to produce working output (still not, usually -- unless you adopt some haskell idiom for doing things). But when you get something working and it appears correct, the typesystem usually ensures that it is so. And because of the strength and flexibility of the type system, these assurances of correctness (proofs, even, in some case) survive refactoring. I challenge anyone to find a language which provides stronger support for retaining correctness in the face of refactoring. But I'll try out the plots and try to learn to love Octave. It will probably be a few days before I publish my code, but I intend to re-release your software package with my "improvements" (namely, improvement of the process of loading data from tables for planets; including and loading data for scanners (and now I know to use something just under 2.25 for the FOV of the Kethane scanners); some adjustments to the printed table; some commenting; removal of all the unused code). Thanks for all of your help.

In what way does it not work? As I understand it (I haven't made the test for this yet, lazily...) all you need is: 1. At least two vessels with the same kind of scanner around the same mainBody. 2. Both need to have the scanners active, and have enough resources (battery/solar) to sustain them for the desired time warp. So assuming you fulfill these basic requirements, it should work. Which KSP (I assume 0.23.5) and which SCANsat version (I assume v5 or v6rc) are you using?

Luckily, I am already familiar with quaternions (and not just their application to rotations in space). Though I doubt we'll see any performance increase. I'll be sure to enable caching of the big map, where possible. I don't understand the decision to cache the small map but not the big map. There is a strange mix of re-use for both maps, and differences for both maps. It must be for hysterical raisins. I also intend to break up drawing the map into the grid shown by Grid, and drawing each box individually (including a partial scanline, or something that looks good). That way, I can avoid re-drawing the majority of the map and just re-draw the components where active vessels have made changes. I also hope to make the red scanline go in both directions, maybe. Depending on the current direction of motion (towards the descending or ascending node). Thanks for taking a look at it for me. I hadn't gotten that far yet. I still need to rescue a few Kerbin from the Mun before I switch my development install back in.

I think the best solution for drawing Orbits in general, is to divide up the current function into two (one which draws orbits, one which draws the equatorial crossings). Then I can leave the default (read: small, not FOV proportional ) orbital tracks for the *vessels* themselves, and then overlay/underlay FOV tracks of significantly less opacity with FOV-proportional sized orbital tracks, for every available active scanner. This is necessary because they don't have similar FOVs.

You can essentially ignore these: these are just screenshot dumps of variations on the theme of seeing more orbits. I want to delete them from my computer, so they go here: http://imgur.com/a/1uh1O#0 Feel free to say if you like the look of any. Two of them includes experimental Solarized coloration, which I did incorrectly.

Or for the Moon, to make sure you are in a frozen orbit! It's a good thing that the Apollo astronauts didn't need to stay in orbit for months, because their orbits would have probably decayed! I did not get tripped up by it. My current favorite language is Haskell, so I'm used to being very careful with operators lest the compiler shout type errors at me! No, and you should! This leads me to a question: There are lots of parts which are commented out. In my code, for sake of clarity, I indented all of the blocks-of-commented-out-code with ~ 120 spaces to get it out of the picture. I intend to delete it all, at some point. Are there any blocks I should save? (Aside from the plotting code, which I'll speak about below). Yes. For the SAR scanner and Mun (which is one of my current favorite test cases), there are no good orbits, only less bad orbits. Yes, I might, if I am feeling frisky, not ask for a sidelap input and instead estimate a good tradeoff between sidelap and shorter total time. I would only do this after I have a good match between the calculator and the scanners, though. Like proton decay large? I don't want mapping to take several times the age of the universe, thank you. I was thinking to build a scanner which has two probe scanners mounted on it. Eject them, have them burn to ~ 5 km away in either direction, and enable. I don't know how to describe that in terms of what I could put in the calculator, but it's the only thought I had in terms of being a faster result with a single launch. The calculator currently doesn't ever seem to suggest 90 degree orbits (at least not for me, so far). I saw that it has some commented out code related to that. There is, of course, the advantage that the less-inclined orbits seem to have shorter total scan times. (Even accounting for the missing cup/cap of the poles). I find myself in that situation a lot. I'm still not sure if it's good or bad. You could just run the calculation at several different numerical resolutions, and then use some sort of gaussian fit to try and find orbits which have the same paramaters at all the numerical resolutions specified. Then you could report the high-numerical resolution result but accompany it with the corresponding low-resolution margin of error. Question mark. I think that should end with a question mark. I haven't enabled any plotting of anything at all yet! I don't even know if it works. I'm using Octave, not Matlab. I wonder if you expect it to work. I can actually think of a counter-example. In my case (for testing), I use HyperEdit. I will put in the orbital altitude first, which puts you in the right altitude but over the equator. Then I click a different tab, and change the incliation. However, I've noticed that you have to wait for the orbit to "settle down" before you change the inclination. I'll notice that the inclination will be exactly 0 for a moment, then fall down to some small 1e-5 value. Only after that settles, do I change the inclination. However, The SMA is on the same tab as the inclination, so if I have: (sma, inclination, eccentricity = 0) I may be able to input the orbits for testing faster. This reminds me to ask you a question (since I haven't ever even visited a planetoid other than Kerbin/Mun/Minmus yet.. I only got this game a few weeks ago): What set of bodies form an ideal basis for testing (both of this tool, and SCANsat), and why? I know that I need to figure out which body can take advantage of the code at the bottom of MapSatAltitude (Single Pass Polar), and make sure I test that. I also guess that Kerbin (and any bodies larger than Kerbin) are a special case (currently) in SCANsat becuase of the 'surface scale' bonus. Not to mention it's a starting planet. Don't want to get those wrong! I also guess Gilly (for its small SOI) and I suppose Jool (if we ever have scanners that can get something from it) for its large SOI. I guess Moho because of its slow rotation, and Eeloo for its fast rotation. Maybe Duna or Laythe for its mid-height atmosphere. As for RSS, I would guess Earth (same reason as Kerbin), the Moon (to compare SCANsat maps to real moon maps), Uranus (retrograde motion and axis tilted), Venus (retrograde motion without tilt). But then I'm worried about changes in planets for updates, and changes in RSS for updates, and people who aren't even using RSS or stock planets at all. The kind of numerical simulation that we are doing seems like exactly the kind of thing one might choose to run in a seperate thread in KSP. I know most plugin developers opt not to try this, but it shouldn't be hard to serialize a few basic facts about the planetary bodies in the game, pass them into a seperate thread, run a simulation, and pass the results back. OK. We'll see. I should have some time to figure it out. Your code has been easier to figure out so far, but then again, it is simpler in some regards. This might be a cheap way to improve the ability of low-FOV scanners. Simply remind the user that they are side-scanning so they probably want to mount two of them to their craft! Thanks!

Can a moderator please move this thread to Tools and Applications? I put this in development, because I'm developing it... And maybe, one day it will be part of a plug-in. But for now, the code is in Matlab/Octave so it doesn't really belong in here.

I don't know yet either. I don't know yet. I very quickly learned to not worry about the intention of feature requests. I sorted the TODO.txt that came with v5 of SCANsat. I moved this item here, and that item there. I read every line and wondered what they were asking for. Then I read some line about changing sea level and how some guy's wife liked a pink Mun, but he didn't. I laughed at that request, assuming I would never do it. Later that night, it was the first "new" feature I actually implemented and left in the code. . So I'll take the lists in stride, try to understand the code quickly, and get to improving it.

I'm not sure I totally follow what you are asking, but I can give you the facts as I know them: 1) No matter what you choose for FOV, the settings in the .dll will never allow it to be higher than 20*. 2) You can just set the best altitude to exactly the minimum altitude, so everything above it will get the best FOV possible. 3) You can set the maximum altitude to whatever you want. 1,500 km should do. I think you should be able to "unify" them (I take this to mean that you are adjusting all four sensors to have the same values -- not that you want to have one sensor only).

That was indeed the problem. When I selected the 'debug' release, I would get an error that looks like: Error CS1902: Invalid debug option `+'. Valid options are `full' or `pdbonly' (CS1902) (TAG) For that reason, I had simply been avoiding Debug. Comparing Debug and Release, I noticed that the "Emit Debugging Symbols" box was checked. So I unchecked that box and instead put -debug:full in the additional options field. Whala, breakpoints work (and SCANsat.dll.mdb suddenly appears!). Some follow up questions, then: 1) If I really want to be able to "Watch" (haven't done this yet) anything (and not just things in my .DLL file), shouldn't I need to generate mdb files for several other DLLs and/or EXEs? If so, what is the strategy here? Should I uncheck "Local Copy" long enough to get MDBs, put them in the same directories as the files they represent in the KSP tree? 2) Is turning on "enable optimizations" going to destroy the utility of profiling or debugging? (Before I try both)? Thanks again for your patience. Yes, I tried to follow the instructions down to the letter but evidently my setup is a little bit more buggy.

My build directory is currently: Kerbal Space Program/GameData/SCANsat/. For the DLL part. For the executable part, it's whatever is default. What is an mdb file? There are PDB files that appear to be needed for win32 only. MDB seems to be associated with the mono debugger from naive searches, but I don't know what that is yet. I just ran the debugger now, and I do not see anything other than the intended DLL in GameData/SCANsat. edit: This might be related to me not using the "Debug" configuration while building, because it gives me an error every time. Perhaps I should fix that. I suspect there must be a box somewhere that I haven't checked in the release version. Like emit debugging symbols. That's what pdb and mdb are, after all, I gather.

Interesting. I'm not sure I think it's better looking than the other ones, but that's not for me to decide. Here are the parameters for the original SCANsat satellites: Name FOV HalfFOV AltitudeMin AltitudeIdeal AltitudeMax LongName RADAR 5.00 2.50 5000.00 5000.00 500000.00 SCAN RADAR Altimetry Sensor Multi 4.00 2.00 5000.00 250000.00 500000.00 SCAN Multispectral Sensor SAR 2.00 1.00 5000.00 750000.00 800000.00 SCAN SAR Altimetry Sensor However, it clearly has totally different height profile: MODULE { name = SCANsat sensorType = 24 Altimetry + Biome fov = 4 min_alt = 5000 max_alt = 12000000 best_alt = 750000 power = 3.5 } MODULE { name = SCANsat sensorType = 1 [B]RADAR[/B] fov = 4 (down from [B]5[/B]) min_alt = 5000 max_alt = 12000000 (up from [B]500000[/B]) best_alt = 750000 (up from [B]5000[/B]) power = 0.1 } MODULE { name = SCANsat sensorType = 2 [B]SAR[/B] fov = 4 (up from [B]2[/B]) min_alt = 5000 max_alt = 12000000 (up from [B]800k[/B]) best_alt = 750000 power = 1 } Hmm...

OK. OK. OK. I have thought about the "supersampling" technique that the B.O.S.S. (something something something screenshot) uses. I wonder if that technique is amenable to this kind of thing. I suppose I already have several text field boxes (all integers so far, as it turns out) that I would need to add. I suppose two more wouldn't hurt. OK. Whoa, whoa, whoa! I'm not a supergenius. Just kidding. I don't really even know where to begin on that one. The other four I can wrap my head around. OK. They seem like reasonable feature requests.