enneract

I agree, was an oversight. Looking at it now, I think I did it that way because I couldn't figure out what the double value which HireApplicant() requires is for, and GetNewKerbal() returns the kerbal which just got hired. *shrug* Either way, changed that, but I also started a dev branch where I'm working on the selection mode stuffs. There is an interface for it now, even if it doesn't do anything yet.

Yea, I like this. My basic thinking is to replace the randomization option with a 'crew selection mode' option, of which randomization would be one option. If you want to do PR, give me a method to turn it on or off, and a method to call to get the next crew. As for GetNewKerbal() vs HireApplicant(), idk. I'm reasonably sure that they do the same thing, most of the time, at least last time I looked.

That, or variations of it, has been a pretty frequent request. I'm ambivalent about it, though, to be entirely honest. I haven't been able to settle on criteria which really suit me. The original point was to prevent seeing the same three Kerbals every mission, but if we wanted to be 'realistic' about it, you wouldn't send your most amateur astronauts on every mission, right? I would like to do something like some percentage of auto-crew (probably 1/3) was from the most-experienced half of the roster, and some percentage was from the least-experienced half of the roster, but I can't make up my mind on the specifics, and so it doesn't get implemented. I think the best thing I might do in the immediate future is do the 'plumbing' for user-selectable selection criteria. Then it should be pretty trivial to implement a variety of algorithms.

If you, or anyone else, wants to add any other features, I accept PRs

Lol. Have fun, man. Thanks for prodding me.

Updated for .25, removed hard dependence on Toolbar.

Perfect. The second part of your answer actually is a better way to solve the problem that I have.

nevermind~

I'm looking for a way to detect if a part is currently 'picked up' in the VAB. I would assume it is the 'mouseGrab' field in EditorLogic, but I can't find the way to get a reference to the instance of this singleton class after the latest update. Any insights?

It is on the to-do list. I can't give you a timeframe, though, other obligations are keeping me busy. I'm sorry I started work on it, and it isn't a simple change. Squad screwed with the way that crewing and the editor works. I have it building and doing the initial crewing, though it isn't getting the correct crew back in yet. If Kerbals are being duplicated by this mod, that is a bug. I have not seen this happen, nor have I had a report of it happening, though. I think that he is asking for crewing to remain consistent between saving and loading the vessel. I can think of a way of doing it, but idk if I am comfortable with it. Probably not going to happen, though I need to think on it some more.

I don't understand what you are asking for. No, neither version will work. Just fired it up, and it looks like there were some nontrivial changes to the way crewing works.

I've been thinking of trying to do this, actually. The reason why I decided against it initially was mostly due to the weird way KSP handles crew assignment, persistence of data across scenes, and making this behavior logically consistent. That being said, I heard something about .25 having a better record of which crew had done what. After I do the initial .25 compatibility update (which I am in the process of doing now), I'm probably going to implement another mode or two based around assigning crew based on their individual experiences. Something like an experienced mission commander and some newbs... or something. Need to work out the details.

I'm enneract, and this is my favorite mod in this thead. My initial reasoning for not doing this in the first place was that I wanted the mod to be as vanilla-like as possible, and 'just work', rather than adding yet another config window. This is great, though! I'm updating the OP to point at this and credit you. I don't have a KSP dev environment set up right now, but I'm in the process of doing so to update for .25, and expect your additions to be rolled forward into the update.

I'm glad you enjoy the mod

The only outstanding bug that does not have a simple workaround is the lack of persistence of manual crew selection on reset to VAB. I'm not sure if this is fixable, unfortunately. Potential solutions have, so far, introduced even more bugs. My mod maintains a relationship between the Part objects in the editor and the crew which is 'assigned' to them (because the game doesn't, interestingly enough), and uses this relationship to regenerate the crew roster each time the editor is updated. I can't simply save this relationship into the flight scene because those Part objects are no longer valid when re-entering the VAB, but without this relationship, I can't rebuild the crew roster. There are ways to deal with this, but I haven't figured out how to determine the difference between starting the editor scene from a .craft file, and starting it upon revert to VAB (each situation would demand different behavior). If anyone knows how to do that, please mention it. Other than that, you may need to have at least an empty entry in the randomization blacklist to prevent it regenerating, and you need to keep the config file in the default installation path. Either way, my focus right now is on my other in-development mod, OMS, and real life Don't hold your breath for fixes for any of these issues at the moment, at least not from me (notice the license!).

This is tricky. Each time you re-enter the editor, it is a new 'session', and data does not persist between 'sessions'. I'll see if I can figure something out for you.

Ahh! Yea, that would do it. As soon as I can be arsed to fire up my laptop with my ksp dev environment this weekend, I'll make that path relative to the location of the dll

Fair enough! Either way, the link is more direct now. Unless I get featured or something, the rate of download isn't going to turn off the link.

I'll look in to it this weekend. I'll admit that I didn't test leaving that section entirely blank, but I'm pretty sure that I know what the issue is. As a workaround, please try leaving an empty entry. Not super feasible, unfortunately. I can't stop kerbals from actually being hired, I could just track them and immediately delete them. This wouldn't play nice with mods like MCE which charge you for them. For the sake of others who might read this comment and be curious - the 'Dropbox' label was a brain fart. I used to use dropbox for this, and switched to Copy.com due to larger free allocations. The url shortener is so that I could get an idea of how many downloads were happening, and adjust hosting if it reached a threshold which threatened to deactivate the link.

That is where the 'open' part comes in. Once the basic framework exists, anyone can add additionally objectives to the project. Additionally, as a future goal, an API for other mods to add objectives would be nice. Not going to happen. This will leverage the existing contract mechanics and UI elements, which are not available in 'science' mode.

Yea, I'm actually working on the parser as we speak. Can you run this one by me again? I'm not sure what you mean.

Indeed! I'm probably going to stick with XML for now, though the input is appreciated. A standalone mission editor is definitely something to do once initial implementation of the plugin is done, which will make the choice of format relatively trivial.

I personally loathe parsing YAML and JSON, to be entirely honest. My mind went to XML because that is what I am familiar with.

Ahhhh John Ringo, the 'Man who doesn't know what numbers mean'.

Hi guys! I've been had an idea tumbling around my head the last few weeks, since .24 was released, and I think I'm going to have the time to start putting it together over the next week or two. I'm mostly in the design phase at the moment, but the success of the commnity-driven development of Karbonite has me thinking that emulating that approach might be extremely productive - and so I'm making this post to solicit feedback, ideas, and (very shortly) content. I know that RoverDude had some well-recieved mods under his belt already, and thus had significantly more 'street cred' than I do, I'm hoping that this mod can evolve into a community effort as well. That being said, I want to establish some overall direction before publishing code and opening it up to PRs. The 'tl;dr' version of the overall goal is to implement 'legacy' MCE-style missions in the new contract system. I want the player to have access to (potentially) narrative-driven, manually created and paced contracts. I want the non-programmer to be able to create mission packs, either narrative or procedural. I want to reduce the amount of repeated coding effort required to create contract mods, in much the same way that ORS seeks to reduce the repeated effort required to create resource-based mods. What OMS is: Mission packs will be defined as XML documents, defining certain attributes which determine the nature of the missions. The primary dichotomy in types of missions will be between Narrative and Procedural. One mission definition document will only be allowed to define one type of mission, but may contain many (unlimited?) individual missions of that type. Narrative missionswill be presented to the player in an (optionally) defined order, will (optionally) reappear if declined, can be dependant on a previous mission being completed (ie, don't show this mission if preceding one was declined), and are exactly as procedural as the mission author wishes them to be. This type of mission could be used to define a 'grab bag' of standalone missions, such as challenge missions. (visit minmus and return a sample using a craft that masses less than 10T at launch as an example), or it could contain 'series' of missions meant to be completed sequentially (see the MCE 'bootstrap' missions as an example). Procedural missions are very similar to the existing squad missions, except they are constructed out of pre-defined mission objectives in novel combinations. An example mission definition could be the equivalent of 'Land on <random planet>, retrieve sample from <random biome, if applicable>'. Mission Objectives are the 'meat' of the plugin. I want to implement (and eventually provide a way for other plugins to implement) generic objectives which can be referenced by the mission definition documents to build new missions. This is the section that I'm particularly seeking feedback and suggestions about. The idea is to break any task down into the minimum 'units' so that they can be potentially reused as much as possible. Currently planned objectives are Orbit <Object>, with optionally defined parameters (inclination, ap, pe, eccentricity) Flyby <Object>, with optionally defined pe Land on <Object>, with optionally defined biome Return sample from <Object>, with optionally defined biome Vessel mass range, optional minimum or maximum. Minimum or maximum crew. Part or PartModule required on vessel. Mission duration What OMS is not: OMS is not intended to be a replacement, or even a compeditor to such fine mods as MCE or Fine Print. All should be able to be used simultaneously, and I'm hoping that this project might even be of use to such efforts in the future. OMS is not intended to contain mission content, per se. The point of initial development effort on my part will be to create the framework to create mission content, and while OMS may come with some mission content, no particular mission pack will be required to use the mod. Anyway, I'm hoping to have a github up with some initial code in the next couple days. I'll admit that all of my previous mods have been 'my baby', and so I'm new to the idea of actually integrating other people's code, but I'll be open to PRs ASAP. For the time being, I'm very eager to hear ideas, requests, criticisms, or other feedback.