RasterPropMonitor, MechJeb and SCANsat...

[BudgetHedgehog]

3 of my favourite mods that just don't seem to play together nicely any more.

I know why, it's because MJ and SS get updated, which breaks links to them in RPM. It just makes me sad because because we have different people working on all 3 mods - there's moarDV and Mihara working on RPM, sarbian on MJ (with OrbitalDebris recompiling RPM to work with the dev builds of MJ) and technogeeky/DMagic working on SCANsat with danmy M.I.A - and I don't know how much they are talking/co-ordinating.

Don't get me wrong, I think it's great that these mods are actively being worked on and updated, but every time one of them updates, it breaks compatibility with the others. I guess it's inevitable, but it's also frustrating. We either have everything working but with old versions or everything up to date but not working together. I don't know if there's a fix for it or if anything can be done about it, but I'm tired of checking all three threads for updates about RPM compatibility.

I guess what I'd really like is this thread to become the hub for everything to do with getting these three to work together nicely because there's various goings-on in all three threads that people in the other threads don't know about. A central place to work around it all rather than spread out over three threads is a lot neater, I think..

I repeat, I think it's great that everyone mentioned is working hard on updating/fixing/recompiling their dlls and mods, but what I find less than great is the fact that doing so invalidates the others work. I'd like for this thread to be where everyone involved (or not) can post and see all updates and thoughts and most important of all, co-ordinate with each other so they don't mess up everyone elses work. All authors can see updates about the others and advise their users accordingly.

For reference, here are some links to the latest versions of all (some threads, some posts, one neither):

SCANsat v6rc1

MechJeb (thread and jenkins dev builds)

RasterPropMonitor

OrbitalDebris' RPM recompile for MJ dev builds

[Cdr_Zeta]

Hi,

Altho RPM is nice I havnt used it this time around and hope to do so...it is however in my opinion at the bottom of your list priority-wise...Mechjeb then ScanSat compatibility but even then ScanSat is also at the bottom or midway on our long list of mods.

We all must look to individual threads for the most important mods for us; I use Planet Factory and had to change something in the code myself to get it to work and I cant re-distribute it; I spent a week or more solving various problems just so that I can play the Science Career mode; we seem to forget this is an Alpha program; one of the best around in that light.

Cdr Zeta

[Zeroignite]

So is there a known way to get the three of them to play nice as of MJ build 240 and ScanSat v6r2?

[technogeeky]

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.

[technogeeky]

So is there a known way to get the three of them to play nice as of MJ build 240 and ScanSat v6r2?

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

Hi,

Altho RPM is nice I havnt used it this time around and hope to do so...it is however in my opinion at the bottom of your list priority-wise...Mechjeb then ScanSat compatibility but even then ScanSat is also at the bottom or midway on our long list of mods.

We all must look to individual threads for the most important mods for us; I use Planet Factory and had to change something in the code myself to get it to work and I cant re-distribute it; I spent a week or more solving various problems just so that I can play the Science Career mode; we seem to forget this is an Alpha program; one of the best around in that light.

Cdr Zeta

I'm hurt that my beloved SCANsat is at the bottom of your list.

j/k. I only adopted SCANsat.

[technogeeky]

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.

[Faark]

So you want to ignore assembly versions? There is an AppDomain.AssemblyResolve event that is fired whenever a resolve fails and seems to be the most promising way to accomplish that goal, though its a bit tricky to set up in KSP and i don't usually want mods messing around with assembly resolution. That could lead to some really ugly bugs. I also wonder whether it is possible to modify such an reference in an assembly to use an partial assembly reference (though Microsoft really don't want us to do sth like that^^)... sounds interesting, ill try it *edit* ofc it doesn't work... would have been way to easy & awesome. I'll set up a proof of concept with AssemblyResolve later today. *edit2* Damit, even module constructors seem to be executed only after KSPs AssemblyLoader has gone though all assemblies and already failed to load those others. Anyone else have an idea on how to execute code early? The only other approach i could imagine would be to reload those dlls if they failed in the first place, but no idea what would be necessary to make this work... beside ofc using a lot of reflection in *RPM.dll's.

Edited May 6, 2014 by Faark

[sarbian]

I still did not take time to look into that. What's happening still sounds strange since I have dll the interface with each other that don't require recompiling each time. But then as I said I did not look into it yet.

So I'll have a look, try to understand and if I can't make it work I'll ask the various dev if I can configure my Jenkins server to build all their mods each time one is updated. Not the perfect solution but it would work.

[OrbitalDebris]

So here's the crazy thing: VesselViewRPM works just fine, even with my rebuild (which is why I assumed scansat would work as well, since I don't use it. My bad for not testing it). What's different about VV?

Edit: Oh I just realized. VV supports RPM directly and the other two do it through the *RPM helpers. Bit slow today . So what seems to be happening is that if KSP loads assembly A and assembly B, then assembly B can refer to assembly A just fine (VV can call RPM functions) but if assembly A calls assembly B which then calls assembly C then versioning matters (RPM calls MJRPM which calls MJ). Weird.

Edited May 7, 2014 by OrbitalDebris

[technogeeky]

This issue is solved as of the latest releases of both MechJeb and SCANsat. Both projects are now committed to hardcoding their assembly version (even for dev releases), and the ssRPM and mjRPM helpers are both hardcoded to 0.0.0.0.

[phoenix_ca]

Versions mismatch and assemblies don't load. Solution? Call everything version 0. Sounds like a very kerbal solution. Jeb would approve I'm sure, if Jeb knew anything about programming.

[Yilmas]

Wouldn't it be fixable with an assembly policy file?

http://msdn.microsoft.com/en-us/library/8f6988ab(v=vs.110).aspx