technogeeky

I do understand the sentiment, but it seems silly overall. I feel like I'm always going to be using a dev build of either MechJeb or SCANsat for all of my life. Why can't we just compile a DLL that doesn't care about versions? Or why can't we actually use versioning information to say that anything with the same Major.Minor.*.* should be tried. This whole -- things just not working with no explanation is bizzare. I wonder if there are any errors in KSP.log (or that other, more detailed one) that say what is happening? Can someone who is having that problem please take a look? I suppose I am having the problem with MechJeb (though I don't even know if I have MechJebRPM installed... silly me)

I did not compile RPM.dll or MechJebRPM.dll myself to release it, so I couldn't have matched them. Plus, I'm behind on dev builds. This situation is really grim, though. There is no way it's reasonable to ask someone to build against this many targets. Surely there is an explanation how version checking is being done here. I need to find more documentation about assemblies and DLLs and versioning. I mean, don't get me wrong -- I'll be happy to build whatever and release whatever to make sure it works for the most people. But there are new dev builds of MechJeb nearly daily. And there is no reason to suspect that each new dev build of any of these things is going to break anything. We need to loosen the version restrictions going on.

Note: I do not expect this comment to help your situation, but perhaps it will help us devs figure out how to stop this version mismatch nonsense. I don't see where this compilation-target mismatching is happening. The (primary) source code of SCANsat and SCANsatRPM do not have version numbers encoded them. However, the assembly file of SCANsat does: // The assembly version has the format "{Major}.{Minor}.{Build}.{Revision}". // The form "{Major}.{Minor}.*" will automatically update the build and revision, // and "{Major}.{Minor}.{Build}.*" will update just the revision. [assembly: AssemblyVersion ("1.0.*")] The assembly file of SCANsatRPM does not even declare an AssemblyVersion: using System.Reflection; using System.Runtime.CompilerServices; // Information about this assembly is defined by the following attributes. // Change them to the values specific to your project. [assembly: AssemblyTitle("SCANsatRPM")] [assembly: AssemblyDescription ("RasterPropMonitor / SCANsat interface plugin for Kerbal Space Program")] The assembly info for MechJebRPM: using System.Reflection; using System.Runtime.CompilerServices; // Information about this assembly is defined by the following attributes. // Change them to the values specific to your project. [assembly: AssemblyTitle("MechJebRPM")] [assembly: AssemblyDescription("RasterPropMonitor / MechJeb2 interface plugin for Kerbal Space Program")] And lastly, the assembly for RPM itself is similarly terse: using System.Reflection; using System.Runtime.CompilerServices; // Information about this assembly is defined by the following attributes. // Change them to the values specific to your project. [assembly: AssemblyTitle ("RasterPropMonitor")] [assembly: AssemblyDescription ("RasterPropMonitor plugin for Kerbal Space Program")] I suspect this is an intentional decision on Mihara's part (to remove all of the version declaration). The assembly file for MechJeb is more complicated, but it appears as they are doing what I thought might be a good (bad) idea. using System.Reflection; using System.Runtime.CompilerServices; using System.Runtime.InteropServices; // General Information about an assembly is controlled through the following // set of attributes. Change these attribute values to modify the information // associated with an assembly. [assembly: AssemblyTitle("MuMechLib")] [assembly: AssemblyDescription("")] [assembly: AssemblyConfiguration("")] [assembly: AssemblyCompany("Multiversal Mechatronics")] [assembly: AssemblyProduct("MuMechLib")] [assembly: AssemblyCopyright("Copyright © Multiversal Mechatronics 2014")] [assembly: AssemblyTrademark("")] [assembly: AssemblyCulture("")] // Setting ComVisible to false makes the types in this assembly not visible // to COM components. If you need to access a type in this assembly from // COM, set the ComVisible attribute to true on that type. [assembly: ComVisible(false)] // The following GUID is for the ID of the typelib if this project is exposed to COM [assembly: Guid("a903d9fe-4604-47b8-b9d9-95728538f769")] // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("2.2.1.0")] [assembly: AssemblyFileVersion("2.2.1.0")] I say good/bad, because the good is it might allow us to make builds which work better -- but bad, because we have to remember to update the hard coded versions. If the issue of this not working is actually because C# / Unity / Mono / whatever is checking hash values of various .dll files, then we're probably never going to get around this kind of dependency hell (unless, I suppose, we do whatever the Toolbar guys are doing and write a wrapper).

Can you point me to Maptraq MM? I assume you mean that small cell-phone looking thing.

Assuming everything checks out, are you OK with me including this sensor into the SCANsat package?

OK. I have pushed all of my changes into my master/v6. This includes a bunch of (trivial) reorganization and re-ordering of methods to suit categorization. Unfortunately, it also includes me running two custom commands (in a shell, no less). I am certain these will not work in DOS, so please beware. If there is an equivalent DOS command and you want to do it that way in general, let me know. I think the line endings should all be Windows style now (yay!) I also have the assets inside the project (and the github repo) -- except the part.cfgs are end in .ignore, to be ignored by the game. I have made all the appropriate changes to the part.cfg files. I have not made any gameplay-affecting changes. And I'm done for the night. As usual, not much done, but it's something. edit: And I've changed the multispectral scanner to be easily clickable.

I had already implemented that (or something similar: check that the values are != 0, and compare best/min) before you posted. Great minds think alike for nearly trivial things

Yeah. I think actually the ideal situation is to report the *effective* FOV (if possible) for each of the three altitudes. That way they can see, at-a-glance, that there is a boost above best, and a penalty below best. But I certainly agree with your suggestion and will implement it. And yes, the MapTraq scanner is looking more and more like it should be removed/deprecated/MM inserted into all pods.

I have before, and I again tonight glanced at your generalized science mod thing. Should I convert these part config files to use it? If the answer is yes, should I do it now (high priority) or later? I'm sorry I haven't had time to pay anywhere near similar levels of attention to your mods (though I used the **** out of your science experiments to farm precious data in both of my careers so far).

Here are some screenshots of my first attempts to add the relevant information to the editor (right click for extra information) window: edit: I delete this album because it was easier than deleting the images in it. Someone else please approve this choice as sensible (or not), and let me know. I expect to include this in the mythical v6rc3.

I think I just had a good idea. We can solve many of these problems and make the game more realistic easily by doing just one thing: Make the: minimum, maximum, and ideal altitude tweakables (with sensible bounds). This is exactly what one would do (in a loose and generic sense) in real life. You would have a general satellite design that you would make for some orbit around some planetary body (or Lagrange point). And you would decide what kind of orbit you determine to be 'ideal' (the one you choose to put it in, silly) , and then you would adjust the general design accordingly. 1. This would let users know what the altitude limitations are. 2. This would let them set their own ideal (the sweet spot configuration chosen by the user); but penalize them for putting it closer (or further away, if it's appropriate) 3. This would make each sensor need to be slightly tailored for each planetary body you wish to scan. This means you will want to scan the Mun (or Gilly, or whatever) with slightly different configurations than with Kerbin. 4. The specific configuration could be used to determine the power usage (higher ideal and/or max might require more power (inverse square falloff?)). 5. There are some other advantages I thought of, but forget now... Anyway, I think generically this is already supported (since the .dll reads these values from the part.cfg files) -- except that I'd have to add tweak ability or whatever. edit: I was looking for GetInfo.

Among other things, I'm bringing all of the GameData files (MapTraq, Resources (science defs.) Scanner 1, Scanner 2, Scanner 8, Scanner 32) into the solution (and also into git). While looking at the part.cfg files for SCANsat (to add scanning altitude descriptions, as was requested and I think nice), I noticed that Scanners 1,2, and 8 all have multiple definitions for attachRules. And they don't match. It's always a battle between [1,1,0,0,1] and [1,1,1,1,0]. I would guess that the latter wins. Which one (if either of these) should it be?

I think you might have confused our Bravery and Stupidity bars. You mean in the README.txt? Or in the small map? Or both? Either way, OK. Added to todo list with higher priority. Yes, I noticed this the other day when I toggled to the other skin. Yes, I will fix that. It will go along with other support for skins.

There are not yet any substantive gameplay changes, unless you have the bug where planted flags do not appear on the BigMap. No, you should not lose your currently scanned maps.

Ah. The emveepee output is fine for viewing the first few entries, but the text-based version is better (since it's amenable to grep/sed/awk/regexen). If you're ever interested in a particular method, you can just search the text output from mprof-decoder.exe. The primary output that you get (in an abstract sense, and assuming a not-yet-written-tool works properly) is a relative, statistical call table (calls made to, calls made by) for every method in your project (plus any calls your project makes to other, known methods). So you can see things like: for every one call to my method blahblah, I make 100 calls to the method derpderp. Obviously the ones which are high up on the list (the ones you mentioned) are the prime targets for optimization (because they are taking up a lot of clock time). But any methods they ever call optimize them too. And the methods you are optimizing might be calling them. It's just one route. I think I'm going to adopt the caching you are doing, in one style or another. I wonder if there is an existing data structure out there in C# libraries or Unity libraries that would provide a cache that we could persist (preferentially in chunks). Also: another route to reducing the memory footprint while sacrificing only a small amount of performance might be to store the cache compressed (just like SCANsat already does with serialize/deserialize). I think the reduction factor is O(10-100) in memory, and I presume that the CPU cost is small enough that it's worth trying.

Hm. I wonder how that could happen. I did not include any references to MechJeb at all when building. I did notice that MechJeb things in my ALCOR capsule didn't work, but the SCANsat ones worked fine. I'm not using dev238, I'm on dev229. But again, I don't see how they would conflict so as to make both not work. I know people in here mentioned recompiling "all three DLLs". I assume this means RPM, SCANsatRPM, and MJRPM. But does MJRPM have a dependency on SCANsatRPM? Why would it? I don't think SSRPM has a dependency on MJRPM (since I didn't build it with one, and it built fine). Shrug. I hope someone else can elucidate here.

FYI: I am reading what you are writing intently; I am just not ready to respond yet. I am playing around with the profiling data and trying to reconcile my guesses with what the profiling data means and what your improvements change. I also wrote a tool that parses the profiling data (using regular expressions) -- at least, the profiling data that can be useful (I don't parse the UNKNOWN references or file references, since I can't tell what they are talking about). It works OK-ish. I have both the qualified and unqualified name available from the parse output -- so, say, SCANsat.SCANmap.getPartialMap and getPartialMap. I also parse the arguments signature, the % of time, and the # of calls. The next step I wanted to do was to automatically insert the profiling output for a particular function directly into the source code (above the function, say). This is actually tricky to do correctly (and should not be attempted with regexes, because it is not context free), and I didn't want to hack it last night. It also involves inserting unique IDs as placeholders into comments, so they can later be stripped out (remembering line numbers here is not sufficient; I intend to insert things into the files so all of the line numbers after the current function will be wrong). The overall goal here is to be able to build/run the profiling tool, have it run, save profiling data -> turn that data into textual output -> splice textual output and put in place in source, where we can see it. It seems simple, but it was harder than I thought. I can think of a few ways to put upper limits (both static and dynamic ones) on the size of the map. I am a habitual mover and resizer of the SCANsat map (both of which delay rendering). I was going to say something like "export is not a problem; for large map sizes we can simply refuse to cache but export to a file". And there's already an exportPNG function (which I actually changed in a trivial way in my latest commit). I think the cleverer feature will be to reverse this process, and consider the cache you are using to be an intermediate stage. It is almost surely faster (even with slow loading time) to load a huge texture from a file and scale that down rather than to re-generate the map (this only being useful after the map is fully rendered). BTW: Your judgements on the performance are currently via: monitoring memory and/or FPS and/or wall clock time when rendering the map, right? You are not using the performance tool thing?

Since I recognized what you probably want it for, I've already added this feature. It's now in v6rc2.

If the people asking for these requests don't know, all feature requests have a lower priority than: * repackaging to make a new official release * debugging any new features (toolbar support, RPM support, ...) * performance optimizations So in that sense, you can feel free to ask (I might even store the request in the TODO.txt), but just know that they are going on some list and there they shall wait.

I'm happy to announce that it was straightforward for me to build SCANsatRPM myself, and I don't see a reason that I shouldn't just release it with SCANsat. This version is built against RPM 0.16. This is the version you want to get now if you use RPM. If it works properly, I will include this in all future SCANsat versions. SCANsat v6rc2 [download] SCANsat v6rc2 [source] I am testing using the pretty damn amazing ALCOR capsule, and it seemed to work fine (though the big map is even slower than I remember! sadface!). Let me know if I missed something.

I just installed this module because so many people were complaining that my SCANsat did not work with it / RPM / SCANsatRPM, etc. Regardless of all that... ALCOR is a marvel at what can be done in this game. It's absolutely fantastic. I'm humbled by your capabilities in the various areas that you'd need to master to get this accomplished. Bravo!

Here is the repository where I have uploaded my version of this code. I don't remember reading the licenses since the code was recovered from a crash originally, but I assume Psawhn can tell us.

I tried to make a signature that looked like this: SCANsat [v5] (thread) (download) (source) by [damny M.I.A.] [v6rc] (post) (download) (source) by [me, DMagic ] Ideal Altitude Calculator [v2] (thread) (download) (source) by [me, Psawhn] This signature is what I adopted after the forum software complained that my signature must be < 1000 characters (including bbcode). So I removed links from some (download) and (source)'s and names, and was allowed to enter this above signature. However, the signature that actually shows up when I post is: Which, as you can see, does not have all 1000 characters promised to me! So: 1.) Can someone increase this limit, and/or select actual characters instead of characters and bbcode? 2.) If not, can someone grant me my full allotment? Evidently the last line is just hidden underneath the grey bar. Maybe adding some newlines will help: Trying again: Put a smiley in there to try and get more: It really seems like it cuts it off no matter what... so I'll wait until someone sees this.

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.

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...