Innsewerants

This mod hasn't ever been dead. Unless you missed the links to my blog in.. o I don't know, only my signature, opening post here, half my more recent replies here, my youtube, spaceports info page on the old version, irc chat. Mapsat has been alive and well and working all the way up to and including 0.22 unless you missed all of my linkage. Furthermore I think you need a kick up your *** Yes it works on 0.22, the maps are always up to date or it updates them, mapsat gets the actual elevation data, no pre-packed textures or anything Get the latest versions on my blog here. There's no tweaking of elevation colour to sea levels, his black sea is probably caused by a bad hilo/dat file. It's not broken for 0.22 at all, just be sure to get the latest builds from my blog here and not Spaceport (I link to the blog on Spaceport info page of the old mapsat.)

New dev build, more info on blog http://forum.kerbalspaceprogram.com/entries/1081-Mapsat-4-devbuild-2-now-available

Hehe I'm not that paranoid lol, if you had used bits of it I would have offered to put in an exemption for your use that's all.

Nice stuff, finally some competition on the mapping front. You just reveal/unhide game textures? I purposely avoided that because I wanted Mapsat to actually do what a topography sat does (though that means multisat was too perfomance intensive for mapsat.) But it's a valid approach and one I though about using for colour maps but I couldn't find a reliable method of accessing the planet colour textures ingame without pre-making them and putting them in the zip and that's just not a good solution imho so I stopped with the real terrain colour. Good luck with the mod, I've been waiting for someone to try a different approach and compete a bit instead of just trying to steal/take-over Mapsat because I was on ksp-vacation longer than they had patience for. If it's using anything from Mapsat, the license for Mapsat doesn't allow for that. If there is something you use that's critical but is a snippet from mapsat let me know and we'll work it out. You do know Mapsat 4 devbuild works with .20 .21 and .22 that's why I took a break from it until now. So technically it doesn't need replacing lol.

Hereby confirming the assumed license as now stated on the opening post: License ALL RIGHTS RESERVED No code is allowed to be used or modified and published without express written consent. I will be making a blog post about this too. Cheers from hiatus-land.

Are you sure it's not just that you're moving very slowly compared to the ground? 1 pixel in y on kerbin represents 1.84 km on the 2048x1024 maps. It might take a while if you are going very slowly compared to the ground for it to move enough to scan something that's represented by another pixel. It would explain why timewarp works. Using old saves should be fine as long as it's fine with ksp itself. You can easily check this having the POS marker on and zooming in on it fully.

Leave scanning off when still in range of each other? (SCN) button. That's why it's there It's not really confused most likely. There are a few instances this happens. On intitial flight start it's default orientated to a course of 000° and it needs to fly a bit to get the data for a course over land calculation. So it always starts flight with a horizontal line for a 000° course and might draw once or twice while switching to the actual course value. It can seem confused around the poles but it's not, your course over ground quickly turns 180° as you get near and pass the pole (e.g. from heading 000° north quickly turning to 180° south course, so the scan line spins with it accordingly, it actually gets the poles filled in better and faster this way by doing a sweep around over these polar singularities. It can also happen when you are leaving the orbit of a planet going along it's rotation (launching eastward on kerbin to an escape trajectory e.g), as you get further out your speed over land will decrease, become zero and your course over land will actually switch direction as you are now flying almost straight away but the planet is rotating beneath you, your path relative to land has reversed, and the scanline rotates accordingly and follows the new course. The same can happen if you approach a planet for an intercept depending on what angle you approach it from compared to it's rotation. Very high timewarp will throw it off probably, it's not recommended to go beyond 100000x timewarp generally, and not beyond 50000x if your machine isn't the most powerful on the ps, if it's in range then yes it will even be available in your interface unless I changed that and forgot. Anyhow I think I will call it quits for now with post release forum and blog lurking and responding, I really need some sleep and to unwire my brain first. Any more problems, questions and stuff will have to wait for tomorrow. Cheers, I'll be back!

Try 100, yes, seriously. I had it on 100 for a really long time. I only upped it because my machine can handle it without getting unacceptable spacing. IS this with csv on? and with what timewarp? Also whats your fps like / system specs. Curious I'm wanting to show Mapsat on youtube again, that would make it easier to compare performance to my machine for others as well. I just lack the diskspace for the huge files you get from recording at 720p Come to think of it if this was at 1x speed this might actually be your script doing it, the io functions don't take kindly to programs other then unity itself reading files that are in use. If you had csv writing on it's that, it's considered broken, the gaps you see are from how much longer the scan takes with filewriting on, so you travel a much further distance between scans. See the large explanation I gave a page or 2 ago. For everyone: In general about the scanresolution setting: One thing you need to understand is that the scanResolution isn't the distance in gaps along your path of movement, it's the number of measurements in the scanning line that's perpendicular to your movement direction. There is a trade off, the higher the scan resolution the more measure points the scanline perpendicular to your direction of motion, but this means the scanline takes longer to complete so the resolution along your direction of movement becomes less. The best way to optimize I find is to zoom in on your new map, start the scanning go to settings and lower the scanRes as much as possible until you start to see gaps in the perpendicular scanline at some latitude you want solid-ish after first pass (it changes on the fly when you save the settings) and then turn it back up a small notch to get it solid again. I might rename things to make this more clear. Ever increasing your scan resolution will actually decrease the resolution along the scan path. the trick is in finding the right balance which depends on body orbited, altitude, machine specs, what else is running etc. In your case I mostly think it's because you're using the csv writing it's too slow.

Don't worry I won't drop the csv writing and I'll make it mroe clear in the documentation when the final is done that it's just a time consuming operation and that means framedrops. Atm though it's simply also just very not optimized at all really *cough. It's fine for the old resolutions but I'm scanning a lot more coordinates to keep the gui maps nice, it takes a bit to compensate for switching to 2048x1024 maps and the csv routine has not been tweaked since the old small maps in 3.3.4 Filewriting takes a lot longer than my gui stuff so it really needs some tweakage before I'll take the "Broken" sticker off of it.

this could simply be because a resolution of 300 results in less duplicate results, there's a filter, this would then actually have more data per write to the csv file than the 500 setting because a lot of those will be duplicates that are filtered out before writing the file. The real problem is it's waiting for 5 seconds and dumping that data (10s of thousands of lines) in one go. I had secretly hoped to drop the csv feature, filewriting is slow. As said csv writing is on the list to look at, for now it's not recommended to use it. Consider it known to be broken. Also the raw data without main scanning is just as fast as not scanning at all because csv scanning is part of scanning routine as a whole, it doesn't get called when scanning in general is off. I'll fix the button lights to reflect this.

I'll try and explain a bit more. I'm sorry if I come across robotic, I'm deathly tired now. First of everything of course always depends on hardware, no matter how good or bad my good there will be a limit somewhere where you notice fps drops beyond acceptable levels The new scanning routing doesn't use a square grid of points any more instead trading that for a line that adjusts it's orientation to keep it optimal for whatever direction you are tracking over ground. This "scanline" consists of measurement points spread out evenly. The number of points used equals the scan resolution setting. If you think of this as the horizontal axis there is no real vertical axis because I dropped the grid. The "vertical" axis (direction we're moving across the ground) resolution depends on how much time it takes to finish a scanline. It won't pause between scans but scans themselves take time. not a lot but well ksp has timewarping. How fast a scanline is finished depends mainly on 2 things, the amount of measurements in it (the scan resolution setting) and how fast your computer gets it done. (all the other ksp stuff/frame needs to run too so keep that in mind.) now say with all things considered a frame takes you 16.7 milliseconds. That's just under 60 fps. So my scanline gets to scan once each 200 measuring points each 16.7 milliseconds. At normal time speed and 2000 m/s over ground there's a spacing between 2 scanlines of 33.4 m. Sweet that's tiny and will look pretty much solid on the map. But we have timewarp, so lets crack it up to 50x. Now because there is no real timewarp, for mapsat timewarp is just faster motion, we're traveling 50x2000= 100000 m/s over ground. and between 2 scanlines are 0.0167*100000=1670m, that's still really good for the gui maps 1 pixel vertically/latitude on kerbins rectangular map represents about 1841m, horizontally/longitude it variates greatly because of map distortion. Now say 1 ms of the 16.7 ms total frame time is my scan with 200 measuring points and we set it to 500 because we think we want more resolution in the scanline and we assume this simply also linearly increases the time it takes for the scan to finish for simplicity's sake. now our frames take about 19.2ms to finish. The resolution in the scanline has increased but our resolution in the form of time between scans has increased. At 1x speed the space between scans has only increased to 38.4 meters, but at 50x the space between scans is now 1920m, we will start having gaps now and this close to the map resolution any frames that take a little longer because ksp does something like save or unpack something or mapsat saves the map or applies texture changes you will have a good chance of getting gaps from these longer frames And since our frame now takes 19.2ms avg to finish our framerate drops to 52.1 fps now say you do the last thing again same settings timewarp, speed over ground but you are using a less powerful pc. Now your frame takes say 27ms to finish with everything and mapsat scanline. now the distance between scans at 50x timewarp is 2700m thats a very noticable and guaranteed gap between scans, and the fps on this weaker system with these setting would be 37 fps. Assuming perfect polar orbit: So the higher the scan resolution longitudinally the bigger the distance between 2 scans/lower resolution latitudinally Fps (except csv) shouldn't change too much between different timewarps as it just does x measurements per frame. Fps will change with increased/decreased scan resolution, the lower the fps the bigger the gap between scans becomes again. In many cases there is simply no need to for hundreds of measuring points in one scanline, not even csv scanning will track such small distances on planets the size of kerbin with just 2 decimal places in the gps coordinates (0.01° longitude on kerbins equator is 1047.2m) CSV writing excluded, as said before this has not been properly looked at since 3.x and the small maps and different beam code, it's slow and buffers way too many coordinates before writing causing really laggy and long writing sequences. I would suggest changing the value with increments of 10 or 20 not 100s. small changes make a difference. Don't try values like 10000 unless you own a machine at CERN. My old laggy grid used 1678, 1678 dots in a scanline though will just be a useless waste of performance for no gain though. I hope this clarifies it a bit, if not I will try it again after I had sleep.

It's not really the visual scanning causing this, it's directly related to writing the csv file. As I explained shortly in the change log and the blog post csv writing atm will likely be horror, I have not tended to it all since I increased the resolutions apart from changing the save interval from 15s to 5s. I don't recommend the csv writing feature in the dev build atm. Giving csv writing some love is on the planned list. & I've put this on the to do/explore list. Thanks for the suggestion

tek_604 Just ignore people that don't read, I do I must have posted 3 or 4 times today keeping the thread up to date for a coming dev build release today.. and then someone comes along and ask such a question. Just ignore it Anyhow, the blog post is up with the dev build and a lengthy post about the changes since the last blog update enjoy!

Just added some options to the settings menu to allow you to tweak the scan routine to your liking/tech specs. The Scan resolution default starts at 200 measurements per scan. 100 is where it was at in the screenshots I posted earlier and most of that was mapped at 50x timewarp. With my cpu downclocked to 2.2 ghz from 3.0 ghz and a setting of 500 I get acceptable performance and my first passes on Mun were fully solid except for really close to the poles in the rectangular projection. I'll explain more in the blog later. I also added the option to change the time interval between autosaving the map that's being scanned, the default is 120 seconds. I've set it to 300 for myself as it saves any maps that have changes when you press pause too. Which also won't freeze badly any more like before. The third option I added so far is the ability to switch on or off the new feature "AutoUpdate Hilo.dat" This feature will update hilo.dat if it finds new planets. You'd only really need it if I don't update mapsat for a new ksp release that has new planets it would also allow you to edit the dat file (it's plain text) and remove a planet if squad changed the terrain so it will check again for the highest and lowest elevations. I will always continue with having an "official" hilo.dat included with new releases but I thought it would be nice to have anyway for the users. Updating Hilo.dat may take up to a few minutes depending on your machine and makes ksp look frozen, it's not. Turning this on will not make it freeze every time, just if there are new planets. So in one way you will rarely need it, but in another it won't harm you having it turned on. Default is off. It's looking good for a dev release today (it's 11:29am right now here). I will work a bit more and I guess next you'll hear from me will be on the blog with the dev version and updates and stuff. Cheers!