Papa_Joe

The existing SM version 4.1.4.4 does work in KSP 1.0. The error from AVC is related to the .version file in the existing release. it has a section for the ksp version. I'm going to try updating the server side version to see if the issue disappears, but it is NOT a functional issue, only a version check issue. Update. I bumped the KSP version on the server side, and that seems to have done the trick. Let me know if you still get the version warning on start up. Btw, CKAN had a problem with a recent version they released. I updated my CKAN.exe (the client) to 1.6.11. CKAN seems to be working fine for me now. Link to CKAN is here: http://forum.kerbalspaceprogram.com/threads/100067.

I copied Toolbar over from my 0.90 install along with the config. Seems to work fine.

Seems to be fully working. I'm testing my new version 4.2.0.0 in 1.0 now. No issues.

Just a note. SM 4.1.4.4 still works in KSP 1.0. @Yemo: GL with the changes . Let me know if I can help in some small way

KSP 1.0.0 update: Ship manifest version 4.1.4.4 works in KSP 1.0.0. No issues found (so far).

Version 4.2.0.0 update: Expanded resource transfers are looking good. Still some testing to do and 1.0 to verify against, but I thought I'd share some images of the changes. First, the Resource selection window (Manifest Window) looks pretty much the same with some minor changes in details to account for multiple resources. You cannot select Crew, Science, or ElectricCharge with anything else. So these will cause the other selections to be deselected when clicked. As before, resources are a toggle, so clicking on a previously selected resource deselects it. Now any other resource may be combined with another. maximum 2 resources. Since I cannot possibly know all the possible fuel / oxidizer combinations, I left it up to the user to select their choices. Second, Transfer Window: This now uses the same button toggle method as in the Manifest Window. You can select any number of parts in the source or the target. It is smart, in that if you select a part in the source, it is now greyed out in the target. (we can't move a resource from/to the same part.. heh). This will make choosing your destination parts easier I think. in the details, when multiple parts are selected, the total amount of resource for each resource will be displayed and the amount remaining in all parts selected. I then calculate the maximum amount of the largest capacity resource to use as a basis for display. I only show the largest resource for editing in the text box. I struggled with whether to allow editing of both, but real estate simply did not allow it, and since I calculate the ratio based on the target tanks, one number is sufficient. The resource slider will control the largest resource, and the smaller resource is calculated, based on the amount selected in the interface. If you want better control, move only one resource at a time. The calculated ratio is the total capacity of the selected parts, and the selected Resources. So, if you have a total capacity of 8000 Oxidizer, and 6000 Fuel, the ratio will be: 6000/8000, or 0.75, which is used to multiply against the larger number to arrive at the smaller number to transfer. It will be up to you to be sure your ratios are correct for your engine needs if you use non stock fuels and parts. Since you likely do this anyway for your ship design, this method should work fine. Multi part, multi resource xfer in progress below: I'll keep you posted.

Welcome! I lurked for a while too, before I joined. Don't be a stranger!

Welcome back! I didn't know it was possible to get burned out with KSP... (at lease till now that 1.0 will have heating effects )

Congrats on your rig, and welcome to the forums! Share some video of your exploits when you can!

Welcome to what I think is the best community in the world. Enjoy your stay!

Hype train aside, welcome to the forums. I've been playing since .7 myself, so I've seen a lot... My favorite missions are building space stations in orbit around every planetary body and keeping them supplied... Funny, I haven't completed even half the planets yet... Modding seems to get in the way of gaming time lately

Lol... you definitely have a very large task in front of you for 1.0... Not sure what I can do to help, but I'm willing...

Sounds good. Start posting your wish list

The main site and store are undergoing Server migration as we speak... https://www.kerbalspaceprogram.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Server Migration Kerbal Space Program website is in maintenance mode while we are performing a Server Migration. We appreciate your patience. - Squad Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Yes. I've been in the middle of an update to Ship Manifest to add multi-part and multi-resource transfers... That is in test now. I expect to release that soon after the release of KSP 1.0. Then it is back to Roster Manager full time. (except for bug fixes for SM. )

Yep, it is weak. My guess is that the name is "hardcoded" across a lot of code as professions and contracts "evolved", and would require a fair bit of refactoring to decouple. Now that they got a chance to do the gender after their "learning curve", they did that right. I'm hoping they will revisit it at some later date, now that they have a pattern to use. However, I'm also guessing that the gender is not embedded into contracts and professions as the name is... I do have to admit I've learned a lot over the past year or so, and I'm in the midst of a serious refactor of SM as well...

Hey sumghai, Yes I do append ascii chars to affect the profession change and allow persistence. The only place where it seems to show up is in map mode when a kerbal is standing on a planetary body (or moon). the image you saw was likely in this post: http://forum.kerbalspaceprogram.com/threads/62270-0-90-0-Ship-Manifest-%28Crew-Science-Resources%29-v-4-1-4-4-10-Apr-15?p=1755250&viewfull=1#post1755250. I agree it would be immersion breaking, and it is NOT an ideal solution. I would much prefer that Squad did NOT tie the profession to the name as they have done. However, given the current constraints, this was the "solution" I came up with with 5thHorseman's assistance. This is also why I have the feature turned off by default and warn to "use at your own risk". My profession management method also does not take into account "custom" professions that are now available in some new mods. With my plan to create Roster Manager, I'm looking into leveraging KerbalStats, where the naming and professions are actively managed using a separate persistence file.. Upon load of your game, the plugin will strip the name and profession in memory, replacing them with their new versions after load of the game save. The upside, is that it is more "elegant" and not a hack, and accounts for custom professions. The downside of this is the need to continue using KerbalStats if you wish to continue with the renames and profession changes. Uninstall KerbalStats, and your kerbals revert to their original name and profession. For many that will not be a bad thing. Now this also introduces a compatibility issue. My current profession management feature is NOT compatible with KerbalStats. If you use KerbalStats, be sure that Profession management is turned off in SM. If you do happen to run into this issue, you can remove the ascii chars in the game save and this will correct the issue. However, your professions will change based on what ever name you have in the game save. I may add a "revert" feature to remove the ascii chars via the Roster Window, to help if anyone wishes to revert the Profession changes in the game save. I intend to provide both options in Roster Manager, as some folks may not wish to use kerbalstats, and instead use the method that alters their game save to manage professions. When Roster manager is released, I will be removing the Roster feature from SM, as it really does not fit the current "Theme" of the plugin and is a holdover from the Crew manifest days. All the same functionality will then be in Roster Manager (plus more). You know me, I like to offer choices.

Indeed it is, and based on the combined efforts of you fine players, and some research, we believe it is related to the proximity of debris. I left out a check to see if the vessel being loaded in th4e event OnVesselLoad was actually the active vessel, so SM sometimes thinks that the debris that just appeared in the scene is the current vessel. To overcome this issue in the short term, you can remove your debris from your game, or switch between vessels using the [ ] keys... Sorry for the inconvenience. To permanently correct the issue, I've added a check for the active vessel in my dev build. I'm in the midst of a fairly large update atm so it will have to wait until I get to a stable point. Currently I have multi-part and multi-resource transfers working. I'm testing them thoroughly to make sure there are no surprises, but soon you will be able to transfer LF+O to multiple parts at the same time. That should make those fueling runs more enjoyable... Look back a page or 2 for the proposed update list for version 4.2.0.0 With the impending release of KSP version 1.0, I'll likely want to test it against the release as well... More coming soon.

Ok, that makes sense. If you initiate another transfer immediately after the first, I can see where that could cause an issue. The process for the override is as follows: Click on the kerbal and initiate the transfer. 1. I immediately revert the transfer and initiate the delay function 2. The next Frame updates to commit the reversion, and the sound and delay begin. 3. when the delay is complete, I then perform the move again. So, the kerbals will appear to be in their original places (and actually are) until the completion of the delay function. 4. The next frame updates to commit the move and update the portraits. I'm not running the events asynchronously, and I'm reusing a single static object to handle persistence between frames, so it could get confused. I'll have to look at how I'm performing the data storage to allow for that behavior. I'm looking at the same issue with multi Part/multi resource transfers as well. You could conceivably try to transfer 2 different kerbals within the delay period... Likely, I'll use an object collections to manage the storage instead of static vars. Also, I can disable the button on the tweakable during the transfer... We should be able to overcome the problem

Did you perform any actions at all, or did you just "install" the mod? I've never seen any of these errors before. Under what conditions does it occur? Did you rename any crew, and if so are you using KerbalStats? Are you using Exception detector to trap this or is it in the KSP log? any additional info you can provide would be helpful. Update: I did a quick search online for this and found... http://forum.kerbalspaceprogram.com/threads/113968-Corrupt-Save-due-to-space-station-seats So it does not look like it is SM causing it... The poster of this thread was using Crew manifest, and SM is based on that for crew transfers, but it looks like the space station mod itself..... read it and see if it applies.

Interesting. This was all accomplished using the part tweakables, with SM override on, correct? Did you Undock a or b before the delay was complete (approx 7 seconds)? It definitely could be the delay, IF the above is true. I revert the crew, and then trigger an event. on the following frame i initiate the delay timeout, allowing callbacks to complete and video frames to proceed prior to the transfer being re accomplished. The transfer is then performed, and an event fired, that will be effective by the next frame... What could also be true, is that I'm missing some action that KSP is expecting when using the Tweakables when I override the behavior... I'll investigate. still more to learn it seems.

Thanks for the feedback. I'll take a look. does open all hatches after a close all hatches behave the same? Update: Ok, I was able to replicate the issue. Interesting that this issue returned. I had it squashed before. I'll be sure to correct it in the next release.

Thanks for the feedback! interesting. Based on that, I'm thinking that using the resource tank sizes to determine ratio may work for my purposes. For example, the LF and Ox tank capacities could be 45/55%, respectively or not. So If I did a calc against the 2 selected resources in the part, I could determine the ratio expected. I'm thinking this would serve the purpose, as it would assure a consistent transfer, based on the source tank ratios. I would then not need to concern myself with the engines, as it would be the responsibility of the ship designer to have the ratios expected of the engine. I'm not so much concerned with the consumption rate as the tank to tank ratios. This also negates any need to "manage" the ratios, as they are defined within the part...

Thanks! I'll post in the Real Fuels thread and then peruse the code as well.

Hey all, I have a question I hope has been or is known. I've read most of the thread, and it would "seem" that the LF/O consumption rate of 0.9/1.1 is a KSP constant. With that assumption, then all custom resources fall within this Stock behavior? Based on looking at the MM configs, it appears that all fuels and oxidizers map to their stock counterparts... For example if you create a resource named Methane, and it is used in place of LF, then M/O consumption percentage is still 0.9/1.1, correct? I'm asking, as I'm preparing to support multi-resource transfers in ShipManifest, and I want to be sure I'm correctly supporting Real Fuels and MFT...