Psawhn

Yeah, I've been trying to follow the RP-0 configs. Thank you for pointing me to them. Is there any explanation of what the individual variables do, aside from digging into the code itself on GitHub? I think I've got "cost" and "baseCostPV' figured out, but "costPerkL" and "baseCost" still leave me baffled, and I'm not sure in what contexts ModuleManager will use "volume" properly. Is there a way to get RF to increase the cost of tanks based on their dry mass? Because, so far, I'm still getting the situation where tanks are pretty much free, aside from the piddly little amount of propellant I have to pay for. It feels pretty cheaty.

I've been trying to fiddle around with modulemanager configs to adjust prices, but I'm afraid I don't know enough about how Real Fuels and Procedural Parts manage prices to accomplish want I want to do. I can set the price for stock tanks individually, but I don't know how to set the prices on procedural tanks by their capacity without also affecting everything with ModuleFuelTanks like said stock fuel tanks, solid rocket motors, TAC-LS tanks, et cetera. My goals for adjusting price are: 1. Fuel tank prices must be more expensive than the equivalent worth of their weight in scrap metal. 2. Fuel tank prices should be within an order of magnitude of a reasonably-priced equivalent sized non-tank structural or aerodynamic part. 4. Fuel tank prices must be less expensive than a reasonably-priced engine they'd be expected to feed. I've been assuming that propellant prices are negligibly cheap, and thus aren't a factor. Currently, Procedural fuel tanks violate #1 and #2, as they have no price at all except for their propellant. Most stock fuel tanks violate #3, as they are expensive -- the Mainsail is half the price of the Jumbo-64 orange fuel tank! I think the importance of the first goal is self-evident, and the second goal is to provide a bit of plausible fidelity and remove the incentive to make the entire craft out of empty fuel tanks. The third point is the real important one. Without it, dense fuels like kerolox become the only economical option, as the financial cost of adding extra tanks more than outweighs any possible savings gained by increased efficiency. It also makes makes Nuclear Thermal rockets pretty much worthless when attempting to use Liquid Hydrogen, as the equivalent delta-v in kerolox or hypergolics costs much less in funds despite the huge mass penalty. Any advice?

Yeah. I was just about to ask if Career mode isn't supported by Real Fuels outside of Realism Overhaul plus RP-0. If it isn't, I think that'd be important information for users to know.

I don't mind that propellants have very low costs. Even still, that procedural tank itself costs only 1.5 funds, so by your conversion ratio it's $26,500 USD (1965) worth of hydrogen stuffed into a $1,500 USD (1965) hydrogen tank. You just described the propellants as being dirt cheap, so I don't think it's correct that the tank is less than 6% the cost of the propellant. (And if the propellant is dirt cheap, I can only describe the tank cost as loose change.) On the other hand, a stock Jumbo-64 tank costs $12.8 million USD in 1965 dollars (Or $95.6 million in 2014 dollars) at 12,800 funds. At least the tank:propellant cost ratio is in the correct direction that time . I don't know what the realistic cost for tanks should be, but it must be somewhere in the middle between rounding error and new F-16. I'll look at RP-0 for prices on engines and tanks and see if there's a scaling factor I can apply to stock fuel tanks.

Well, you're right, $28 is a lot more than $0. Actually, is Real Fuels supposed to modify the cost of tanks? Because currently the prices for tanks are completely unadjusted from stock. I'm finding that the tanks themselves are often more expensive than the engines, to the point that dense fuels like kerolox are invariably much more cost-effective than choices like hydrolox. For example, a Jumbo-64 fuel tank costs twice as much as a Mainsail, so using the lowest volume of fuel possible (and thus the fewest number of fuel tanks) becomes the key consideration. I'm currently using the stockalike pack, but with all the prices commented out because it was making all the engines even cheaper than stock and exacerbating this problem. However, I skimmed the module manager .cfgs in the RFTS pack and it doesn't appear to modify tank or engine prices either. I haven't touched Realism Overhaul, however I expect it probably wouldn't have this problem because it will have had a careful balance pass for all masses and costs.

I'm going off of what actually gets scanned in-game. I'll zoom into to a new swath that's scanning, mouse over the left and right edges of the swath, note their longitudes, then find the difference. I guess what's going on is that SCANsat uses these values for both left and right, effectively doubling ground coverage. I think it also rounds up only on the west side and always truncates on the east side, so coverage will go up by ones, not twos. Ah. Sounds good. In-game, it appears RAR has a resolution of 1x1 degree. The more I think about it, the more I think that it doesn't actually correspond to any physical value. Or, if it does, it corresponds more to beat frequency or something very unintuitive when thinking about satellite coverage. Whatever it is, I think it's safe to throw away that value and ignore it . (Hurray that's another column to get rid of and save space!)

Sorry I haven't been able to pop in for a little bit. I'm amazed to see the work you've done. I've tested out some of the orbits, and they appear to be working just as well as can be expected! That's really the hard part, making sure the swath width per altitude and orbit slotting code works. I only have a few tiny nitpicks. The FOV values shown appear to be the half-FOV. On Kerbin, I get ~10 degrees of longitude coverage for RAR, ~8 deg for Multi, and ~5 deg for SAR. (When they're at optimal scanner altitude) I still disagree with the term FOV (Field of View) to refer to ground coverage. Swath width should refer to the ground coverage of the entire swath. So, for a multispectral scanner on Kerbin with ground coverage of 8 degrees of longitude, swath width should be 83.767 km. I don't know where the 3-4 m values are coming from. Because SCANsat works differently than Mapsat, the resolution fields are incorrect and may not even be necessary. From what I understand, RAR uses 1x1 degree cells, Multi is locked to the resolution of the internal biome map, and SAR is arbitrarily high, correct? Or, you can get rid of the resolution value in degrees, and just fix the resolution value in metres. The EAQx field may also not be needed. I'm still not sure what physical value it represents, and so is confusing and not useful for the end-user.

I've read that this was supposed to be fixed in KSPI 0.11, but IR Telescopes still don't appear to be generating science while unfocused in version 0.11. I just tested with a new installation with only stock and WarpPlugin to eliminate mod effects. I've tried both the Deep-Field Survey and the G-Lensing observations. In both 0.5 sci/day and 15 sci/day modes, science accumulates in the persistence files while the vessel is focused, as expected. However, if I let several days elapse in the tracking station then return to the vessel, no science is accumulated in the persistence file. On the other hand, the cryostats are not losing liquid helium to cook-off while unfocused, either. Science labs appear to be fine. After time warping in the tracking station then focusing on the vessel, the message pops up with how much science is added and the persistence file changes properly.

Thanks for replying. I'm sure you've gotten tired of having to repeatedly explain the limitations of the current system with respect to Apollo-style missions . Although I didn't realize that MCE was already able to track multiple concurrent missions, so thank you for explaining that. Your tagging system is exactly what I was trying to get at with my proposal. And I fully agree that it's a daunting task, especially with 0.24 looming over the horizon. Again, thanks for your time.

Sorry to double-post and keep spamming up your thread like this, but I just finished collating up the data. So I just looked up some satellites that I already knew by name, plus a few more I didn't know about, and collected their statistics. I tried to go for some with the widest swath widths, because resolution in the game isn't too high anyway. While looking these up, I discovered that there's something called Interferometric SAR, which uses multiple passes to generate maps of surface deformation. Reading from the wikipedia link: It'd be funny if SAR required multiple passes in order to generate a DEM in the first place, but that'd probably be much too convoluted a process for most players. But you said that you were interested in tandem-vessel experiments, so I thought it'd be neat to bring it up. [TABLE=width: 890] [TR] [TD]Satellite[/TD] [TD]Link[/TD] [TD]Inclination[/TD] [TD]Altitude[/TD] [TD]Period[/TD] [TD] Swath Width[/TD] [TD]Resolution[/TD] [TD]Antenna[/TD] [/TR] [TR] [TD=colspan: 2]Synthetic Aperture RADAR[/TD] [TD][/TD] [TD](km)[/TD] [TD](mins)[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]ERS-2[/TD] [TD]https://directory.eoportal.org/web/eoportal/satellite-missions/e/ers-2[/TD] [TD]98.516 98.543 98.491[/TD] [TD]785 782 770[/TD] [TD]~100[/TD] [TD]100 km[/TD] [TD]30m[/TD] [TD]325.8 kg[/TD] [/TR] [TR] [TD]RADARSAT 1 and 2[/TD] [TD]http://www.asc-csa.gc.ca/eng/satellites/radarsat/radarsat-tableau.asp http://en.wikipedia.org/wiki/Radarsat-2[/TD] [TD=align: right]98.6[/TD] [TD=align: right]798[/TD] [TD=align: right]100.75[/TD] [TD]500 km[/TD] [TD]100 m[/TD] [TD]750 kg, 15m x 1.5m[/TD] [/TR] [TR] [TD]RADARSAT Constellation[/TD] [TD][/TD] [TD=align: right]97.74[/TD] [TD=align: right]592.7[/TD] [TD=align: right]96.4[/TD] [TD]500 km[/TD] [TD]100 m[/TD] [TD]400kg, 6.75m x 1.38 m[/TD] [/TR] [TR] [TD]ENVISAT[/TD] [TD]https://earth.esa.int/web/guest/missions/esa-operational-eo-missions/envisat/instruments/asar http://en.wikipedia.org/wiki/Envisat[/TD] [TD=align: right]98.4[/TD] [TD=align: right]773[/TD] [TD=align: right]100.16[/TD] [TD]405 km[/TD] [TD]150 m[/TD] [TD][/TD] [/TR] [TR] [TD]TerraSAR-X[/TD] [TD]https://directory.eoportal.org/web/eoportal/satellite-missions/t/terrasar-x[/TD] [TD=align: right]97.44[/TD] [TD=align: right]514.8[/TD] [TD][/TD] [TD]200 km[/TD] [TD]35 m[/TD] [TD]5m x 2.4m[/TD] [/TR] [TR] [TD]Multispectral[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]LANDSAT 5/7/8[/TD] [TD]http://geo.arc.nasa.gov/sge/landsat/l7.html http://landsat.usgs.gov/about_landsat5.php[/TD] [TD=align: right]98.22[/TD] [TD=align: right]705[/TD] [TD=align: right]98.83[/TD] [TD]185 km[/TD] [TD]30 m[/TD] [TD][/TD] [/TR] [TR] [TD]IRS-3[/TD] [TD]https://directory.eoportal.org/web/eoportal/satellite-missions/i/irs-p3[/TD] [TD=align: right]98.7[/TD] [TD=align: right]817[/TD] [TD=align: right]101.35[/TD] [TD]770km / 200km[/TD] [TD=colspan: 2]188 m / 520 m[/TD] [/TR] [TR] [TD]kompsat-1[/TD] [TD]https://directory.eoportal.org/web/eoportal/satellite-missions/k/kompsat-1[/TD] [TD=align: right]98.13[/TD] [TD=align: right]685[/TD] [TD=align: right]98.46[/TD] [TD]17 km / 800 km[/TD] [TD]6.6m / 1 km[/TD] [TD][/TD] [/TR] [/TABLE] All of these satellites are in sun-synchronous orbits, which is why their inclinations are at about 98 degrees (retrograde). It's pretty important for EO satellites to take images at the same solar time of day each pass (typically about 9:30 AM to 10:00 AM). I think it might also allow them to remain in constant sunlight to keep the solar panels charged, having just enough altitude to reach sunlight while travelling over the night side at 10 PM. This cannot be replicated in KSP because orbits around non-spherical masses are not modelled.

That sounds like a good plan. I'd be worried about the uncertainty of electric generation. Solar panel geometry, extra generators like KSPI's or Kethane's, or extra sinks like RT2 antennas, complicate the solution. Personally, I don't mind the assumption that unfocused vessels have enough generators/batteries to last through the nights just because the alternative is such a potential mess. If you'd like, I can summarize some of the stats for some of the real Earth-Observation satellites. Mostly just leave the swath width, then offset that. The neat thing is that it shouldn't affect time-to-scan or trying to line up sidelaps or coverage, because it'll just shift the coverage to one side. The only exception may be the poles -- one pole will have better coverage than the other unless antenna direction is switched. Those are pretty cool. Although, by the looks of it, RBSP is also finding data with respect to time, not just volume, which is why it's using multiple vessels. Funny thing about GRAIL, it might actually be a replacement for the Gravioli detector. We don't have a sensor in real life that can directly measure gravity fields, only the acceleration caused by gravity fields. When I'd first heard about how GRAIL works, I thought it was pretty cool, too, but the math must be crazy. Well, luckily that method only has to project backwards .

Which is fair. I realized shortly after posting that the box fill gives the buffer for higher time warps. Plus, the effects not being noticeable is a relevant point. I'd still think having SAR scan only to one side would be an interesting concession to reality. Although, thinking about it, there's already orbit prediction code in place, right? It's used to draw the orbit tracks. I wonder if it's possible to repurpose it to update the map by interpolating updates on scanning knowledge between its last known position and its current position. That may not be a bad idea for a long-term goal. Not only should this allow for arbitrarily large time-warps, but also for unfocused scanning around SOIs other than the current body.

That looks amazing! Back when ISA_Mapsat was a thing, I'd have to manually use GIS to overlay Kethane maps onto height maps to find good landing sites. Having SCANsat do that is an incredibly useful tool. On the subject, though, I'd be wary of duplicating or even obsoleting scanning functionality of existing mods like Kethane. I think I'd read that Majir has specific design goals in mind for Kethane, and the reason he hasn't implemented unfocused scanning on his own is that he still wants electric charge power management to be an important factor in Kethane scanning. Implementing a SCANsat Kethane scanner that can scan at higher time warps without focus on the vessel... oh and it can scan in a 45 degree cone for less electric charge... that's a bit rude, now, ain't it? Is it too early to talk about possible changes in SCANsat's FOV mechanics for v8 (or later) yet? . Personally, I'd think it'd be amazing if the SAR and Multispectral scanners had similar behaviour and swath widths under RSS as real systems like LANDSAT and RADARSAT have in real-life. In addition, ideally each sensor type would have its own scanning behaviour. RAR (real-aperture RADAR) would work as it does now, scanning in a box around the vessel's position to represent manually steering it in two directions. Multispectral would scan in a line perpendicularly to its ground travel to represent a Scanning or Pushbroom style radiometer. Finally, SAR would scan perpendicularly to the direction of travel, but only to one side (and not directly underneath) because of how synthetic-aperture RADAR works. I think that'd be a fun concession to realism that'd make GIS nerds like me or RSS gurus like NathanKell happy .

If you run the Octave.exe directly it should pop up with its own command window, I think. At least that's how mine's set up. You can resize both this window (and any windows command window) by clicking on the top-left icon, then selecting Properties, then adjusting the sizes in the Layout tab. (Don't double-click the top-left icon, as that will close any windows program just like pressing the X button.) My screen buffer is set to 120x5000, and my window size is 120x60. (You can also change the font and colors, in case the defaults don't suit your fancy)

After I used KSP's revert option too often and lost all my money, I edited my persistence save file to change the lines CanRestart and CanLeaveToEditor to False, which completely removed the option to revert flight. This left Mission Controller's revert as the only way to reset, ensuring I couldn't accidentally throw away money. Is this something you'd be able to include in Mission Controller by default? ========== I've also been mulling over the oft-discussed problem, where Apollo-style landers can't complete objectives because they have different vessel IDs, which is primarily a problem due to the data model, right? It's probably not worth the effort with contracts and budgets coming in the next stock KSP, but would changing the data model potentially solve this problem? The system I've got in mind is described as this: -Vessels have a reference to point to a mission. (Instead of the current system, which is the other way around) -Multiple vessels can share the same mission. -Each vessel can only have a single mission assigned. -Missions are "infectious": docking or decoupling will spread the mission to all affected vessels. -- In case of a conflict of missions (docking to a vessel with a different mission assigned), one mission must be overwritten either automatically or by player choice. -Vessels store knowledge of which goals it has completed, which is also infectious. (To help prevent exploits) -The mission also stores knowledge of sub-goals and mission completion. (For garbage cleanup of completed missions and to also prevent exploits) I think there are two very clear advantages to such a system. Firstly, it allows more complicated mission profiles. Apollo-style missions with a separate lander are feasible. As are even more complicated profiles: For example, an SSTO Spaceplane can lift off from Kerbin, dock with an orbital hub in low orbit, which spreads the mission to a nuclear Munar shuttle which then heads to the Mun, the shuttle docks with a station in Munar orbit and spreads the mission to a lander, which lands on the Mun and completes the mission. Secondly, this should better allow for concurrent missions. It would allow players to continue their space program while a probe is en route to Eve on a 6-month Rockomax contract, for example. The main disadvantage is that the system must be made more complicate in order to prevent exploits or bugs. In the SSTO-example, suppose the final goal was to take off from the Mun and land on Kerbin. The player shouldn't be allowed to simply switch to the SSTO craft and land it immediately after the Mun landing without any flight back. Or for the case of optional goals which yield more money, the player shouldn't be able to repeat the same goal with dozens of sub-craft (or even debris!) for completing the optional goal multiple times. In addition, both the space stations and the Nuclear Kerbin-Mun shuttle will have residual pointers to the mission even after it's completed, so the mission should store its completion state in order for garbage cleanup to remove the old reference the next time focus is assigned to these vessels. I have absolutely no expectation that you'd incorporate these changes into the mod ("Hey, I'm new here, but I'm going to tell you to change your entire back-end data model!" ), but I'm more curious what your thoughts on this kind of system would be. No disrespect to any of your work intended. The development and maintenance of mods like these represent a significant investment of effort, and I've already enjoyed the mod significantly.

Sorry, I don't mean using an actual camera or remote-viewing type mod. I keep getting confused because of the repeated use of terms like Field-of-View and these lines of code: S1 = ((alts+R).*cot(hFOV)+sqrt(R.^2.*cot(hFOV).^2-alts.^2-2.*alts.*R))./(1+cot(hFOV).^2); S2 = ((alts+R).*cot(hFOV)-sqrt(R.^2.*cot(hFOV).^2-alts.^2-2.*alts.*R))./(1+cot(hFOV).^2); S = min([S1;S2]); swathWidths = (asin(S./R)*2)/pi*180; I haven't mathed it out, but due to the heavy trigonometry I'd guess this code calculates the footprint of a projected FOV onto a sphere? ie: if you have a camera with a certain field-of-view, what can the camera see at various altitudes? Unless SCANsat sensors are actually using a field of view as if they were a camera (and I don't think they are), I think FOV is a misleading term to use. It find it extremely confusing when field-of-view is used to describe instantaneous ground coverage. I've always used the term swath width for that (And even then, I usually mean swath width in units of degrees of longitude at the equator).

I want to say I've recently picked up this mod, and I'm quite enjoying it. While you're at it, would it be unreasonable to suggest a check be added for either a probe core or manned command pod for auto-recycling using powered landings? It seemed a little silly that spent return stages would get recycled just because it had an engine and a tiny amount of leftover fuel. (Or, going further, requiring research to unlock the ability to auto-recycle using powered landings?)

Ah. Yes, I agree that getting SCANsat released had a much higher priority. Nice job on that! I think the current code actually calculates the swath width as a projection of the field of view onto the surface of a sphere? If that's true, then amusingly enough I think it's a better model than the current SCANsat code. However, I suppose discussion of changing the FOV models should be moved to your v8 development thread, once you put it up? It's designed to work with Octave, which is already free, so that's functionally equivalent to requiring someone to download the MatLab Compiler Runtime. I haven't looked into it too much, but I believe this link: http://stackoverflow.com/questions/3843522/how-do-i-create-a-simple-octave-distributable-without-installing-octave explains a method to turn octave code into a simple distributable, which is an even better solution. If neither of those solutions work out, though, I believe rewriting the code in another language wouldn't be too arduous an undertaking, although we'd need a volunteer for it .

Hey, Technogeeky. I'm sorry to have to say this, but I believe that the swath width calculations are incorrect. For example, in-game, the low-res RADAR sensor appears to have a swath width of 10.4 degrees of latitude no matter its altitude. I'll try out the Mun and Minmus soon, but I'm just running Career mode so it may take a little while to get set up. I think that the SCANSat sensor FOVs given aren't actually field-of-view as seen from a camera, but nominal ground coverage in degrees longitude. That would make sense for the RADAR sensor, as it would have a swath width of 2x5.00 deg = 10 deg for all altitudes above its best altitude, which gets rounded to 10.4 degrees in-game due to pixel shenanigans. The decimal place may even be dependent on the Big Map's window size. I suspect this may account for some of your discrepancies between estimated and actual times-to-scan, as well. If the actual swath width is wider than calculated, scans may complete on earlier orbits due to overlapping sidelaps. If the actual swath width is smaller than calculated, more orbits may be needed, or permanent gaps in the coverage may pop up.

Swath width of 2.25, not FOV. A constant field of view will cause an increase in swath width with increasing altitude, but Kethane scanners only scan the cell directly underneath them, which are 2.25 degrees of longitude wide at the equator. Funnily enough, an orbit with exactly 2.25 swath width and 0% sidelap shouldn't have any scanning between two Kethane grid, because of the exactness. But the calculator isn't set up to give you that (a new program with an analytical solution would be needed), and close enough is close enough anyway, so I never mind having a few missed vertical strips in my Kethane maps. Nice job with the release of SCANsat v6, guys! I'm looking forward to playing with it in my games!

I don't think I included a license more restrictive than an MIT license, and I may have just released it into the public domain in the first place. It's looking pretty good! Thank you so much for continuing on with the tool. It looks so much cleaner than my hacked out version. Some comments: Does SCANsat actually model the projection of a camera field of view onto the sphere? If so, that's pretty neat (and also explains why I couldn't get the calculator to work when I tried). I like that much better than ISA Mapsat's function, which could give some odd results when altitude >> planet radius. Also, keep in mind that Kethane scanners don't have a FOV of 2.25 degrees, they have a ground "swath width" of 2.25 degrees of longitude, regardless of altitude. I forgot to mention earlier that the numerical resolution/precision was only one way of increasing the granularity. If RSS Earth and Moon are giving troubles, then shrinking alt_stepsize increases the altitude-wise resolution. I tried to include some scaling to factor in planet size, and increasing numerical precision also introduced a factor to pick lower stepsizes between altitude slices -- which is why using Very or Ultra high resolution was needed for RSS. It's a tradeoff, because longer array sizes obviously mean that the program takes much more time to calculate. Most of that commented-out code is obsolete and can safely be deleted. Most of it was obsolete when you got it. A few lines were specific to ISA Mapsat (like the polynomial functions) but are obsolete for SCAN sat. The only exception might be the plotting code. The same applies for variables that are calculated then never used. Possibly the most glaring example of this is code related to swath width. It took me many tries to fit the right function, and I didn't want to ever delete my work in case I had to go back and try again. As SCANsat is different, you can delete all the code if you'd like. Yep, max_width is in degrees. Because of the way ISA calculated ground coverage, there was a possibility that for very high altitudes and very small bodies, ground coverage would be more than 180 degrees of longitude. That doesn't make sense from a physical standpoint, so I hardcoded a limit. The altitude at which this occurs is about maxSwathAlt. Neither of those variables are needed with SCANsat and your improvements. The minimum altitude of 10 km was hardcoded because ISA Mapsat had no minimum altitude, and on-rails time warp doesn't work below 10 km. Again, nice job maintaining it! It's already a lot better than I could have made it.

Well, the tricky thing with Octave/Matlab is they're interpreted language which are designed for linear algebra, and operators like * wouldn't be invalid because of variable type, but because of dimensions. For example: > 2*2 ans = 4 > [1 2] * 2 ans = 2 4 > [1 2] * [2 4] error: operator *: nonconformant arguments (op1 is 1x2, op2 is 1x2) > [1 2]' * [2 4] ans = 2 4 4 8 > [1 2] * [2 4]' ans = 10 > [1 2] .* [2 4] ans = 2 8 The easy vectorization and parallelization actually makes Octave my go-to choice if I need to math up some numbers, tables, or graphs, rather than Excel. No. That's just my lazy way of doing poor man's SVN. I think every bit of code that's commented out can safely be deleted. Sidelap is actually a pretty important factor in real-world photogrammetry and satellite mapping, so I like being able to have some control over which sidelap I choose even if it's only a concession to realism. Yeah, sending two probes on one launch would work. The problem with trying to develop a calculator for such a situation, though, is that there is no single "solution" to the case of two satellites. The interactions become pretty complicated, and you need to ask a specific question in order to get a specific answer -- and asking the question in the first place needs a decent solid understanding of the orbital mechanics involved. For example, suppose the case where I'd want to use two satellites to scan a planet in half the time. I'd pick the same inclination because otherwise I might get tiny slivers of no coverage that are hard to predict. I'd also pick the same orbit, each satellite with the same SMA and sidereal LAN. The orbits should completely overlap in the map view, with the only difference being phase (position in the orbit). This lets me launch both vessels on the same rocket and use only the tiniest bit of delta-v to shift them around. The next choice is if I want to use a single scanning path with each vessel scanning 180 degrees out of phase with respect to the entire scan time (tricky to calculate!), or two complementary orbits with half-size swath widths. The second case is much simpler to calculate, because I can just ask the Octave calculator tool to give me orbits with sidelaps of 0.5 to 0.6. I'd then launch both vehicles to orbit on one rocket, then split off the second probe and boost it into a slightly higher orbit. Then I just watch the scanning map until the second satellite is scanning an adjacent swath to the first, then I'll drop it back down into the same orbit. Voila! Two mapping satellites to map the same planet and halve scan time. It mathematically can't suggest 90 degree orbits. tgtInclination = acosd(orbitalPeriods./planetDay); Inclination will only be 90 if orbital period is zero. If I understand it properly, swath width is constant if the sensor altitude is greater than "best altitude?" That means the relationship is actually the other way around: lower orbits reduce scan time because of a higher frequency of equatorial crossing points, and the higher orbital velocity also pushes the angle needed to match horizontal velocity at the equator closer to 90 degrees. The controlling factor for if low or higher orbits are better is how swath width responds to altitude. Constant swath widths like RADAR or Kethane mean that the best altitudes are very low because more orbits decrease scan time. Sensors with high responsitivity to altitude, like ISA_Mapsat, mean that higher altitudes are better because wide swaths decrease the number of orbits needed for a total scan. I'm leaning towards finding the rule for what calculated sidelaps are still valid. It's a quantization problem involving fractals. Because the underlying functions are discontinuous (and erratically so), functions trying to fit for continuous data won't work well. It works just fine in Octave? I'm actually using Octave myself and wrote these tools in Octave, not Matlab, because I don't own a license for Matlab. Unless you're doing really high-end stuff like system simulations or fluid dynamics simulations or an entire mission planner and GUI, there's not much you can do in Matlab that you can't in Octave. Just try it! You can even enter the following in the command window: >x = 1:10 >y = x.^2 >plot(x,y) The easy plotting is why Octave is my go-to environment for trying to test out math. It's really easy to intuit mathematical relationships when I can tweak formulae and instantly see how the graph responds. I wouldn't have been able to write the ideal orbit calculator in any other language simply because I wouldn't have been able to figure out the math behind it. Gilly is actually the only body I found that qualifies for Single Pass Polar. For SPP, orbital period has to be several times longer than the body's rotation period. For every other body, the altitude needed for an SPP is higher than the sensors' maximum range, or even outside the planet's SOI. Kerbin, Mun, and Minmus are probably the most important test cases. Kerbin's a good "average" planet and probably the most common subject of mapping satellites. The Mun and Minmus are the most-visited bodies, and are good examples of slow rotation and fast rotation. Tylo/Moho have very slow rotations, so are good test subjects for that extreme. And Gilly has a very fast rotation compared to its gravity, so it's the other extreme. I think only rocky worlds are really important for this tool. Gas giants don't really have a surface to study, and their clouds are always changing so there's no permanent structures to map out. Not to mean you can't do science on them via remote sensing -- just look at Cassini or Gallileo! -- but it's so different from ground observation missions like Landsat or Radarsat that I don't think a mod like SCANsat is the best thing for it. Yeah, Earth, Moon, Venus, Mars, probably. Maybe also Titan. Uranus, as a gas giant, doesn't really have much to offer via SCANsat, and axial tilt isn't possible in KSP anyway. Even if it was, it'd just mean that a polar orbit is with respect to the planet's rotation. As an side, it'd be fun if sensor parameters were tweaked so that, in RSS, SCANsat satellites could replicated Earth Observation satellites like Landsat or Radarsat. (For example, Landsat 7 has an altitude of 705 km and swath width of 185 km.) Yeah, that's a good point. That's a funny difference between real life and KSP. In real life, adding a second RADAR antenna would be anything but cheap because you'd probably have to double the mass of the entire spacecraft. (Second heavy antenna, doubled power generation, and more complicated signal processing to avoid interference.) In KSP it's just as simple as clicking a second part .

Before it was abandoned a few versions ago, ISA_Mapsat was neat because you could use it to generate heightmaps of any resolution you chose, assuming you had the disk space and patience for it. But it was harder to use, and abandoned so, yeah, it'll crash unless you use KSP 0.18 or 0.20 at most. I'm not in the remote sensing industry, but I'd think that 'in real life' sensors obviously have a field-of-view composing an angle from the sensor, which causes ground coverage to be dependent on flight altitude, and the spacecraft can slew its sensors to better cover gaps and to provide revisit capabilities. On top of that, I'm sure many other factors go into designing a remote sensing mission, one of the more important probably being a careful choice of orbit altitude and inclination to take advantage of Earth's non-spherical gravity well to create a sun-synchronous orbit. Heh. Not only that, but everything is a matrix! (of which an array is just an 1xn case). You've probably figured it out the hard way, but it still catches me when I accidentally use the * and / operators instead of the .* and ./ operators. (The .* and ./ are element-wise multiplication and division, but when * and / are fed arrays or matrices it attempts to do a matrix multiplication or division.) Have I apologized yet for calculating variables that end up never getting used? Planet rotation is accounted for in the line "orbitRats = orbitalPeriods./planetDay;". I think planetRotPerPeriod is leftover when I was still trying to figure out the underlying math in the first place, but it's pretty useless now. Yep. It does nicely solve another problem, though: What altitudes should I avoid because their low resonance means I can never scan the entire planet? Oh, I forgot one more: You can pick an orbit with better sidelap coverage. I think 25% sidelap would eliminate all mid-latitude gaps. 50% Sidelap most definitely will. On the other hand, 50% sidelap also scans the entire planet about 50% slower. Luckily, even a mere 10% sidelap will work in some cases. Yeah. It depends on some kind of resonance + spherical trigonometry thing that I don't know how to do the math for. (Orbit precision is a good point to bring up. Unless your orbit is super-precise, every full scanning period your coverage will probably shift just a tiny bit, letting even low-resonance orbits "eventually" scan the entire planet. For sufficiently large values of "eventually," that is )

I'm glad to see someone continuing off my work! (I apologize for the sorry state of code and lack of any comments ) I'll just comment on some "hidden" aspects of the algorithm that may not be as obvious.. - Probably the biggest thing to note is that the primary consideration is the number of unique equatorial crossing points. In the code it's orbitRatN, the denominator in the Res column. orbitRatN, or the numerator in the Res column, is actually useless for our purposes and I should never have displayed it. It took me a while before I figured out the algorithm to calculate it. That's also where numerical resolution comes in, because it has to decide if a fraction of 99/100 should round to 1/1 or not. (That also relates to the +/- bounds on altitude, and I'll talk about that later.) - Swath width estimation is obviously the next most important thing. A couple months ago I tried to update the code to handle scansat, but I just couldn't reverse engineer the FOV from the C# code and then life got in the way again. For ISA_Mapsat, too, I actually gave up trying to reverse engineer the function and just empirically derived an estimated curve for swath width. That's the bad news. The good news about swath width is that if you can reverse-engineer the function, then it should work even with SCANsat's "lower-than-ideal-altitude" penalty. swathWidths is just a big array, so you can just split it up into multiple lines. I don't know how the altitude penalty works, but assuming a scanner which has a swath width of 0 at ground level, linearly increases to 20 degrees at 200 km, and stays at 20 degrees for all higher altitudes, I'd insert it into the code like this: penaltyAltsIndex = find(alts <= 200e3); %find the array indices of alts where the altitude is 200 km or less swathWidths = alts * 0 + 20; %this is my lazy way of creating a matrix of the same size as another, but with the constant value of 20 swathWidths(penaltyAltsIndex) = alts(penaltyAltsIndex) / 200e3 * 20; %this replaces the elements of swathWidths that correspond to an altitude of 200km or less with a linearly increasing function from 0 to 20 at 200km (Again, I don't know the actual penalty function, but that's one way to do it. ) - Combining the two, an ideal altitude is where the number of unique equatorial crossing points for the orbit match the number of times the swath width fits in a 360 degree circle. - One problem I was never able to solve I dubbed the "mid-latitude gap problem." Because of the nature of the curved paths that multiple polar orbits trace over the Mercator map, I found that it tended to leave little diamond-shaped gaps in coverage at mid/high latitudes. I'm sure the solution to detect these would involve some complicated spherical trigonometry that I wasn't willing to do. Sometimes you could just orbit for another full scan period and it'll fill these out, and if not then you could change the scansat's inclination to match the latitude of the diamond gaps. In addition, I figured that lower inclinations would reduce the size of the mid-latitude diamond gaps, and when the inclination was set to create north/south-aligned swaths then the symmetrical patterns this caused also reduced the gap sizes. - Speaking of inclinations... a dirty little secret is that inclination doesn't really matter much for total coverage at all, aside from the mid-latitude gap problem. I always include it because it causes really aesthetically-pleasing symmetrical coverage patterns that cross the equator aligned directly north/south. Obviously user discretion should apply in case of extreme results - such as a near-geosynchronous orbit around Gillly, for example. - the tolerance for orbits is sometimes a little or a lot more forgiving in reality than it looks like. It's an artifact of the math, and the fact that I didn't program in the most robust "safe-zone aggregator", so to speak. Essentially, the higher you bump up the numerical resolution, the smaller the tolerances appear to become. The problem arises due to "rounding" when converting the orbit ratio to a fraction with a numerator and denominator. Thinking about a "real" orbit, it might actually have a resonance nearer to 2.001/21 or 1.999/21, which are slightly different resonances, but should all be aggregated to the same resonance ratio of 2/21. When calculating with higher numerical resolutions, the program treats all of these resonances as different ideal zones with tight tolerances, even though they might actually aggregate up to one larger zone ideal zone with looser tolerances. - I really should have added Orbital Period and Semi-Major Axis columns to that output. Would you be able to do that? -Moving on to Kethane for the moment... because the Kethane scanners only scan one hex, in essence they have an altitude-invariant swath width. There are 160 hexes along the equator, so the easy way to model that in the ideal orbit calculator is to use a constant swath width of 2.25. I've also written a tool that will calculate the best altitude for each number of equatorial crossing points, but its output isn't very user friendly so I never ended up releasing my results to the public. I hope these thoughts help. Feel free to ask any questions, and keep up the good work!