technogeeky

My understanding is that, right now, as of v6, the version numbers are: [TABLE=class: grid, width: 500] [TR] [TD]Name[/TD] [TD]Version Format[/TD] [TD](Example) Version[/TD] [/TR] [TR] [TD]MechJeb (Release)[/TD] [TD]v.v.v.0[/TD] [TD]2.2.1.0[/TD] [/TR] [TR] [TD]MechJeb (Dev)[/TD] [TD]v.v.v.b[/TD] [TD]2.2.1.244[/TD] [/TR] [TR] [TD]RPM[/TD] [TD]v.v.x.y **[/TD] [TD]0.16.???.???[/TD] [/TR] [TR] [TD]MechJebRPM[/TD] [TD]0.0.0.0[/TD] [TD]0.0.0.0[/TD] [/TR] [TR] [TD]SCANsatRPM[/TD] [TD]0.0.0.0[/TD] [TD]0.0.0.0[/TD] [/TR] [TR] [TD]SCANsat[/TD] [TD]v.v.v.v[/TD] [TD]1.0.6.0[/TD] [/TR] [/TABLE] where: v is a manually entered digit b is the build ID, generated by the Jenkins build process x and y are generated by the IDE at compile time ??? just means I did not bother to look it up [**]: In the AssemblyInfo.cs file, this would would look like: "v.v.*" or "v.v.*.*" where v are integers. As of now, RPM is the only one using compile-time-generated version numbers (SCANsat used to do this, and so did MechJeb a long time ago perhaps?) So, if you build RPM yourself, you will make a DLL with a version number whose first and second components you can predict, but whose third and fourth components you can not.

Correct me if I'm wrong, but couldn't you also call this part an Ullage Motor? It would also be a welcome addition to the RealFuels or RealIgnitions guys, or whatever. This competition is working wonderfully.

The next release will have a totally revamped "bottom of big map" section. This will include displaying of coordinates, colors, height color gradients, etc. As for anomaly coordinates: The ability to drop map markers should get you arbitrarily close (this includes the MechJeb landing reticle, if we do that). I don't think I want to display anomaly coordinates anywhere. There are a few reasons: it's a step closer to cheating; displaying none of their coordinates is easy; displaying all of their coordinates is easy; but displaying just some of them is hard (how do I track selection? clicking them on bigmap? they already seem to have alignment issues). But maybe. It should be easy to allow small map markers, so I'll check that out. It should be easy to do ground track on the small map. I may be interested in doing line-style ground track on the big map too, since having on the order of ten thousand dots to represent several orbits is quite taxing.

As promised, here is the final v6 release. The last feature to make it in was the big map caching. Which is awesome. DOWNLOAD SCANsat v6 (from GitHub) SCANsat v6 SOURCE (hosted by GitHub) This version, like all new versions, has a hardcoded version ("1.0.6.0", meaning SCANsat 1 version 6). Please also check out the new README. I have converted it to nice, link-filled, table-filled markdown. Please suggest fixes, changes, or additions. Unless this has any breaking changes, this freezes v6. All future features or bugfixes will be in v7 (or later). If everything is reported as good, and Mihara is able to compile against these official versions (please inform s/he to try and do so), then I will make a new thread inthe Showcase for the release version, and make a new thread in Development for us developers.

I have said and will stick by: v6 will be released this weekend. I may have to use some technicality to actually reach that goal (like, midnight PST even though I'm in EST), but I'll get it out tonight. It will not have the kethane resource views in. It almost certainly will have the cached bigmap in.

These pictures and my previous work make me think that the opacity of many of these overlays should be adjustable in the UI. Nice work!

From reading what he wrote, he has not decided yet. Also, many scanning satellites do look like Christmas trees with various parts slapped on them.

I finally check in after a lot more around-the-house work than I expected this weekend. Lovely work DMagic. Psawhn (who made the ideal altitude calculator) figures that you can replicate the correct swath width of the Kethane hexes by simply using an FOV (or was it swath width?) of 2.25. Or maybe a shade less, to handle the case where you are scanning between two Kethane grids. One other feature I would like to add ASAP is to represent the MechJeb landing target reticle on the SCANsat map. That way you could see not only which hex you are going to land in (important!) but also you could see what the slope is where you are projected to land. However, this may or may not be a dependency problem.

Thanks for this and the follow up post. I have thought about it, and I see only two routes that will let me develop as actively as I want without breaking compatibility. Strip the versioning from the assembly entirely, effectivelly setting it to "0.0.0.0" for all time. (BAD) Hardcode all four components of the version for each release, and store the development build in some other field (which is not checked by the PluginLoader -- like the description or the copyright field). In which case, I might use something like "1.0.6.0" I will not be be officially releasing a DLL with version number "1.0.5.32015" because that seems dangerous and silly. Except: I would like to release such a version to two or three people who are currently straddling SCANsat v5/v6rc2 with RPM, and who wish to help us at SCAN by telling us if indeed that method (hard-coding to the same version number) solves the problem. If you would (or anyone else) wants to verify that such a scenario works, please chime in and I will give you guys a link to a download in private message. To be safe, I should probably revert to an earlier build than my master, to get rid of part.cfg changes.

I have read and understood all of the arguments about what to do, and have made the decision to change SCANsat to having fully hardcoded version numbers. However, I do not accept that it is a good idea for me (after having released v6rc1, v6rc2) to manually edit the version number to be identical to that of v5 (the last damny release). First of all, it would be going backwards in version number (which is a horrible idea). But secondly, I have made changes to the part cfgs that I do not want to revert. I intend to release the official version of SCANsat this weekend. I hope that Mihara will be around to produce a new triplet of RPM, ssRPM, and mjRPM against my new release, before I release it -- so everyone can get the whole package, all at once. Thereafter, there won't be a problem. I won't be changing the version number on dev builds, so you will be able to use the latest dev build of SCANsat until I change the version number manually (which I will only do when breaking compatibility). I would ask that someone inform me if part.cfg changes are going to break savegames (or not). I think DMagic should be able to take a guess. I think he mentioned doing something with MM, instead of editing them. I'd be happy to revert the changes and do it that way, if it will guarantee that nobody's saves will get messed up. I suppose I could have tried it out on my career savegame, but I don't have any scanners on any vessels (I did kerbal recovery missions before switching back to development mode). - - - Updated - - - I have read and understood all of the arguments about what to do, and have made the decision to change SCANsat to having fully hardcoded version numbers. However, I do not accept that it is a good idea for me (after having released v6rc1, v6rc2) to manually edit the version number to be identical to that of v5 (the last damny release). First of all, it would be going backwards in version number (which is a horrible idea). But secondly, I have made changes to the part cfgs that I do not want to revert. I intend to release the official version of SCANsat this weekend. I hope that Mihara will be around to produce a new triplet of RPM, ssRPM, and mjRPM against my new release, before I release it -- so everyone can get the whole package, all at once. Thereafter, there won't be a problem. I won't be changing the version number on dev builds, so you will be able to use the latest dev build of SCANsat until I change the version number manually (which I will only do when breaking compatibility). I would ask that someone inform me if part.cfg changes are going to break savegames (or not). I think DMagic should be able to take a guess. I think he mentioned doing something with MM, instead of editing them. I'd be happy to revert the changes and do it that way, if it will guarantee that nobody's saves will get messed up. I suppose I could have tried it out on my career savegame, but I don't have any scanners on any vessels (I did kerbal recovery missions before switching back to development mode).

For scanning purposes, there are two methods that we could use: 1. Use the standard Kethane hexagonal grid, and incorporate that into a second fundamental type of scanning. 2. Use the same method that SCANsat uses for scanning and storing data, and use the fact that you can approximate Kethane scanners using a specific FOV/swath width. The honorable gentleman Psawhn has some Octave/Matlab code that does a rough job of calculating ideal altitudes for scanning Kethane, using the approximate method. Either direct inspection of the code, or evaluation of the output of the code versus the behaviour of Kethane in-game should tell us if the method will work or not. The general answer to your question is yes: if it's stored in the persistent file, then it is possible to use (and edit) all of the Kethane data.

Mihara: Starting with the next SCANsat release (and the first by me instead of danny), I will be assigning the version numbers by hand. I assume your decision to omit version numbers from your assemblies is a conscious one. I also assume that it has the effect of assigning the version string "0.0.0.0" to the assembly. I also assume that these two are equivalent. When and if I get a buildbot going for the dev versions, I will be leaving the build information in some other field (description? name?) so that they will be loaded correctly. I assume you want to be the one releasing the -RPM version of the dll. If this is not the case, please let me know. If I host it and release it, you can have commit access to it. In either case, I have the following questions: 1.) Is there a reason to/not to match the SCANsatRPM version to the hard-coded SCANsat version, or do you want to leave SCANsatRPM's version string undefined. 2.) Can I give you the release first by a day or two so you can build and be ready for a (more or less) simultaneously release? Thanks, -tg

Just add a boolean in some code that tracks when the user has pressed F2 (which is supposed to hide all UI elements). Then put an if statement check in the code that draws the text on screen.

Another person on reddit asked the same question. I can not say with 100% certainty that this is not related to SCANsat (yet, I may be able to figure it out with more information). But it's probably not related to SCANsat. Install KJR. The physics easing will correct this problem, no matter what is causing it. And it's probably KSP itself and/or something producing rounding errors.

DMagic: FYI, merged it all. Thanks!

This is a partial solution. This post contains a link to source code, which contains a planetInfos.txt file. This table contains everything needed to calculate whatever you would like (including sidereal rotation). This is not a great way to obtain this information (it could be wrong), but I think it's right. I would be interested to know where in the API you can get all of this, too. I don't know the name for what you want, but I assume you want to know the orientation of the planetary bodies at time = 0. The rotation rates are strictly constant (I'd expect), so once you know the initial configuration you know them all. But I have no clue what they would be.

See this post for some information that, if verified to be correct, can be imported in here. Namely, what is the role of assembly version numbers, if any, in rejecting our DLLs.

I will add, by the way, that there is an additional (but implicit) reason to do something like this: In Linux, the ever-present keyboard/mouse focus UI detection bug means that those of us who quickly click the left or right arrows, looking for our desired function, are also quickly clicking the scene rendered behind the MechJeb UI. This double click causes you to select No Target. In this case, it means I often (pretty much every time, until I notice and stop myself) will set the target, click to get to the right manuever type, and then have to re-click the target. It's not a strong reason, but it is a reason. (I also have all of the following keys unbound, because typing with them falls through: [1,2,3,4,5,6,7,8,9,0,.,] and maybe a few others.

sarbian: if you have time, please head over to this thread to discuss the set: [RPM, MJ, mjRPM, ssRPM, SCANsat]. I would like to establish known facts and/or tests to determine what role versioning and/or OS plays in this ongoing affair, and see what we can do together to ensure that we serve our open source customers in a way that is better for all of us.

I am the new maintainer of SCANsat. I do not have danny's permission, I have had no contact with him at all. Nevertheless, the software is open source and I am willing and able. I don't think it is even necessary to contact him to ask (since his M.I.A.-ness has been established) but I would be happy to do so. So I have been releasing release candidates in the hopes of getting a version out there which at least 2 people have confirmed works in every way I expect it to work (which includes RPM, and the exporting of any attributes that you see fit to need, to make any improvements you want). Please head over to this thread in General Add-On Affairs so we can work together to see if there is an acceptable solution to our module loading needs, or if we need to petition the Squad squad to help us so we can active, modern-day open source developers who have fast build cycles. I do not have to worry about MechJeb (though I use it), because I have no reason to reference it when compiling to build SCANsat (or SCANsatRPM, for that matter). I agree with you that, in principle, .NET/C#/Mono/whatever, should not even care about version numbers in the assembly.cs files of our various projects. (The argument is that none of us are strong-named, so assembly version numbers do not matter). I think there are two outs to this: 1. Squad can choose to do whatever the hell they want, using any information available to them (though they may ultimately have to call some .NET module to load an assembly eventually) 2. This page (MSDN) and this page (blogspot, ref. from stackoverflow) seem to imply that there are three version attributes (whose response to our three current version strategies of (RPM,mjRPM,ssRPM = no versioning), (SS = 1.0.*.{random} ), and (MJ = arbitrary (all four assigned manually)); whose response to these choices for all three attributes we do not know in the case of .NET, nor do we know in the case of Squad. I am willing to do literally whatever is best, but I want to be able to have people use dev builds of MechJeb and dev builds of my mod. If that means that we figure out this versioning nonsense, then fine. If that means I have to re-write the whole damn SCANsat plugin using some reflection or wrapper or some other mildly annoying (but performance retaining!), I will do that too. I am on Linux, by the way, so we might be able to come up with a protocol to test these things and verify that they work consistently on both platforms, before getting out pitchforks and demand^h^h^h^h^h^h humbly petitioning Squad to help us.

This is the most helpful thing I've yet seen. Mihara and I should work together on this problem, I guess. I don't know if there's a difference yet, but I play and develop in Linux, and he in Windows. Anyway, let me think about what I have read by Mihara and .NET docs (which seem to agree: nobody in KSP land seems to use cryptographic signing on their modules, so version numbers are not involved -- though I think there might be two separate loopholes to this). I'll reply in the new thread in Add-on Requests and Support or whatever that sub-forum is called. Thanks.

I can try and build and release all three (four?) packages myself. I don't think I should need to build MechJeb myself. But again, that only solves the problem for a day. - - - Updated - - - I'm hurt that my beloved SCANsat is at the bottom of your list. j/k. I only adopted SCANsat.

I will step in here. I am stuck in limbo right now. I have so far only made SCANsat release candidates. This is because, so far, there have been problems with every one of them. The problem with v6rc2 is that I built SCANsat and SCANsatRPM myself, but did not build MechJebRPM (or MechJeb itself, for that matter) myself (nor did I include it anywhere in the references for anything I built). I don't understand what is happening to reject these builds. My outstanding questions are: 1. What is deciding that these builds are incompatible, and on what grounds? Is this the role of 'assemblies'? Is it KSP itself? Is it RPM itself? 2. Are there error messages (in KSP.log or the more detailed log file whose name escapes me) when one or more of these DLLs fails to load? Or do we really just do an IVA and see nothing on the screen? 3. What is actually happening when the RPM, SCANsatRPM, and MechJebRPM assemblies are built without any version information in the assemblies? Does a random version number get generated? Does it get assigned a version number like 0.0.0.0? 4. Is some piece of software reverting to comparing a hash (MD5? SHA?) or checksum of these DLL files to determine they are invalid? If this is the case and it can't be avoided, then we might very well be doomed. I simply can not accept that the "proper" solution is to mechanically build every single permutation of the versions of: RPM, ssRPM, mjRPM, and MJ. That would be an absurd state of affairs. This 'limbo' I'm stuck in is worse than that. I don't want to make an official release (v6) of SCANsat (which now includes SCANsatRPM, thanks to this issue) until I know that it will work with the above trio. But evidently (as DMagic et. al. argue), the proper thing to do is make the v6 release and let the RPM developers target my official release. I do this, but then the very next day I'm sure there will be a bug in my official release. Or one of the new features we are working on will be released, and we'll be back in this situation. I feel like we need a C# expert to help us here.

There are two reasons I think it might be good to collect data: 1. For RemoteTech users who have incorrect or otherwise failed relay networks. 2. For interacting with new add-ons which "automatically" (how?) collect data and store it in the capsule. I haven't looked at any yet. I'll look at your changes tonight and incorporate them. I have a private branch with caching support enabled. I am testing your solution and my solution in isolation to see if there are performance differences (there are no visible differences).

It makes me wonder if: 1. SCANsat is responsible for actually having a version number (that is automatically changed/assigned) or 2. If all of the RPM libraries are responsible for *not* having a version. Perhaps this is forcing them to fall back to comparing hash values of the DLL or something silly.