[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[technogeeky]

Had same problem but then remember had to click open map on the MapTraq part which, I added to my probe cores so just clicked on probe core and open map and all good now scanning in background.

Aha! I didn't see this before I responded. Perhaps I am vindicated (though, perhaps not).

I haven't ever tried multiple vessel scanning. Shame on me!

[Mecripp]

LOL all good so far, I haven't found a bug in your v6rc all is working like it should or as thanks for all the work and time for those who pickup mod's and help keep them up to date.

[DMagic]

DMagic:

Can we sync whatever is necessary to get both of us developing from the same master (ie, mine)? I presume that will mean adding back whatever is necessary to the .csproj and .sln files for you to build. I also converted everything to Unix-like line endings, and I think such a change will persist normally.

You mentioned that you didn't expect to be able to debug and/or profile with ksp-devtools and Visual Studio, but I think you should be able to (without Professional, even). The worst case scenario is that you would have to use MonoDevelop for such things (which is a pretty bad case). But I was able to get profiling results (which I'm told actually do represent complete time intervals, and not just number of function calls -- modulo the RTDSC inaccuracies and recursive functions). And I was able to get the debugger working, and to add breakpoints and watches.

OK, I'll have to look into all of this more.

For now I've been able to build fine, there were just a few things I had to change. I had to remove SCANdebug altogether and redirect the references. The toolbar reference actually shouldn't be included at all. SCANtoolbarwrapper takes care of everything that Toolbar needs so the reference to the .dll and the using directives should be removed. After I set it to release it compiled fine. So it works fine for the quick testing I've been doing, but obviously I'll need to check into getting things working properly.

I forked your Git repository so at least you can see exactly what I've been doing (a 4D array to cache values for the big map seems to working ok so far).

I also want to do something to automate a few other processes (though I'm unsure exactly how to do them, but I think it's a good idea):

---

The standard crafts and scenarios are great ideas, it shouldn't be difficult at all to setup, really all that should be required is a save file and to point the loading plugin at that file when debugging. Imgur albums are the easiest way to setup initial posts, that way you can just update the album without needing to edit the post as well.

As for what I'd ask you to do most urgently... Either:

---

I will note that it seems to be mandatory that I have the target directory of the SCANsat project (but not necessarily the .sln) be my GameData\SCANsat folder for debugging to work. I haven't tried symlinks for this scenario (though I suspect they would work) -- but I don't even know if I know enough Windows junction to setup a similar situation in Windows.

I see, I switched off local copy and now I think building it directly in the GameData/SCANsat folder works fine. Normally I start KSP with a .bat file that just copies over the .dll, but your first method seems to be working.

You are the more experienced developer here, so tell me what I should/shouldn't do and what I can change to be most correct. But I would really like to be able to directly use git to directly import your code and changes (like, for example, your bigmap caching attempts). So far, I have done everything manually because of differences in these things (and in differences in Line endings). (Another reason for me doing things manually is because some of your changes were whitespace-only changes that despite all my attempts did not fall out the diffs.)

Thanks,

tg

I may know a bit more about KSP specifically, but my programming skills are pretty limited.

The git fork I setup should give you an idea, but I need to setup VS's autoformating so that it doesn't keep shifting things onto different lines when I don't want it to, that kind of stuff can make it hard to see exactly what has been changed.

VS doesn't seem to have a good way of always using Unix line endings, but it can be set manually (and seems to require resetting it every time I save) so that at least the final update for whatever I'm doing can be saved correctly.

I'll try looking into all of this stuff more thoroughly to try and figure out what we need.

[technogeeky]

OK, I'll have to look into all of this more.

For now I've been able to build fine, there were just a few things I had to change. I had to remove SCANdebug altogether and redirect the references. The toolbar reference actually shouldn't be included at all. SCANtoolbarwrapper takes care of everything that Toolbar needs so the reference to the .dll and the using directives should be removed. After I set it to release it compiled fine. So it works fine for the quick testing I've been doing, but obviously I'll need to check into getting things working properly.

I forked your Git repository so at least you can see exactly what I've been doing (a 4D array to cache values for the big map seems to working ok so far).

The standard crafts and scenarios are great ideas, it shouldn't be difficult at all to setup, really all that should be required is a save file and to point the loading plugin at that file when debugging. Imgur albums are the easiest way to setup initial posts, that way you can just update the album without needing to edit the post as well.

I see, I switched off local copy and now I think building it directly in the GameData/SCANsat folder works fine. Normally I start KSP with a .bat file that just copies over the .dll, but your first method seems to be working.

I may know a bit more about KSP specifically, but my programming skills are pretty limited.

The git fork I setup should give you an idea, but I need to setup VS's autoformating so that it doesn't keep shifting things onto different lines when I don't want it to, that kind of stuff can make it hard to see exactly what has been changed.

VS doesn't seem to have a good way of always using Unix line endings, but it can be set manually (and seems to require resetting it every time I save) so that at least the final update for whatever I'm doing can be saved correctly.

I'll try looking into all of this stuff more thoroughly to try and figure out what we need.

I was worried about the line endings. I am totally happy to switch back to Windows line endings uniformly. I have three possible settings: Always Unix, Always Windows, and Leave As Is.

As long as I don't use Leave As Is (which is what I was doing), I'm happy.

So since that's a trivial thing to me, and it will make your life easier, I will uniformly move to Windows line endings in my next master.

[Mecripp]

Got 1 little bug the maps don't show in RPM's

[DMagic]

TG: You should probably put a disclaimer about RPM in all of your release posts.

RPM is not going to work with anything but the v5 release until a more official update is made available.

[technogeeky]

TG: You should probably put a disclaimer about RPM in all of your release posts.

RPM is not going to work with anything but the v5 release until a more official update is made available.

In the words of Capt. Jean-Luc Picard:

Made it so.

[4nxs]

Technogeeky and DMagic, thanks for continuing the development of this mod. This was one of the first I used and adds a whole new level gameplay for me.

Just felt I needed to say something..

[technogeeky]

Technogeeky and DMagic, thanks for continuing the development of this mod. This was one of the first I used and adds a whole new level gameplay for me.

Just felt I needed to say something..

Your appreciation has been noted and will be forwarded to the relevant authorities.

[DMagic]

This caching idea is looking promising.

All three map types use elevation data, so it's only necessary to cache the terrain height data once for each projection type.

You can build the map once, with grey or color mode, it doesn't matter, in any of the three map types (elevation, slope, biome) and it caches the terrain height data. This drops the time by around 50% for building or rebuilding any of the other map types and more importantly doesn't have so much of a framerate hit.

The best way to run it, I think, is to find a big map size that you like and stick with it. If you are constantly re-sizing the map this won't make much of a difference, but if you stay with one size it should help a lot.

The memory implications don't seem too bad. For a totally insane 4000*2000 pixel map (that's bigger than full screen on a 4K monitor) this would require 4000 * 2000 * 3 32bit values, which comes out to 96MB, which is a lot, but that's a ridiculous map size. A more reasonable, but still huge map of 2000 * 1000 pixels comes out to 24MB. And something more realistic, like 1000 * 500 comes out to 6MB. Maybe there's some overhead that I'm not accounting for, but this seems like a reasonable trade off for the increase in performance. Maybe some kind of warning could be triggered when the map is stretched above some limit.

The biome map has some issues that need to be worked out, but it looks good so far.

[biohazard15]

Alright, using v6rc1.

No button is actually OK (I never liked it - because I prefer to have MJ windows in upper left corner, and I don't use toolbar), but can you make "Open SCANSat menu" as a right-click option for SCANSat parts?

[Tiron]

TG: You should probably put a disclaimer about RPM in all of your release posts.

RPM is not going to work with anything but the v5 release until a more official update is made available.

Actually...

You just have to compile RPM yourself with the references updated to the newer version of the .dlls. And at least in my case, ten of the 'Orbit'-s changed into 'orbit'-s (I get fits over missing reference if they're capitalized, I have no idea why.)

[DMagic]

You just have to compile RPM yourself with the references updated to the newer version of the .dlls. And at least in my case, ten of the 'Orbit'-s changed into 'orbit'-s (I get fits over missing reference if they're capitalized, I have no idea why.)

Yeah, that's true, I put some very basic instructions on how to do this 5 or 10 pages back. The process is extremely simple if you already know what you're doing, but baffling if you don't.

So unless you already know how to fix the problem it's probably best to stick with version 5 until a more complete update is released and RPM can officially be updated.

[Virtualgenius]

Will there be an official release soonish as I really like this mod and cant wait for version 6

[Tiron]

Yeah, that's true, I put some very basic instructions on how to do this 5 or 10 pages back. The process is extremely simple if you already know what you're doing, but baffling if you don't.

So unless you already know how to fix the problem it's probably best to stick with version 5 until a more complete update is released and RPM can officially be updated.

Absurdly simple. At first I was trying to figure out how to get Dev Mechjeb to compile (the version number as specified in the files isn't changed with each new commit, the automated buildbot does it, so if you build it yourself it'll have the same version number as the last release), but RPM was much easier to get it to go... MUCH easier. New dev mechjeb came out and I decided to try V6r1 scansat at the same time. Works a charm.

I should really put the dependencies where they're supposed to go so I don't have to reset them every time I update RPM, but meh.

[technogeeky]

Will there be an official release soonish as I really like this mod and cant wait for version 6

I won't lie and say I'm going as fast as I can, but I am going as fast as I can modulo real life and my weekend attempt to rescue stranded Kerbals.

I'm switching to dev environment right now and will get to work!

[technogeeky]

Absurdly simple. At first I was trying to figure out how to get Dev Mechjeb to compile (the version number as specified in the files isn't changed with each new commit, the automated buildbot does it, so if you build it yourself it'll have the same version number as the last release), but RPM was much easier to get it to go... MUCH easier. New dev mechjeb came out and I decided to try V6r1 scansat at the same time. Works a charm.

I should really put the dependencies where they're supposed to go so I don't have to reset them every time I update RPM, but meh.

Is this something that I could easily do and distribute with SCANsat itself? I'm happy to build anything, especially if it's easy. I already use dev versions of MechJeb.

I'd like to be able to say "v6 works with RPM" without any hesitation; if that can be done faster by doing something on my side rather than asking others to do it...

[Mecripp]

Is this something that I could easily do and distribute with SCANsat itself? I'm happy to build anything, especially if it's easy. I already use dev versions of MechJeb.

I'd like to be able to say "v6 works with RPM" without any hesitation; if that can be done faster by doing something on my side rather than asking others to do it...

If you haven't seen, I think there talking about this post http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=1089874&viewfull=1#post1089874

and

http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=1090391&viewfull=1#post1090391

[technogeeky]

If you haven't seen, I think there talking about this post http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=1089874&viewfull=1#post1089874

and

http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=1090391&viewfull=1#post1090391

I clearly remember the first (I'd be a fool not to read all of DMagic's SCANsat posts!), and only vaguely remember the second.

I'd need to know the licenses for SCANsatRPM and RPM, but if they are logically compatible, I could just release the SCANsatRPM file in v6rc2 (and obviously in the real v6, assuming I do it right). That would solve the issue entirely. I don't think I would need to modify the references for SCANsat itself (otherwise, why would they be doing this mod <-> mod+RPM <-> RPM business anyway?). So I would just do one additional build and include the .dll in the distribution.

[Tiron]

I clearly remember the first (I'd be a fool not to read all of DMagic's SCANsat posts!), and only vaguely remember the second.

I'd need to know the licenses for SCANsatRPM and RPM, but if they are logically compatible, I could just release the SCANsatRPM file in v6rc2 (and obviously in the real v6, assuming I do it right). That would solve the issue entirely. I don't think I would need to modify the references for SCANsat itself (otherwise, why would they be doing this mod <-> mod+RPM <-> RPM business anyway?). So I would just do one additional build and include the .dll in the distribution.

It's some problem with a 'module that will not be named' bug or somesuch? I forget. Something about the way KSP works when one plugin calls functions from another one. Apparently, it only works with the specific version of the plugin you compiled yours with. But from what I read, it's linked to the version *number*. Apparently, the dev versions of mechjeb used to be drop-in replacements until the buildbot started auto-incrementing the version numbers.

The problem is, this applies to the RPM plugins too. I have no idea why, but when I build them myself I get a slightly different build number than the official release, even if I build from the official release's source. This prevents just rebuilding say, SCANSatRPM.dll and dropping it in. You have to build all three RPM plugins to get them to work with each other.

It's not hard: the source comes with .csproj files for the three dlls and a .sln for the overall set. When I try to compile it, I get 10 build errors: something something.Orbit.something commands to mechjeb that come up with an error along the lines of 'mechjeb doesn't have an 'Orbit' thing, wtf you talking about'. Changing '<x>.Orbit.<y>' in those lines to '<x>.orbit.<y>' leads to a successful build. No idea why.

Other than that, all it takes is making sure it can find the three KSP .dlls it needs, plus the versions of SCANSat and Mechjeb you want it to work with.

If you could figure out some way to get the SCANSatRPM.dll to build by itself with the same version number as the official release, it might work as a drop-in, though...that's the impression I get, anyway. Otherwise, every time the version number on the SCANSat.dll changes, it'll break compat until the whole thing is recompiled. Or some such garbage.

There's some way to integrate into RPM directly without going through a special plugin, which Vesselview does. No idea what it is, but I gather it doesn't have any of these problems, so that might ultimately be easier than custom-rebuilding RPM each time MJ or SS updates.

Edited May 2, 2014 by Tiron

[DMagic]

I'd need to know the licenses for SCANsatRPM and RPM, but if they are logically compatible, I could just release the SCANsatRPM file in v6rc2 (and obviously in the real v6, assuming I do it right).

It's released under GPLv3, which I think is compatible with SCANsat's 3-clause BSD license (and the license for CLZF2).

For now all it requires is recompiling RPM from its source using a reference to the updated SCANsat.dll; both the SCANsatRPM.dll and JSI.dll need to be replaced. Of course, this might not always be the case. But as long as nothing else is required to get it working it would probably be ok to include an alternate version of RPM. Though I would very strongly warn people not to go complaining in the RPM thread if things don't work, that might cause problems.

[Mecripp]

It's released under GPLv3, which I think is compatible with SCANsat's 3-clause BSD license (and the license for CLZF2).

For now all it requires is recompiling RPM from its source using a reference to the updated SCANsat.dll; both the SCANsatRPM.dll and JSI.dll need to be replaced. Of course, this might not always be the case. But as long as nothing else is required to get it working it would probably be ok to include an alternate version of RPM. Though I would very strongly warn people not to go complaining in the RPM thread if things don't work, that might cause problems.

Do you need to add the MechJeb2RPM in too ? if so guess the stable 1 from spaceport as last, I heard the dev don't work with RPM.

[BudgetHedgehog]

Do you need to add the MechJeb2RPM in too ? if so guess the stable 1 from spaceport as last, I heard the dev don't work with RPM.

Just so you know, OrbitalDebris is recompiling RPM to work with the dev builds of MJ pretty much as often as sarbian can push new dev builds of MJ. Might be worth talking with him/nicking his dlls.

[Mecripp]

Just so you know, OrbitalDebris is recompiling RPM to work with the dev builds of MJ pretty much as often as sarbian can push new dev builds of MJ. Might be worth talking with him/nicking his dlls.

Thanks didn't know that.

[goldenpeach]

Is it normal that there is no legend for the slope(I was in the big map and, yes, I activated the legend)?

The legend appear without problem for the altitude.