Cyrik

err, i´m not even sure if my overlays works with rss:) other then that, the maps resource maps aren't actually part of this mod. they would be in karbonite/mks, but i´m guessing it would be better to try asking in the ORS thread since they(wave right now) would have to scale the maps incoming from other mods.

check out https://github.com/angavrilov/ksp-devtools i just havent tried it yet since you need to use monodev with it and i love love love visual studio, but once i have 30 mins i´ll give it a go

ok so if i ever manage to get my lon/lat math sorted i´ll make it optional to generate a high map cache and will do it the slow way by default having to restart ksp and debug with log messages is really starting to kill my enthusiasm

yes i already told him and posted to the firespitter thread. there´s nothing b9 can do. i haven´t studied the firespitter code in enough detail to check if its possible to fix, but i would bet it is. otherwise any mod using it is gonna have problems with on rails stuff, not just transfers. imagine a karbonite drill loading before the tank, writing the new resources to the tank and then when the tank loads it pretty much empties it again:/

Hi, we´ve been having problems with B9 and MKS Logistics compatibility and I´ve hunted down the problem to the FSfuelSwitch partmodule. The issue: mks logistics sends stuff from one ship to another and changes the others resource node if it is on rails. FSfuelSwitch however ignores the resource node when the craft goes active and overwrites it with a value it saved in its own node. Would it be possible for you guys to not do that? The way it is now it breaks compatibility to any plugin that does anything with on rails resources and will lead to very strange and hard to find bugs.

I just checked, its not crossfeed. its firspitter, specifically FSfuelSwitch. It deletes the Resource node every time it loads a craft and puts a new one in from its own config:(

mhh yeah, didnt think about more then one planet. well the good thing is you can generate it on the players pc, so you dont have to bundle it with the addon. harddrive space is cheap:P filling 350mb of it wouldnt be the end of the world. just need to test how slow it actually is to generate 3mins to generate the file for kerbin. not as bad as i had feared

ok, so a long lat map in binary format with 0.1 accuracy would be 50 meg. do you guys think thats acceptable? generating a detailed slope map from that would be sped up by a lot though, i think. gonna put it in for a test run:) maybe, i dont know. this is the first time i do anything with graphics. i´m just a lowly programmer

i think we would have to test it. having it in a texture compresses it more but you would have to do more calculations to get the data out. you are trading space for cpu time. keeping either in memory is a bad idea anyway unless they aren't very detailed. a file might be the best way though now that i think about it. you could format it in a way where you can just read a few specific lines if you are doing continues updates or you can read through the whole thing and dump it again if you build up your whole thing, the way my overlays do it.

looks decent to me, but i´m very open to improvements. btw right now you can change the accuracy on the fly and you have to set the max slope yourself, since i dont want to calculate everything twice to find the max slope to divide by:P yeah saving it would be great but then i´d have to force 1.0 accuracy and thats a bit large for planets. the best way to read a texture/file a few pixels/lines at a time, but that only works if you don't need the values often. it would kind of work for me, not for scansat though, unless you want to slow it's display speed down by a lot

I´ve got the first version working. And you are right, there's problems with it, but i think its still kind of useful. You don't actually need a height map before hand, since this "body.pqsController.GetSurfaceHeight(rad)" gives you a decent value for any point on the surface. Well I guess you could say that is the height map:) Anyway, in my first attempt i´m calculating the slope for every lat/long by taking a measurement 0,5 lat/long in 4 directions away from it. It takes around 10 sec to calculate the whole thing sadly. I´ll upload a picture in a sec. BTW the slope map by itself is just a curiosity I guess. It starts making sense when you combine it with a resource map like rover suggested. That way you could see if that space you with the high resource could is sloped like crazy so you don't want to build there. When you combine the values by dividing the resource map by the slope you might get something usable. Thats the next thing I´ll try once slope map is in releasable shape

sounds like a good idea. I´ll start working on the slopes overlay first since it would be needed anyway and has already been requested

Ok since there i no more feedback, I guess I´m done with this mod. Just kidding, theres a new release with an anomaly overlay and individual cutoffs for resources and lots of small stuff. Seriously though, i need some feedback to know what I should prioritize.

now thats a great name, not sure why we have things like fuel:)

just to chime in: the only thing thats dependent on karbonite/mks right now are the initial configs. if you add your resource to the base.cfg file it should automagicly get a button and thus an overlay. i´ll be removing even that dependency once i´m sure most people have ors 1.2 installed, since it exposes a list of ors minable resources and i dont need to specify it in a .cfg file. tldr: remove mks/karbonite from Base.cfg, add your resource and you are done.

ouch, your first idea is possible, but a lot of work. mostly because right now i can only display colors on the overlay, not textures. if i ever get around to putting textures on it for a feature that more people would use () you can bring it up again. then it would only be a matter of seeing if the mod in question has a decent interface to get at it. slope overlay is something i want to build anyway. its just a bit more complicated since there is no api for it and i dont want a hard dependency on scansat. i´ll see how scansat builds its slope map, but the feature is not very high on the priorities list, since it would be more of a gimmick then actually useful for the game:)

great feedback, thank you for the effort! now to your specific points: - i will look into the orbit/overlay thing today. i´m not sure if its fixable. might have to lower the alpha so that you can see through:/ - its intended for both to be active at the same time, i just forgot to make them interact in that case:) - log(0) gives explosions:) gonna fix that - more visual feedback on the buttons incoming next update, just for you:) - yeah the displacement is a visual thing:/ the tooltip gives you the exact mouse coordinate at the planet, the overlay is a bit higher, depending on the highest mountain. not sure what to do about that. i could make the tooltip depend on the overlay sphere instead of the planet, but i´d rather keep it as accurate as possible. if anyone has ideas for a fix, i´m open to them! - nearly forgot: tooltip disabled below cutoff. would need more peoples feedback on this. i like that i can always check with the tooltip, even if its below the cutoff, then again, i havent played the game since i started modding... - yes, someone suggested it, but its good to remind me. i sometimes forget feature request. if i dont say no to a request just poke me once in a while so i dont forget. or even better, make an issue on github so i have to deal with it:) - yes, i can make an anomalies overlay. not sure if i want to, since the scansat one better looking then an overlay would be, but i might as well throw it in for people who dont use scansat thank you! even if i had to google fractally while i´m at it: the colored scale goes through these colors: xkcd_ArmyGreen, xkcd_Yellow, xkcd_Red, xkcd_Magenta, xkcd_White, xkcd_White if you have a better idea, let me know. this one has been stolen from scansat

ok, i´m dead and going to bed, but first you get a new vesion: science overlay is now way faster, so its actually usable without going crazy 3 different scalings for resources, try them, tell me if you like em:)

ok soooo, its not actually that slow to run through the map once and finding the highest value:) next version you will have 2 options: colors linearly scaled from 0-255 starting at the cutoff. so 0 would be the cutoff and so on. second option would be to logarithmicly scale it from 0-255 starting at cutoff. hope this helps everyone, otherwise i´ll throw more stuff in there:)

right now it is, mostly because i havent found a good way to find the max or average value for a resource. i´ll try just running through it twice to see if it slows down too much, if it does i´ll have to build a config file for every planet/resource combination

not that anyone doesn't use blitzy's toolbar, but the next version will be independent of it, yay:) + i´m using CaptRobaus new icons. working on getting science overlays to load faster for now, until someone tells me to do something different:P

new release is out. ors is now optional and version independent, unless it changes a very specific part of its API. otherwise the science overlay was extended but still slow:/ there are now 2 configs: Base.cfg shouldn't be touched. this is where i change the starting config. if you touch it, it will get overwritten in the next release. MapResourceOverlay is the config that you can change by hand or ingame. it wont get overwritten in new releases, hopefully:) poll: should i work on the ui, making the science overlay better, giving more options to tweak or adding more overlay types?

yes. if i dont get around to making it independent, i´ll make it depend on the newest one. if i do make it independent it should work with any new version of ORS unless ORS changes the definition of this single method: ORSPlanetaryResourceMapData.getResourceAvailabilityByRealResourceName()

In my case i was playing around with having the remote one at github or somewhere else. thats why the github one was pointing to somewhere else, so i could make the switch in the following version. Its not a big deal, was just surprised that it matters at all where the remote one is pointing and even more surprised that it has to point to itself to work at all. I guess it doesnt matter if you dont have the version file inside your version control system. might be a stupid place for it anyway:)

I think the way my vision for this is changing right now. I really like the way the science overlay is shaping up and i would hate for people to miss out on that part because they arent using ORS. So I think sometime in one of the next few versions I will make ORS optional and will just search for it. If its there you can do all the resource stuff, if its not you can do all the other stuff anyway. It would basically work the same way SCANSat integration is working right now. It would even get rid of the version dependency, so I might just put it into the next release.