enneract

No dev thread yet. Not that far enough along. I've done proof of concept of a lot of the individual pieces (mangling squad ui elements, mostly), but no coherent work as to making it an actual 'mod', yet. Like, I've figured out how to hijack the launch dialogues, a more cohesive way to do simulations, a few other things. It definitely is my next project to go full-steam on once I finish the features I want for CrewQueue. What it will actually end up with is a bit up in the air; the way KCT's code is organized makes it difficult to integrate what amounts to a UI overhaul, and my design 'philosophy' is somewhat different than magico's. It may end up as a 'UI layer' for KCT, or it may end up as a competing mod, or a 'mod of a mod', I just don't know yet.

That project is coming along, actually. Nothing ready to release, but I know *how* to do that UI mangling and have made some progress at implementing something useful. Don't have an excessive amount of time for KSP modding anymore, though

Please please please report bugs you run into with that combo. I've gotten a couple of feedback saying there are some, but I can't repro them.

KCT compatibility has been reported to work, but I am going to be taking another pass at it when KCT gets an official 1.0 release. Ship Manifest is compatible. Ship Manifest's renaming hack is not compatible, and is probably not a good idea to use (for a few different reasons). I'm going to fix the whole 'crash if you use that hack', though.

Beautiful. On the to-do list.

1.0 is here, I'm going to be updating this. This is to all 87 of you who've downloaded the mod; other than bugfixes, is there anything else you'd like to see?

Can you seriously get more pedantic? I'd really like to see you try. The real difference between 'kilo' and 'Kilo' in this context is negligible. KSP uses SI units, period. Nobody in their right mind uses SI base units when dealing with numbers these large, because that is a great way to introduce accidental order-of-magnitude errors. So bloody what if you calculate megajoules instead of joules - megajoules is likely to be the relevant unit size, anyway.

Well, I was pretty sure it didn't actually work I wrote it in about 10 minutes with minimal testing, and never got the chance to go back and verify it. I'm going to be revisiting this with 1.0. Too much on my plate IRL to deal with it right now.

Good to hear from you. It looks like KerbalStats doesn't currently support soft dependency (though that could be contributed if that is a thing you are really interested in, it isn't too difficult), nor does it (as of yet) support anything like name changes. If you are interested in collaborating on implementing that, I would be willing to make the attempt.

At the risk of being a bit impolite to the OP, I'm going to plug my own mod which implements crew rotations.

Sploosh.

As Starwaster said, Kerbals are literally defined by their name. Even their profession is based off of a calculation performed on their name. When you 'rename' a kerbal, you are more or less deleting the old one and adding a new one, as far as the game is concerned. I have a few ideas on how to address this, but haven't had a chance to play with them; 1) Implement into the compatibility interface a way to inform CrewQ of changes that gameevents doesnt notice. PR ship manifest to inform CrewQ of changes. Doesn't fix the underlying problem (fixes would need to be done per-mod), but would result in least-exploitable solution (ie, you couldn't rename a kerbal to reset their vacation timer). 2) Do some sanity checking when building the internal roster. Only perform actions on Kerbals that actually exist, and generate new CrewQ data for kerbals that suddenly 'appear'. Downsides, you could exploit this to reset timers, and would marginally increase overhead of CrewQ. I'll probably do both, but... yea, time. On another note, I'm about 50% sure that the existing compatibility with KCT doesn't actually work. Some reports on that would be helpful; any day now, I'll have some time to spend on this.

Nope, no way that this mod could do that. Totally not possible. I don't touch the camera at all, or interact with the flight scene in any significant way.

Not really, I haven't had a chance to do any modding lately. You can work around it by looking for the CrewQ section of your persistence file, and updating the names there to match the new ones.

Yep, no problem. Thanks for pointing out this problem, I didn't consider it. I need to think about what the best solution would be, because right now I'm keeping track of crew by their names. This works fine in stock, but.. yea. Bleh. Maybe I'll go look at how FF handles this.

Not particularly soon, though. I wouldn't expect it before 1.0.

Ah, balls, yea, that would do that. Next version will have some sanity checks. I've been AFK due to school lately, I'm hoping to get some KSP time soon.

This is happening.

Thanks, this is useful. I'm not sure what is going on, but I'll get a fix out asap. Can you do me a favor and try it without KCT?

The best way to get feature requests noticed would be to post them on the issues page on github.

Anyone using this without KCT, please try out the new prerelease. If you are using KCT, I've got a PR in to KCT to add compatibility; next release of KCT should be compatible.

Whats with the KAS hate?

Yea. I'm really not sure what is up with the version I released. It was overall just far too fragile, but passed my tests. The current development snapshot is much better, mostly because I rewrote the entire data-storage mechanism. Expect a new release pretty soon; what is left is auto-assigning new crews and testing.

Is there any way to insert a ScenarioModule into the game save\load queue other than using the KSPScenario annotation? I need my ScenarioModule loaded faster than that.

I also want to note for posterity, that writing a few thousand LOC with no comments, then walking away for two weeks, does not work very well.