lincourtl

Yeah, that's what I'm seeing too. See the video I posted above (#31). skykooler thought it might be a problem with center of mass because I had solar panels extended, but further testing on my part revealed the same behavior whether they were extended or not.

Hmm. Let me try that out and get back to you. When I tested the mod earlier today the vessel didn't have solar panels, so you may be onto something. On edit: Drat, that wasn't it. I just tried it out again, and got the same effect as you saw in the previous video, with and without solar panels extended.

I think I've encountered a bug with this mod. It appears to be multiplying the magnitude of rotation after coming out of timewarp. In the video you can see I start out in 1X time with a small rotation, go to 50X, and back out to 1X. Each time I do this the rotation is greater. I turn on SAS and the rotation is slowly nulled, but if I turn it off, then timewarp again, I see a repeat of the same behavior of each round of timewarp increasing the rotational velocity.

Neato! That has always bugged me. It sure seems to freak out MechJeb's autowarp on ascent and landing though. That's not a fault of your mod -- that's just Mechjeb being Mechjeb.

It's a tradeoff -- a little less efficient in both modes for weight, and ease of use. I suspect they'll be refined (and hopefully remodeled) in future releases though.

If I'm understanding you correctly, then why not just use the linear RCS ports for this? Bind them to an action key so you can turn them on and off separately from your translation thrusters. At least I think they can be used that way. I've never tried it.

They're stored in a SCENARIO inside the persistent.sfs file for a particular save. There'll be a separate Body block for each celestial object you've scanned. Look for a section like this: SCENARIO { name = SCANcontroller scene = 7 colours = 0 map_markers = True map_flags = True map_orbit = True map_grid = True projection = 0 map_width = 0 map_x = 100 map_y = 50 anomalyMarker = ✗ closeBox = ✖ legend = False scan_background = True timeWarpResolution = 20 Scanners { } Progress { Body { Name = Kerbin Disabled = False Map = CAABAAAA-----0AHQAAAB0AIAQICIAoAaCAJALQgBwAAQAzg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDg-wDgawABAAs_ } } }

The mapping data (actually the areas you've scanned -- the maps themselves are regenerated when you ask for them) is stored in the persistence file. So if somebody else does the map scan in KMP, it wouldn't be saved in your persistence file. If you do the scan, it should be saved.

Hah! Good question. I got so fixated on your altitude that I missed that part of your original query. I've never had a situation where the minimap wasn't updating unless the sensors were out of range. I have had weirdness where the sensors would report being out of range, even though they weren't. For instance, I was doing an altimetry scan of Duna the other night at an almost perfectly circular 750km polar orbit, but my SAR sensor kept blinking out as I passed over the poles. Reducing my altitude to 725km solved the problem. I have no idea what could have caused that. My only other issues with this mod are 1) I'd really like it to use Blizzy's toolbar, and 2) the settings are never retained. BTW: I used ModuleManager to add Maptraq to all my spacecraft. If you already have ModuleManager installed, just stick a file named something like 'add-maptraq.cfg' in your GameData with this code: @PART [*]:HAS[@MODULE[ModuleCommand]] { //enables SCANSat MapTraq on all pods and probes// MODULE { name = SCANsat sensorType = 0 fov = 0 min_alt = 0 max_alt = 0 best_alt = 0 power = 0.01 } }

You're way too low. Each scanner has a maximum, minimum, and optimal altitude. They're defined in part.cfg for each part, but they really should be mentioned in the description so you can see the values when you're building your craft. The MapTraq is used for accessing the maps on craft without any of the sensors -- sort of like a GPS receiver. [TABLE=class: grid, width: 85%, align: left] [TR] [TD]Part [/TD] [TD]Part Folder[/TD] [TD]Min. Alt.[/TD] [TD]Max. Alt.[/TD] [TD]Opt. Alt.[/TD] [/TR] [TR] [TD]SCAN RADAR Altimetry Sensor (Low-Res Altimetry)[/TD] [TD]Scanner 1[/TD] [TD=align: right]5km[/TD] [TD=align: right]500km[/TD] [TD=align: right]5km[/TD] [/TR] [TR] [TD]SCAN SAR Altimetry Sensor (Hi-Res Altimetry)[/TD] [TD]Scanner 2[/TD] [TD=align: right]5km[/TD] [TD=align: right]800km[/TD] [TD=align: right]750km[/TD] [/TR] [TR] [TD]SCAN Multispectral Sensor (Biomes & Anomalies)[/TD] [TD]Scanner 8[/TD] [TD=align: right]5km[/TD] [TD=align: right]500km[/TD] [TD=align: right]250km[/TD] [/TR] [TR] [TD]SCAN Been There Done That® (BTDT -- short range anomaly ident)[/TD] [TD]Scanner 32[/TD] [TD=align: right]0km[/TD] [TD=align: right]2km[/TD] [TD=align: right]0km[/TD] [/TR] [/TABLE]

I seriously recommend installing Blizzy's Rendezvous Tutorial mod, and his Docking Tutorial mod. Those two mods will teach you everything you need to know. However, here's Scott Manley's docking and rendezvous tutorial from 0.18. Nothing has changed in recent versions that would invalidate it.

Ike's core is made of pure evil. I base this on the fact that no matter how I come into Duna SOI, Ike always stands between me and Duna orbit.

Nice! I like how you think.

You're incredible! That would be fantastic. I like this. Maybe something that allows users to configure mods without altering configs? Sure. Next release.

Do we need a config file now for everything we want to be compressed? For instance, I see it isn't caching textures for Procedural Fairings, so I assume it's not compressing the fairing and base textures at all.

So 2-12 and earlier were reporting about twice the actual memory saved? That doesn't seem quite right either because I'm running up against the wall with fewer parts mods since 2-14. In any case, I'll try loading KSP in windowed mode with Performance Monitor running both with and without Active Texture Management. Once again, please don't mistake my comments for complaining. I'm totally chuffed with what your mod allows me to do in KSP with my poor memory starved machine.

The aggressive version halves the texture sizes, and knocks out MIPMaps (which alone subtracts about 1/3 the size from those textures using them), as well as just compressing the textures. The basic version just does the texture compression. At least that's how I understand it.

Thanks for all your hard work! Loading time with the cached version is much improved -- in my case it's halved from about 8 minutes to about 4 minutes. I'm still only seeing 714MB saved in 2-15 Aggressive compared to the 1.5GB savings I saw in 2-12 Aggressive. I'll happily take the 714MB, but I'm wondering why the huge difference between what you were doing in 2-12, and what you've been doing in 2-14 and 2-15 (I missed the 2-13 release). Also, the amount of memory saved reported in the log decreased from loading 2-15 the first time to loading the cached version -- 714MB down to 701MB. That's not significant, but thought I'd mention it.

No, I didn't include any of my previously modified configs when I tested both 2-13 and 2-14 because I knew how much you were changing. Here's my 2-14 log. Edit to add: Those values are what is being reported in the log file. On 2nd edit: I just tried it with 2-12 again to be sure (2-12 log file here). Memory saved 2-12: 1,482MB. Memory saved 2-14: 714MB.

I'm sad to report I'm still seeing only about half the memory savings in Aggressive 2-14, as I saw in Aggressive 2-12 -- 714MB vs. 1.5GB. Load time is also still much higher in the latest version compared to 2-12 -- 7m 7s vs. ~5m. No crashing though, loaded fine, no errors in the log.

Whoa! With 2-13 Aggressive, my load time increased from 4:30 to 7:05, and the reported memory savings declined from 1.5GB down to just 700MB. That is a marked difference from 2-12 Aggressive. On edit: Forgot link to my log file if you want it.

The data is actually stored inside your save file, so unless damny changes things in a future update, you should be fine.

I'd love to be a tester on this!

Absolutely. It's the developer's choice of how considerate of the user they want to be.

I could live with that.