Jump to content

Innsewerants

Members
  • Posts

    90
  • Joined

  • Last visited

Everything posted by Innsewerants

  1. 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.)
  2. New dev build, more info on blog http://forum.kerbalspaceprogram.com/entries/1081-Mapsat-4-devbuild-2-now-available
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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!
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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!
  14. 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!
  15. Yeah that was just a dumb thing on my part. In the dev version the icon is a fixed width away from the side. Since the ksp gui scales and stays a fixed width it shouldn't be a problem any more. Just before I went on hiatus there was someone doing a mod to try and unify and interface for all mods that would auto arrange everyone's icons. I should check if that's still around now because I whole heartedly support it to try and promote everyone to switch to an agreed upon icon size and style and support the unification mod. I don't remember who it was back then who was doing that.
  16. Heya, sorry about not posting the promised blog entry, something happened called 0.20 that interrupted that haha. I just finished fixing my dev code for 0.20 and doing some tests if everything works. 4.0 will be using the new plugin lay-out, there were quite a few issues so I just moved over completely. Anyhow keeping it short as I'm coding as I post this. Depending on what I get done now I think I will be releasing a dev build, it won't have all the stuff I want to put in 4 and will be messy and have known bugs and unoptimized parts that are on my todo list. But it will have the new map sizes and be fully 0.20 compliant at least. Let me know if you want that and promise you won't flood me we reports about obvious and probably known bugs lol. [edit] O and I just made these screenshots when I tested my fixes for 0.20 I'm reserving the screenies of the new scanning beam I haven't told you about yet I think, lol, for the blog post I neglected to do about the changes done last weekend.
  17. There's an updated hilo.dat on my blog and in the thread here somewhere, easiest just to check my blog, you can also manually have mapsat rebuild it by deleting it and starting a flight with mapsat, it will seem to hang for a while before its done building, it's meant more for me as the dev but will fix your hilo.dat. 3.3.4 came out around late in 17.x I think, I've had a seperate new source since and because I'm changing a lot both in code and the superficial features of mapsat I just try to avoid wasting too much time on fixing 3.x. This bug is fixed in the next release/current dev build, it's caused by all the new models around ksc, because my filter for anomalies is based on exclusion (I exclude things that are definitely not anomalies instead of look for things that definitely are anomalies) it finds a zillion of them around ksc. Combined with some old and now replaced saving code that caused a lot of lag whenever ksc is in scanning range. All this is fixed in my current build. It's noted on my blog and in the thread here somewhere. 4.0 isn't too far of now I think. I think the best way from now on to keep up to date about mapsat is my blog here on ksp. I only recently started it but I am liking it as a way to report news about mapsat a lot. Probably another mod causing it or the combination of another mod + mapsat. If you like please investigate and report what mod it is, I'll try and get in touch and see if we can resolve the issue. I haven't had this happen with just mapsat in my clean testing install nor on my main game install with the few mods I always use. (mechjeb, robotics, engineer) Yes you can, I made the gps for that, it esentially uses the same code and interface but excludes scanning from running so it's light on performance and portable as far as model size goes o you can put it anywhere. Sorry about that, once upon a time I thought it would be easy and convenient to differentiate between the gps and dish part based on model names. Unintentionally excluding any easy use of the code with other parts. This is on my to do list to change for the next release. Real topography scanning satellites? They either look like boring grey boxes or they look like my dish except instead of an antenna in the middle there's a radar or laser emitting bar on it like and even that dish is normally hidden inside the fuselage. (it uses radar which just penetrates the protective hull casing iirc) and it doesn't auto look at the ground either! lol I might change the design and quality of the dish model but the basic idea will probably stay. I am however going to change my method of differentiating between gps and dish which will get rid of the problems of using the dll on other parts, custom dishes etc. pod animations and stuff is not what determines if the scanning code runs lol, the other way around is more likely (game code not real life ), The new default for scanning is off anyway. 50% want it off at default 50% want it on. So I'm just picking what I prefer and I prefer to start scanning when I am finished getting into my mapping orbit lol. As far as all the animation model suggestion go, great. But, if I spend the little time I have for mapsat on making a nicer model and model animation gimmicks I won't get work done on the core functionality of mapsat which I would guess is more important? I might do more work on the look of the thing when mapsat is up to date again and I have enough time. As far as all the different scanning goes, there's just nothing to scan really in ksp and I'm not going to make fake datasets to scan. There essentially is only topography right now, there's no ground temperature really, I've been playing with doing that and the temp. curve but so far nothing interesting, no magnetic fields to scan, visible light is not going to work either I wasted a few hours on that yesterday. I'm not allowed to readpixels from the diffuse maps so that comes down to having no data. I have an idea for old school realistic photo mapping like space agencies do in real life, but that's quite a large undertaking and probably not suited for just a feature in mapsat and mapping would be slow because to keep lighting consistent you can only map strips of the planet that are in between a few degrees of "noon" when the sat passes over. I can code it no problem but would it be fun? Many people think mapsat as is takes too long, this would just take "forever". I will look at mapping resources when they become official though. And if they ever add anything interesting to map I will definitely check it out. I don't want to sound like a downer, they are all great idea's but as you might have noticed I get way too little time in on mapsat work as it is and compared to functionality and bugs superficial models and animations don't add that much. A definitive might do though but that all depends on time and despite (or maybe because) mapsat being the usual free mod, money. As far as the beaming goes, no sorry. It's just makes for a less enjoyable user experience, Or do you really like sitting and waiting for a at to pass over ksc to transmit it's data. never mind waiting for the one around eeloo to come into line of sight with ksc? Also this comes back to multisat mapping, pqs reading is just too heavy for so many simultaneous scans everywhere. I've improved mapsat performance a lot lately but it's still a limit. I'm thinking about having a transceiver gps type part that will let scanning continue with mapsats that orbit the same planet as the vessel you are controlling so people can do stuff while mapping. Just an idea atm though. might be in 4.0 or a later incremental update if I decide to do it. Sort of an intermediate between full multisat and having to be on the same vessel as the satellite. There's a bug in the gps model vectors, it's backwards, rotating it should fix it, I will fix the model once the coding work for 4.0 is done. Disable scanning while launching/landing at ksc for now. Work on mapsat is going well. I managed to get a lot done over the past 3 day weekend (monday was a holiday here), I will blog about it later today or so. -- Would people want an intermediate changelist of the current dev version? I hope I didn't forget anyone since my last post. Keep an eye on my blog, I will update somewhere today probably about the work done in the weekend and I am fast coming to like it as the main way to post news about mapsats development. Fans will probably be best of subscribing to it Hope that answers all, Cheers Innsewerants!
  18. That's not exactly a lot either if you'd want to play another ship while the mapper is orbiting somewhere else. -- @artao, It's the intended function, I thought about multisat mapping for a while which would also solve your problem but it would mean major rewriting of code. I have quite a large to do list already right now and don't get enough time in on working on Mapsat as is. It might be a future feature, if I find a slot somewhere when I can really put some time in on Mapsat. Perhaps a compromise like needing to be around or on the same planet. Getting the elevation data is also not the lightest of operations. I have been dedicating most of my time since I've resumed work and got back in touch here to performance to cope with the future high resolution maps. It's going well but I don't dare to predict if there is enough headway for multisat throughout the Kerbolar system and if there is there's also adding new map types to consider, every type needs it's own texture and texture applies are not a light operation, that's beyond my control as it doesn't seem to matter if the texture apply has 1 or 1000 changed pixels. So a definite very maybe in 5.0 For now I'd suggest you use 50x timewarp and try to find the best mapping orbit for whatever you are mapping. You don't need to do it all in one sitting, Mapsat won't forget the maps @Deep Silence, I'm looking into making it use electricity for the next update. @castun, No idea, maybe he made an error in the cfg and it's not loading properly? It's in the right category in my dev version. Categories changed somewhere between now and last update. Most of what Mick said might also be true except for one correction. If the hilo.dat file is missing you won't get white or garbled textures, KSP will seem to freeze for a long time as Mapsat rebuilds it. It takes a while and ksp looks crashed until it's done. That's why I include a hilo.dat. The rebuilding is meant more for me as the developer.
  19. It's possible my exclusion of some scanning functions when scanning is turned of is faulty in 3.3.4, I'm not entirely sure as I haven't worked on 3.x code in ages after deciding to switch to a new source for the next version, if so, my apologies I'm trying not to get distracted fixing the old version instead of finishing the next one. The anomaly scanning has been rewritten in my dev version and this bug doesn't apply any more in that.
  20. This feature is in the new version, unless r4m0n removed it from his end of the deal the next version has a feature where you click on the map and the coordinates get put into mechjeb automagically. ---- Also, blogging from now on whenever I had the chance to work on Mapsat I will do a quick update here http://forum.kerbalspaceprogram.com/entry.php/300-I-m-not-dead-nor-is-Mapsat-abandoned-and-also-a-blog!
  21. How do you mean day/night area's? those change constantly? I've been playing with colour maps for a while but haven't found a reliable way of doing it, I haven't had the chance to dig into 19.x much though so maybe I can do it now, it's definitely something I would like to see in Mapsat. I will check out MapMFD to see what you mean, I haven't dabbled in that because I didn't want to make Mapsat too much of a flight instrument but I'll take a look. -- Question to everyone, since I can't currently be the most active mod dev in the world lol, would you all like me to "blog" about development whenever I worked on it? So even if things take long and or have big pauses you have a better sense of my non-deadness and what's being worked on for mapsat and other mods? Something simple, like "hey all today I had some time to work on some performance tweaks" type updates, short and to the point. Let me know
  22. *coughs Hello, Camacha you can be assured Emee and I really spoke with each other. Everyone, sorry for my silence and stuff. No I'm not dead and neither is Mapsat. See: Not dead. Just dusty Analogue life just had priority for a while over my digital one. About Mapsat, I've resumed working on my new update that I've shown on occasion before. Atm I'm not satisfied with X4 to make it a public 4.0 yet, mainly performance balancing on the high res scanning and there are still features I would prefer to add before releasing it. My time right now is mostly taken up by "analogue" things though. But I'm back again and I am working to finish the long due update that got halted somewhere halfway. The current release seems to be working good enough on 19.x apart from weird "directly above ksc" lag. This is fixed in my dev build of x4. Turning off scanning during launches should alleviate the problem, there's no valuable mapping being done while launching so turning it off during that stage shouldn't affect your mapping. In the mean time for those who haven't replaced or let Mapsat rebuild the hilo.dat file and are having problems with new bodies you can get my "official" file here. https://dl.dropboxusercontent.com/u/49791830/ksp%20addons/hilo.dat Replace the one in plugindata/isa_mapsat . What else? em.. no I think that's it. I haven't backtracked the whole forum thread since I last was here so if there is anything pressing you want to ask me please do so. It's very late here, time for me to go to bed. Will check back more frequently again.
  23. That's odd I haven't touched those and didn't notice anything not showing when I tested it before uploading. Will look into it if I get the chance and that's why I really wanted to post a message and give a little heads up. I'm in a little bit of a jam. When I came home and turned on the pc my screen apparently decided to start it's death throes. It's currently very blueish tinted and I can hardly read the text on the screen, the on screen display menu shows garbage. Atm I can't afford a new screen so should it die you'll know why I'm absent completely and can't work on Mapsat or the other mod I wanted to have out this week. No clue when I could afford a new one, this is usually crunch time money-wise until summer :/ So my expectations of being able to replace it soon aren't very high. On the upside, at least this time you're informed as to why I'm not putting out updates, am not on irc and never reply here lol. Anyway just wanted to let you all know before the screen gives out completely. Nope I don't stop the running of mapsat if it's not active flight or anything, if you are close enough for the part to be spawned and it's script to run you'll just get mapsat showing up. E.g. if you put a mapsat rocket on launchpad and then leave it there, start a plane without mapsat on the runway, you'll still get the mapsat icon and everything. Once you fly away far enough it will disappear as the part on the rocket gets unloaded due to range (I guess)
  24. No shouldn't happen I haven't changed anything about the texture format. It adds a part, the dish is still there too and hasn't changed. Otherwise it only fixes filepath issues with macs.
×
×
  • Create New...