Psawhn

January 20, 2015

Here's some ideas:
https://github.com/KSP-RO/RP-0/blob/master/GameData/RP-0/CostHacks.cfg#L38
(Start there, read down).
I suggest you set the price of all fuel tanks (PP and non-PP) to 0.1 and let RF handle the cost.

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.

January 20, 2015

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?

January 17, 2015

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.

January 16, 2015

RftS is *very* out of date. The only mod that prices everything for the Real*.* universe is RP-0, though it's nowhere near finished.
RealFuels, like all the realism mods in the RO stable, uses 1 fund = $1000 in 1965 dollars. So that tank costs $28,000 USD (probably something like $400k in today's dollars). Propellants, however, are dirt cheap: think about how cheap a gallon (rather more than a liter!) of gas was in 1965...
RP-0: http://forum.kerbalspaceprogram.com/threads/103196-0-25-Realistic-Progression-Zero
(note that ONLY the mods listed as supported are supported by RP-0, and if it's not even listed as WIP, then *none* of the prices will be correct...)

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. :sticktongue:

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.

January 16, 2015

Czerky: Make a *large* tank (like, 5m x 10m, say). Show the RF GUI, and add a LH2 tank. Now tell me again that it costs 0.

Well, you're right, $28 is a lot more than $0.

Javascript is disabled. View full album

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.

June 5, 2014

I'll double check, but I think the effective FOV numbers are "correct" (in the sense they match what SCANsat is doing). The nominal FOVs for those scanners are 5, 4, and 2, respectively. There is an (arbitrary) maximum cutoff of 20 degrees total, which is again reproduced.

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.

Me too. But until I switch SCANsat to tell the user any of these values during scanning, I'm just going to stick with the nomenclature that's there. Once I have a good handle on the relationship between the two, I'll switch over to be correct.

Ah. Sounds good.

I think SAR is arbitrarily high. I don't know about RADAR. I don't know about biome, but that makes sense.

In-game, it appears RAR has a resolution of 1x1 degree.

Damn. I was hoping you would know. I assumed it was number of total number of equatorial crossings, but that didn't seem correct.

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!)

June 4, 2014

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.

May 23, 2014

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.

May 22, 2014

Well the problem stems from Kerbal Space Program only has 1 way to track a vessel and what it is. Thats Vessel ID's. Every vessel in game gets a vessel ID. When a vessel docks with another vessel they combine into 1 vessel ID. And when they seperate they both become 2 different ID's. So MCE uses these ID's to keep track of what Missions have been done by what vessel and what objectives are also done by this vessel. The system is great most of the time because the player can run multiple missions at the same time. For instance using your example, player can launch a vessel to Jool. MCE records any objectives for that jool mission for that vessel ID.
Player now wants to run a mission to his space station in Kerbin Orbit. Player deselects Jool mission and runs the Space Station mission, finishes it.. Maybe he runs 3 other short missions and finishes it. The jool vessel is about to get into Jool orbit. Player loads the mission back and loads the vessel. MCE will continue from where the player left off because the Vessel ID is saved for the jool mission under this players vessel. MCE see's that the player already did such and such missions and is ready for next objective which is orbit duna. Player orbits duna and finishes objective and mission and gets paid.
This is how it works right now most of the time in game, as long as player vessel ID never changes.
Where things go wrong with apollo style missions.
Player with same jool mission loads up the mission and the vessel. Player is to land on tylo. Player enters tylo with same vessel hes been using the whole time. But his lander is a completely separate vessel with its own pod (this is important). Player is in tylo and seperates the lander from the rest of vehicle. The new lander now gets assigned a brand new vessel ID because the Command vessel still retains its old ID (its still a playable craft because it has its own pod). The the players new craft with completely new ID doesn't register with MCE as completing any of the objectives before hand. So MCE thinks this is a new Vessel doing the mission over so its waiting for this vessel to complete the objectives before getting to Jool.
Thats the nut of it. This can be bypassed by using the VesselIndependent = True value in MCE for the landing goal of tylo. What this means is that once whatever vessel lands on tylo the mission objective will record for any vessel, even an EVA kerbal. Once the player goes back to the command pod, nothing matters anymore because the command pod has the old Vessel ID and can complete the rest of mission without VesselIndependent.
the problem now is that since basically the Landing value for Tylo is never really recorded (thats what vesselIndependent does by the way) the player now has to finish the rest of this mission in one play through without leaving, or the landing on tylo will reset.
Thats about it.
As for a new system, I have thought about doing a tagging system. Once a vessel launches its actually tagged. And any vessel that is Undocked from it gets the same tag. And MCE tracks the mission objectives using this tag. Its a lot of work though and something that might be trying once I have to completely recode the whole Mission System. Which might be the case for KSP .24.

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.

May 22, 2014

Sorry to double-post and keep spamming up your thread like this, but I just finished collating up the data.

To me, that is not only the obvious place to start to calibrate the FOVs and swath widths of scanners in RSS; it is also a good way to determine the realism level of scanners in the Kerbol system. I would be happy have someone to summarize the orbits used and the total scanning time needed and see how these scanners compare.

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:

Interferograms can be used to produce digital elevation maps (DEMs) using the stereoscopic effect caused by slight differences in observation position between the two images. When using two images produced by the same sensor with a separation in time, it must be assumed other phase contributions (for example from deformation or atmospheric effects) are minimal. In 1995 the two ERS satellites flew in tandem with a one-day separation for this purpose. A second approach is to use two antennas mounted some distance apart on the same platform, and acquire the images at the same time, which ensures no atmospheric or deformation signals are present. This approach was followed by NASA's SRTM mission aboard the space shuttle in 2000. InSAR-derived DEMs can be used for later two-pass deformation studies, or for use in other geophysical applications.

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.

May 22, 2014

As for electric charge usage -- this is a realism point that needs to be addressed.
My only guess at how to handle it would be:
calculate in the active vessel how large of a battery buffer would be required to survive X scan type at Y warp factor
for each background scanner
if their panels are deployed and/or their RTGs are actived and:
their battery buffer is large enough, allow them to contribute
otherwise, disallow contribution and warn
Additionally, if/once we implement a day/night terminator we would be able to more precisely determine if the buffer would suffice. Modulo different orbital parameters, this should be nearly trivial to estimate.
So even if we don't drain the resource from an inactive vessel, at least we can ensure that it would have had enough charge had we used that vessel as active.
NathanKell says that you *can* drain the resource from an inactive vessel, too.
I don't actually know if we can ask about panel deployment state or battery capacity. I suspect we can.

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.

NathanKell and I have discussed this today. There are a few known location where SCANsat hardcodes values which (relatively) hurt the utility of SCANsat in RSS. Nevertheless, thousands of people use RSS and we want them to use SCANsat, so they are a relatively high priority.
To me, that is not only the obvious place to start to calibrate the FOVs and swath widths of scanners in RSS; it is also a good way to determine the realism level of scanners in the Kerbol system. I would be happy have someone to summarize the orbits used and the total scanning time needed and see how these scanners compare.

If you'd like, I can summarize some of the stats for some of the real Earth-Observation satellites.

[sAR sidelook]You've mentioned this before. For SAR, we would essentially cut the swathwidth in half and offset it to not be centered? (or leave the width the same but make it offset)?

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.

My favorite pet project in new scanners lies in satellites that require multiple vessels to provide any data (ala GRAIL or RBSP). In other words, scanning 3D volumes instead of surfaces. This, of course, is probably very difficult and all of the data would need to be implemented by us.

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.

Orbit projection doesn't work like I expected it to. I had those screenshots of me playing with it. What I found is that it was happy to project backwards, but would only project one orbit forwards.
This could have been the way I was doing it, though. *shrug*

Well, luckily that method only has to project backwards .

May 22, 2014

Yeah, the end result would seem to be about the same. The offset scanning coverage would be slightly different, though it would probably just confuse the majority of users and would only be noticeable if you actually watch it scan. And also, scanning under high time warp relies on the high FOV creating a box around the vessel position to fill in the map without gaps. If we switched to a much narrower scan in one dimension it would complicate that.

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.

May 22, 2014

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 .

May 21, 2014

Ugh, the Windows command line is a PITA... doesn't size wide enough to properly space the various columns, and doesn't keep enough of the output in memory to be useful...

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)

May 21, 2014

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.

May 20, 2014

Earlier you asked if SCANsat uses a camera or something like that to scan the surface -- no, it does not. The camera bit (RemoteView) is just for the BTDT sensor.

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

May 20, 2014

I want to say I've recently picked up this mod, and I'm quite enjoying it.

Ah ok, I don't remember anyone adding that, but let me check the code to see if I can find it. Might been something nathan added a long time ago to test.
Edit. Ah yes nathan must of snuck this in before he left, its using only moduleengines at this point to test the values, I will have to add the new module engine fx to make it work with new type engines that use ModuleEngineFX.

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?)

May 20, 2014

Psawhn:
Yes, I am aware they are incorrect. I was still deciding what to do about it. I don't even remember the state I left MapSatAltitude.m in.
I currently think I should modify MapSatAltitude.m to use the same calculation that SCANsat uses internally. Namely, fov *= (current altitude/ideal altitude) if you are below the ideal altitude; and also fov *= max(1,sqrt(kerbin radius/mainbody radius)). This first factor is a penalty, the second factor is a bonus if the body is smaller than Kerbin.
Yes, I think this is precisely where the discrepancies come from; I just was focused on getting SCANsat released first.

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?

Now, in case you like to give us the "separate tool" implementation to try, I am to ask if you could generate a compiled version to be run with the MatLab Compiler Runtime (being the MCR free to download, would allow anybody to use this tool for free). Of course, when you feel the code is to your satisfaction.

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 .

May 16, 2014

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.

May 12, 2014

Psawhn (who made the ideal altitude calculator) figures that you can replicate the correct swath width of the Kethane hexes by simply using an FOV (or was it swath width?) of 2.25. Or maybe a shade less, to handle the case where you are scanning between two Kethane grids.

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!

May 3, 2014

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.

April 30, 2014

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!

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, 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).

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.

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.

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.

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.

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.

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.

It mathematically can't suggest 90 degree orbits.

tgtInclination = acosd(orbitalPeriods./planetDay);

Inclination will only be 90 if orbital period is zero.

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

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.

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

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.

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.

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.

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.

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

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

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.

Yeah, that's a good point.

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!

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 .

April 29, 2014

I am pretty sure I understand the fov calculation for SCANsat satellites. I think, at one point I had it replicated in MapSatAltitude, but I don't remember now.
I don't know the status of ISA_Mapsat. I certainly don't use it. I think it crashed my game on launch.
I intend to be the new maintainer of SACNsat, and also intend to improve upon it. As such, I will have the decision of either trying to account for the altitude penalty (and, in fact, there is an altitude bonus) OR eliminating the altitude penalty (and/or the bonus) and having a static FOV. I don't really know how this works 'in real life'. Also, I don't think usually people would be operating in the same context as we are: how to cover a planetoid from orbit with exactly one vessel.

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.

Anyway, I thought the difficulty would be having an array of FOVs, but it seems like everything in Octave/Matlab is an array.

Heh. Not only that, but everything is a matrix! :sticktongue: (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.)

Yes, that seems easy enough to understand. I was wondering: in the code I have, there is planetRotPerPeriod, which is aptly named. However, it is never used. But I think your code must be accounting for planet rotation, otherwise the time to complete scanning estimation would not be so (relatively) accurate.

Have I apologized yet for calculating variables that end up never getting used? :blush:

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.

Yes. I have to keep reminding myself that this tool optimizes for a specific case: What is an ideal fixed orbit so that exactly one scanning vessel can cover as much of the planet in the fastest possible time?

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?

You can alter (or weaken) [the mid-latitude gap problem] case in several ways.

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.

2. You can also, as you suggest, simply wait another full scanning period (though this might never work, in some cases, depending on planet rotation and how precise your orbit is? right? *shrug*)

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 )

April 27, 2014

I'm glad to see someone continuing off my work!

(I apologize for the sorry state of code and lack of any comments :blush: )

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!

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Psawhn