[0.90] CrewFiles: persistence files for individual kerbals (16 dec 2014)

[Ippo]

Ok, as suggested by codepoet, I am trying to implement a reflection wrapper to avoid a hard dependency.

I'm copying the approach that blizzy78 used for the Toolbar wrapper, but I can't get it to work. If some one could help me out a little it would be great.

So as far as I can tell, blizzy defines some interfaces in the Toolbar namespace and all classes implement the appropriate interface.

Then, there is a copy of all those interfaces inside the ToolbarWrapper file: you need to copy this file to your solution and change the namespace to match yours.

I copied this structure (see the dev branch).

However, the server class implements CrewFiles.ICrewFilesServer , and when you put the interface file in your namespace you retrieve the instance (this line) and then try to cast it to YourNamespace.ICrewFilesServer, and an exception is thrown.

A little help, please?

[blizzy78]

However, the server class implements CrewFiles.ICrewFilesServer , and when you put the interface file in your namespace you retrieve the instance (this line) and then try to cast it to YourNamespace.ICrewFilesServer, and an exception is thrown.

I've only quickly read over the issue, but as I see it, this cannot work. You're trying to cast from the server's ICrewFilesServer to your local ICrewFilesServer. Despite having the same name, they are different interfaces, and the server's class does not implement your local interface, which is why the exception occurs.

The way I do it in the Toolbar wrapper is by keeping the "remote" object just as an object, and whenever someone calls one of the local interface methods, I call the corresponding "remote" method via reflection. I hope that makes sense.

[Ippo]

This actually makes a ton of sense. Thank you very much!

[Ippo]

Good news everyone, I made a new release!

I had to drop the pure reflection wrapper that blizzy did, because I'm not him

However, I followed the advices I got from codepoet and now there is a loose coupling: the mod that wishes to use this system only has to reference the interface assembly that can be safely redistributed alongside the mod.

Still missing: preventing multiple instances of the server (for some reason, I always get NREs all the time when I try to check if there are multiple instances) and then moving the database into the persistence file (as of now it's still external because it's easier to mess with while I'm still debugging: also, I understand that a ScenarioModule cannot load / save at will...)

By the way, I could really use some advice for the multiple instances thing

[AppleDavidJeans]

Who knows what we can do with this API? We could finally implement crew ranks, regulate permissions by the individual kerbal, and what else. Let the ideas fly!

[Ippo]

Who knows what we can do with this API? We could finally implement crew ranks, regulate permissions by the individual kerbal, and what else. Let the ideas fly!

Or individual perks, like I intend to do in my main mod Keep in mind that for the moment the persistency is still "broken", in the sense that it does not synch with the main persistent file. In its current state it's good for things that are never going to change during the lifetime of the kerbonaut.

By the way, I could also use a little help: I was experimenting with an empty ScenarioModule that only logged whenever it entered a function. It gets instantiated, but OnLoad and OnSave are never called: does anybody know what I am doing wrong?

[Ippo]

Small update: as per your suggestions, I am moving the database in the persistent file.

I'm working on it in the dev branch: right now it's not working yet (weird NREs all over the place), but I hope it will be soon.

[Ippo]

Beta 3 is now available on github.

This update has moved the database into the persistent file -> it is automatically in synch with the game, but it completely broke backwards compatibility (not that anyone was using it, but still).

Please check the code and maybe give it a couple of tests if you are interested. If no particular bug is found, I'm just going to promote this to v1 and call it a day.

[codepoet]

Thanks for doing this. Now that you have reached this stage I am going to start work on my "kerbal social" mod which at the moment is all a bit woolie in my head and needs some firm requirements and goals, but giving kerbals extra attributes will be a big part of it. I would be interested to hear about any other modders that are thinking about using this now that it is progressing. I think Ippo has done an excellent job of listening to feedback from potential users and meeting the needs that were identified.

I will post again once I have made some progress, but it might be slow as my real life is about to get really busy.

[Ippo]

Well, as I said, there will be at least my mod (DangIt) using this: in fact, I was testing it today and it seems to work fine, which is encouraging

By the way, I had seen your thread about the kerbal social mod, and I think it's very interesting: I'll be monitoring it closely and see if I have something to contribute

[Ippo]

By the way, I was reflecting on the code and realized that I may have accidentally fixed the only real issue.

Since now it is a scenario module, because of the injection code two instances shouldn't run, at least if I'm right. I will test it tomorrow.

On the other hand, this prevents upgrading, because the new version will not be added to the game since an older one is found, but I think it's not too difficult to work around it. Tests tomorrow.

[Ippo]

Well, since I fixed the main problem (the multiple instances bug) I have decided to declare this complete and so I promoted it to version 1 and posted it in the release section.

See you there!

[Olympic1]

What's your next thing on the list for this?

[Ippo]

Nothing: as far as I'm concerned, it's done (unless someone has bugs or feature requests)

[Olympic1]

Is this compatible with 0.24 (x64)

[Ippo]

Is this compatible with 0.24 (x64)

Apparently, not: there has been some change in the API and it doesn't even recompile out of the box. I'll need to investigate into what has changed, but I'm really tied up in RL atm :/

[Olympic1]

Apparently, not: there has been some change in the API and it doesn't even recompile out of the box. I'll need to investigate into what has changed, but I'm really tied up in RL atm :/

I can wait

[Ippo]

I can wait

Hi, I'm back. I am wondering: does anybody really plan to use this?

Because technically, it has never been necessary. You can obviously just replicate the mechanism I am using*, which is very simple, and avoid a dependency on another mod, and we all know that dependencies are evil.

The reason I made this is that I needed it, and then realized that if anyone else was going to need the same thing then it was pointless to reinvent the wheel. However, reinventing the wheel might be better for you if you want to avoid a dependency.

So yeah: is anybody interested in this? Because 0.24 broke it, and I'm not going to need it myself for a while. If there is no interest, I'll just do other stuff first.

[Olympic1]

Hi, I'm back. I am wondering: does anybody really plan to use this?

Because technically, it has never been necessary. You can obviously just replicate the mechanism I am using*, which is very simple, and avoid a dependency on another mod, and we all know that dependencies are evil.

The reason I made this is that I needed it, and then realized that if anyone else was going to need the same thing then it was pointless to reinvent the wheel. However, reinventing the wheel might be better for you if you want to avoid a dependency.

So yeah: is anybody interested in this? Because 0.24 broke it, and I'm not going to need it myself for a while. If there is no interest, I'll just do other stuff first.

People like RoverDude and codepoet could use it in their mods. Like: too far from Kerbin, no friend to "talk" to brings their sanity higher.

[codepoet]

Hi, I'm back. I am wondering: does anybody really plan to use this?

Because technically, it has never been necessary. You can obviously just replicate the mechanism I am using*, which is very simple, and avoid a dependency on another mod, and we all know that dependencies are evil.

The reason I made this is that I needed it, and then realized that if anyone else was going to need the same thing then it was pointless to reinvent the wheel. However, reinventing the wheel might be better for you if you want to avoid a dependency.

So yeah: is anybody interested in this? Because 0.24 broke it, and I'm not going to need it myself for a while. If there is no interest, I'll just do other stuff first.

I have been holding off my development as I have been waiting for this to be updated to work with 0.24.2.

[Ippo]

Well, if this is the case, I'll get working then

To be fair, it is a fairly simple piece of code, but why reinvent the wheel? I'll see to it asap

[Ippo]

Ok guys, I have updated it for 0.24.2. I am not releasing right now because it's almost 1 am, and the last two releases of DangIt have taught me that I should NEVER release something that I finished coding after midnight.

In the next days I will try some more tests, but in the meantime, if you are interested the 1.1 branch is basically the next release already.

[Ippo]

Well, so this morning's test didn't show me any obvious bug, so I uploaded the new build.

Now for that Kerbal Social mod...

[codepoet]

Thanks. I will get to work - no overnight promises though...

[Ippo]

Micro-update: I was working on Dang It! and realized that

if (CrewFilesManager.CrewFilesInstalled && (CrewFilesManager.Server != null)) 

was starting to come up often in my code, so I added a shortcut:

if (CrewFilesManager.IsReady)

Just posting for completeness in case anyone wants to know the full changelog (really: that's it).