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.