[1.12.x] Ship Manifest (Crew, Science, & Resources) - v 6.0.8.0 - 28 Apr 23

[Papa_Joe]

Mmm, I was hoping that KSP API provided some sort of "here's a resource, here's how much mass it has per unit and how much volume it takes" information. If not, then the solutions are messier. It may end up being that you have to keep a list of the popular resources, or at least the exceptions which require special handling, like TAC/LS Oxygen which comes in huge quantities.

If you know the mass per unit via the KSP API, then maybe the pumps are simply rated to move 1000 kg of stuff per second. Which might be a reasonable least-cost solution that is semi-realistic and mostly self-balancing. Moving 100t of fuel around is still going to take a long time, but moving 1t of Oxygen would be very quick.

...

Another option would be to cap the transfer time at some upper limit. Calculate the sum of the source tank size + target tank size in units, divide by 180 seconds. Your transfer rate is the maximum of either that value or 100 units/sec.

For a little mono-prop tank that holds 750 that is pushing to another 750 unit tank, that is (1500 / 180s) or 8.33 units/sec. In which case you would use the 100 units/sec transfer rate.

In the case of moving Oxygen around, the source tank holds 210k units and the target tank holds 50k units. (260000 / 180s) is 1444 units/sec. Since that is larger then 100 units/sec, you would transfer the materials at a rate of 1444 units/sec.

I have some LF/O tanks that hold 29568 units of Oxidizer each. Transferring between those tanks would use a speed of ((29568 + 29568) / 180s) or 328 units/sec instead of the default of 100 units/sec.

It's a quick-n-dirty solution, but a little suspension of disbelief says that larger tanks have larger pumps. And three minutes is probably a reasonable upper bound for moving bulk materials around.

Ya, that is what I was thinking. Allow you to both set the flow rate and an upper time limit. If the flow calc exceeds the upper time limit, then use a fraction of the time as the flow rate. If below the max time, use the flow rate set.

I agree that it gets messy, especially since some of these mods allow you to "create your own resource". Keeping a list would be problematic in that it would need maintenance and create headaches for all modders.

Better to use some "approximation" so that you get the feeling of immersion, rather than trying to "be precise". I realize that a lot of work has been done to try to overcome the inherent limitations of the existing model, as mass and density are not adequately simulated in KSP.

That is not to say however that I won't take a look at what work has been done with resource mods, to see if there is an "elegant" way to provide a more satisfying simulation. I will think of that as a "4.1" goal, along with moving both fuel and oxidizer at the same time...

On another note, I've added the requested stop button and cleaned up the behavior of the transfer process a bit. I've also exposed the min and max numbers for the slider in the settings window, to save having to directly edit the config.xml file. I'll post screen shots soon.

Edit: Okay I've added the time limit as well... default set to 180 sec (3 min).

Edited February 13, 2015 by Papa_Joe

[Wisq]

Are there any known mod incompatibilities between ShipManifest and other mods? I run a lot of mods (80+) and I find that Manifest sometimes work, but sometimes just produces weird results. Science and crew work fine, but resources tend to be weird.

In the past, I've tried to transfer resources from a full tank to an empty tank, and ended up with it transferring -1 instead: the full tank becomes over-full and the empty tank becomes negative.

In my current game, I just tried to transfer fuel from my station's large (14k) Multipurpose Resource Tank XL (Hangar mod) to a Rockomax X200-16 tank on a ship docked to the station. The "Xfer" interface goes away, like it normally does when a transfer is in progress, but there's no sound and it never transfers anything, and aside from the Settings and Roster buttons, the entire Manifest UI is now unusable until I exit and reload.

Nothing in the KSP.log that I can see. Certainly nothing that appeared when the problem happened.

I have seen successful resource transfers in the past, so this isn't a case of being totally broken at all times, but it's definitely broken for this situation.

[Papa_Joe]

Are there any known mod incompatibilities between ShipManifest and other mods? I run a lot of mods (80+) and I find that Manifest sometimes work, but sometimes just produces weird results. Science and crew work fine, but resources tend to be weird.

In the past, I've tried to transfer resources from a full tank to an empty tank, and ended up with it transferring -1 instead: the full tank becomes over-full and the empty tank becomes negative.

In my current game, I just tried to transfer fuel from my station's large (14k) Multipurpose Resource Tank XL (Hangar mod) to a Rockomax X200-16 tank on a ship docked to the station. The "Xfer" interface goes away, like it normally does when a transfer is in progress, but there's no sound and it never transfers anything, and aside from the Settings and Roster buttons, the entire Manifest UI is now unusable until I exit and reload.

Nothing in the KSP.log that I can see. Certainly nothing that appeared when the problem happened.

I have seen successful resource transfers in the past, so this isn't a case of being totally broken at all times, but it's definitely broken for this situation.

There had been reports of SM doing exactly what you have described with the "-1". I'd not personally seen that issue, but had made some small changes that should have corrected this issue. There was an incompatibility with Kerbal Mechanics and highlighting but we resolved that with a fix to Kerbal Mechanics. Other than that I know of no incompatibilities with other mods.

As far as the issue with it just becoming unusable. That is new. Let me know what version of SM you are using, and what settings you have (realism mode, etc). Also, what would be very helpful is steps to reproduce if you can make it happen consistently.

Finally, I have my own log built in. Set Enable Debugger Window in settings, and turn on verbose logging. there may be something in that window that can help identify the issue, and you can save the log to disk, so that I can look.

I've just gone through the resource transfer process and added a stop button, and revisions to how it works. Again, I've not seen the issue, but hopefully we can track it down.

Upcoming release 4.0.2 will have the following:

Version 0.90.0_4.0.2 - Release 13 Feb, 2015 - Bugs, Mod Refactoring and More Edition.

- New: Added New resource transfer features. Now you can stop a transfer in progress.

- -- -- - Additionally you can now change the min and max flow rate in Settings.

- -- -- - Finally, you can also set a maximum run time in seconds.

- -- -- - System will use the lesser duration of flow rate or max time.

- New: Added tool tips to controls in the options section of the Settings Window.

- Bug: When moving or transferring a kerbal, closing the transfer window, Manifest window or closing the manifest window from any toolbar while the action is in progress causes an error.

- Bug: When closing the Transfer Window, internally resetting the selected resource causes an error.

should be out on the 13th of Feb.

Edited February 13, 2015 by Papa_Joe

[JPLRepo]

Thanks for the new version the new hatch options are great and so glad that highlighting has been fixed.

[WuphonsReach]

I know that the -1 bug still crops up occasionally in ShipManifest.90.0_3.3.4_01152014 (I'm waiting for 4.0.2). The workaround is still - go back to the space center or another craft, then come back. The bug most frequently occurs right after docking two ships together.

[Papa_Joe]

I know that the -1 bug still crops up occasionally in ShipManifest.90.0_3.3.4_01152014 (I'm waiting for 4.0.2). The workaround is still - go back to the space center or another craft, then come back. The bug most frequently occurs right after docking two ships together.

That would be correct.

I'm not sure why you would wait for 4.0.2, as 4.0.0 and up are great improvements over that version. Although, I've completely refactored the resource transfer display and setup mechanics for 4.0.2 (it was year old code and I've learned some since then). The negative bug will definitely be squashed with this version.

4.0.2 will be out tonight. I'm performing final testing now.

Edited February 13, 2015 by Papa_Joe

[Papa_Joe]

4.0.2 will be out tonight. I'm performing final testing now.

New version released:

Version 0.90.0_4.0.2 - Release 13 Feb, 2015 - Bugs, Mod Refactoring and More Edition.

- New: Resource Transfer display and setup system refactored. Added ability to stop a transfer in progress.

- New: Exposed Resource Transfer Flow Rate Slider min and max values. You can now change the min and max flow rate.

- New: Added a maximum run time in seconds. SM will use the lesser duration of Xfer amount / flow rate or max time.

- New: Added tool tips to controls in the options section of the Settings Window.

- Bug: When moving or transferring a kerbal, closing the transfer window, Manifest window or closing the manifest window from any toolbar while the action is in progress causes an error.

- Bug: When closing the Transfer Window, internally resetting the selected resource causes an error.

Also, just a reminder. If tool tips get in your way, just turn them off, or turn them off for certain windows.

Edited February 14, 2015 by Papa_Joe

[Papa_Joe]

Thanks for the new version the new hatch options are great and so glad that highlighting has been fixed.

Sorry I missed this earlier. Thanks, I'm glad you're enjoying the new version.

[WuphonsReach]

The negative bug will definitely be squashed with this version.

Not squashed yet in 4.0.2. Docking two ships and then immediately attempting to transfer LiquidFuel causes the stop button to appear, but nothing transfers. Will see if I can get something to show up in a log file.

Worse - now, even if I jump to another ship (or KSC) and come back, the Ship Manifest UI is "stuck" and won't let me switch to a different resource or restart the transfer. I have to exit out of KSC and come back in to fix it. (Under the previous version, switching away to another vessel and then coming back always fixed the -1 bug.)

Note: Was using Connected_Living_Space-1.1.0.0, will try with CLSv1.1.1.0. Will be a bit before I do another docking.

Edited February 16, 2015 by WuphonsReach

[Papa_Joe]

Not squashed yet in 4.0.2. Docking two ships and then immediately attempting to transfer LiquidFuel causes the stop button to appear, but nothing transfers. Will see if I can get something to show up in a log file.

Worse - now, even if I jump to another ship (or KSC) and come back, the Ship Manifest UI is "stuck" and won't let me switch to a different resource or restart the transfer. I have to exit out of KSC and come back in to fix it. (Under the previous version, switching away to another vessel and then coming back always fixed the -1 bug.)

Note: Was using Connected_Living_Space-1.1.0.0, will try with CLSv1.1.1.0. Will be a bit before I do another docking.

The CLS version will definitely impact you. The changes in 1.1.1.0 are REQUIRED if you use CLS with SM 4.0.0 or higher. I performed the exact test you just did (many times using my newly built space station over Kerbin) and all is working fine. However, I was using a current version of CLS. You can also test this by turning off CLS in Settings to see if things are better.

Also, I noted a couple of errors I introduced with my refactoring. Changing scenes introduces an error with CLS instantiation. Turning off CLS will work around this as well I'm resolving this now.

Also, In the SETI balance Mod thread, someone mentioned it would be nice to be able to Extend or Retract all solar panels. Brilliant Idea. I've added a Solar Panel management Window to SM. Already working. Works like hatch management.

Hope to have a new version very soon. Sorry for the inconvenience as I clean up the Code that was once spaghetti...

Edited February 16, 2015 by Papa_Joe

[Yemo]

Also, In the SETI balance Mod thread, someone mentioned it would be nice to be able to Extend or Retract all solar panels. Brilliant Idea. I've added a Solar Panel management Window to SM. Already working. Works like hatch management.

Great addition!

Just wanted to add, that not all solar panels are retractable based on StockRebalance by stupid_chris and CaptRobau:

//OX-4W 2x3 Photovoltaic Panels
@PART[solarPanels3]:FOR[SETI]
{
    @title = Electrics: Solar Panels OX-4W 2x3

    @MODULE[ModuleDeployableSolarPanel]
    {
        retractable = false
    }
}

[Papa_Joe]

Great addition!

Just wanted to add, that not all solar panels are retractable based on StockRebalance by stupid_chris and CaptRobau:

//OX-4W 2x3 Photovoltaic Panels
@PART[solarPanels3]:FOR[SETI]
{
    @title = Electrics: Solar Panels OX-4W 2x3

    @MODULE[ModuleDeployableSolarPanel]
    {
        retractable = false
    }
}

Thanks for that! a I'll be sure to respect that setting in realism.

[WuphonsReach]

Yep, upgrading to 1.1.1.0 fixes the -1 error that occurred right after docking (wish CLS had the version check feature). PEBKAC on my part.

Also, the "Xfer Remaining" number is a larger font size then the rest of the text on the line. The transfer sub-window (that lets you move from tank A to is not saving its window position.

...

Still thinking about how to improve the maximum time limit feature on transfers. The current implementation makes a lot of sense when you are dumping 100% of one big tank to another big tank, but isn't optimal for a case where you are only moving 10% of one big tank to the other big tank. Both transfers end up taking 180 seconds (when in the second case it would make more sense for it to only take 18-36 seconds).

#1 - Calculate the transfer rate based on the source tank being 100% emptied in 180 seconds. The gameplay idea here is that it's the source tank that drives the transfer. For big tanks filling up little tanks, it would go faster. For small tanks filling up big tanks, it would go slower.

Example 1a: Source tank holds 210k units, target tank holds 840k units. To drain the source tank from 100% to 0% in 180 seconds = 210k/180s = 1167 flow rate. Thus, if I move only 50k units, the time ends up as 43 seconds (not the full 180s).

Example 1b: Source is 840k, target is 210k sized tank. So transfer rate should be 840k/180s = 4667 flow. Moving 50k units takes 10.7s.

#2 - Calculate the sum of both tank sizes, set the transfer rate to be such that emptying both tanks would take 180s. Transfers end up being really quick in this scenario, much faster then the maximum 180s transfer time (in the case of equal sized tanks, worst-case is a 90s transfer).

Example 2: Tank sizes are 840k and 210k (target/source does not matter). Transfer rate would be (840k+210k)/180s = 5833 flow. Moving 50k units between those two tanks would take 8.6s. Moving 210k from one to the other would take 36 seconds.

#3 - Calculate the average of the two tank sizes, and base flow rate on that.

Example 3: So (840k+210k)/2/180s = 2917 flow rate. Moving 50k units takes 17.1s. Worst case time of moving 210k from one tank to the other would take 72s.

...

Personally, I lean towards #3 as the option, but #2 also avoids the issue.

Edited February 16, 2015 by WuphonsReach

[Papa_Joe]

Yep, upgrading to 1.1.1.0 fixes the -1 error that occurred right after docking (wish CLS had the version check feature). PEBKAC on my part.

Also, the "Xfer Remaining" number is a larger font size then the rest of the text on the line. The transfer sub-window (that lets you move from tank A to is not saving its window position.

...

Still thinking about how to improve the maximum time limit feature on transfers. The current implementation makes a lot of sense when you are dumping 100% of one big tank to another big tank, but isn't optimal for a case where you are only moving 10% of one big tank to the other big tank. Both transfers end up taking 180 seconds (when in the second case it would make more sense for it to only take 18-36 seconds).

#1 - Calculate the transfer rate based on the source tank being 100% emptied in 180 seconds. The gameplay idea here is that it's the source tank that drives the transfer. For big tanks filling up little tanks, it would go faster. For small tanks filling up big tanks, it would go slower.

Example 1a: Source tank holds 210k units, target tank holds 840k units. To drain the source tank from 100% to 0% in 180 seconds = 210k/180s = 1167 flow rate. Thus, if I move only 50k units, the time ends up as 43 seconds (not the full 180s).

Example 1b: Source is 840k, target is 210k sized tank. So transfer rate should be 840k/180s = 4667 flow. Moving 50k units takes 10.7s.

#2 - Calculate the sum of both tank sizes, set the transfer rate to be such that emptying both tanks would take 180s. Transfers end up being really quick in this scenario, much faster then the maximum 180s transfer time (in the case of equal sized tanks, worst-case is a 90s transfer).

Example 2: Tank sizes are 840k and 210k (target/source does not matter). Transfer rate would be (840k+210k)/180s = 5833 flow. Moving 50k units between those two tanks would take 8.6s. Moving 210k from one to the other would take 36 seconds.

#3 - Calculate the average of the two tank sizes, and base flow rate on that.

Example 3: So (840k+210k)/2/180s = 2917 flow rate. Moving 50k units takes 17.1s. Worst case time of moving 210k from one tank to the other would take 72s.

...

Personally, I lean towards #3 as the option, but #2 also avoids the issue.

I intentionally made the remaining transfer amount bold and larger. Don't like it?

The Transfer Window does not remember it's position? I'll look at the config file to see If I changed a name or made a spelling error in my settings configuration.

As far as the rate, I see your point. I'm only considering the amount to transfer and not the tank sizes... it would likely be more realistic to consider the tank size in determining the rate (simulating pump size, heh) Option 3 is certainly doable, and would seem to make sense. But, if we consider the pump source... (Pull or push?), then it might make sense to use the source tank's volume for the calculation. With Push in mind, Option 1 makes more sense.

Thoughts?

Edit: I checked my code, and the Transfer Window should be saving its location... the config file contains a reference to it. check to see if it is there... Second from the top of the file.

    <rect name="ManifestPosition">
        <xmin>359</xmin>
        <xmax>682</xmax>
        <ymin>791</ymin>
        <ymax>1079</ymax>
    </rect>
    <rect name="TransferPosition">
        <xmin>683</xmin>
        <xmax>1305</xmax>
        <ymin>791</ymin>
        <ymax>1080</ymax>
    </rect>
    <rect name="RosterPosition">
        <xmin>277</xmin>
        <xmax>668</xmax>
        <ymin>232</ymin>
        <ymax>582</ymax>
    </rect>
    <rect name="SettingsPosition">
        <xmin>277</xmin>
        <xmax>668</xmax>
        <ymin>232</ymin>
        <ymax>582</ymax>
    </rect>
    <rect name="HatchPosition">
        <xmin>624</xmin>
        <xmax>1010</xmax>
        <ymin>103</ymin>
        <ymax>363</ymax>
    </rect>
    <rect name="DebuggerPosition">
        <xmin>1254</xmin>
        <xmax>1770</xmax>
        <ymin>269</ymin>
        <ymax>629</ymax>
    </rect>

Edited February 16, 2015 by Papa_Joe

[Dermeister]

Crew manifest won't allow me to rename kerbals anymore? Am I missing something it used to be easy but now it seems impossible to do. Does any 1 know how to rename kerbals?

[Papa_Joe]

Crew manifest won't allow me to rename kerbals anymore? Am I missing something it used to be easy but now it seems impossible to do. Does any 1 know how to rename kerbals?

With the addition of careers in KSP, renaming a Kerbal changes their profession. So, if you had a pilot, and you rename your kerbal, they could become a Scientist or Engineer... In career mode, it can affect ship's performance... no pilot, no sas, etc...

I cannot answer for Crew Manifest (http://forum.kerbalspaceprogram.com/threads/60936), it may well still allow renaming. But In Ship Manifest, in order to prevent "disasters", I removed the ability to Rename Kerbals in version 3.3.4. I'm still researching a means to allow it, but it seems that Squad has linked the two together. A kerbal with the same name will always have the same profession, regardless of the save game they are in. If you want renaming, use version 3.3.3.

If enough people want to be able to rename, and don't care about the effects of that, I could add a switch in Settings to allow it (Use at your own risk!).

As is shown in several previous posts a few pages back, we have been experimenting with this in hopes of coming up with a workaround...

So far, no luck

Edited February 17, 2015 by Papa_Joe

[Superfluous J]

So far, no luck

I don't understand why it's not working for you programmatically. I've renamed a dozen Kerbals to various "Kerman:):)" combinations in my personal save and without more than 5 or so smiley faces I've been able to set each guy's name and profession to what I want.

Can't you just* have a "rename" button that, once you type the name you want keeps renaming the guy (internally, not visibly in the game) and checking his profession?

(example, not based on real data in the game)

Gene Kerman is an Engineer

I click "rename" and make him Fred Kerman

You check, Fred Kerman is a Scientist.

You change his name to Fred Kerman:) who is also a Scientist.

You change his name to Fred Kerman:) who is a Pilot.

You change his name to Fred Kerman:):) who is an engineer.

You set the actual guy's name to Fred Kerman:):) which looks like Fred Kerman in the game, is an engineer, and makes everybody happy.

It could even work if I wanted to change Gene Kerman from an Engineer to a Scientist, just keep adding 's to his name until you get the right profession.

*Caution! Non-programmer using the word "just" to describe how easy code would be!

[Papa_Joe]

I don't understand why it's not working for you programmatically. I've renamed a dozen Kerbals to various "Kerman:):)" combinations in my personal save and without more than 5 or so smiley faces I've been able to set each guy's name and profession to what I want.

Can't you just* have a "rename" button that, once you type the name you want keeps renaming the guy (internally, not visibly in the game) and checking his profession?

(example, not based on real data in the game)

Gene Kerman is an Engineer

I click "rename" and make him Fred Kerman

You check, Fred Kerman is a Scientist.

You change his name to Fred Kerman:) who is also a Scientist.

You change his name to Fred Kerman:) who is a Pilot.

You change his name to Fred Kerman:):) who is an engineer.

You set the actual guy's name to Fred Kerman:):) which looks like Fred Kerman in the game, is an engineer, and makes everybody happy.

It could even work if I wanted to change Gene Kerman from an Engineer to a Scientist, just keep adding 's to his name until you get the right profession.

*Caution! Non-programmer using the word "just" to describe how easy code would be!

Maybe I misunderstood your last post. I was under the impression that the test DLL did not work as described. What you are describing here is different that what I implemented.

I'll take another look at that methodology to see if it does work. I had moved on to the "other" method I had described just after, that did NOT work after all..

Finally, are you using these renamed kerbals in your career games with no issues?

[Dermeister]

With the addition of careers in KSP, renaming a Kerbal changes their profession. So, if you had a pilot, and you rename your kerbal, they could become a Scientist or Engineer... In career mode, it can affect ship's performance... no pilot, no sas, etc...

I cannot answer for Crew Manifest (http://forum.kerbalspaceprogram.com/threads/60936), it may well still allow renaming. But In Ship Manifest, in order to prevent "disasters", I removed the ability to Rename Kerbals in version 3.3.4. I'm still researching a means to allow it, but it seems that Squad has linked the two together. A kerbal with the same name will always have the same profession, regardless of the save game they are in. If you want renaming, use version 3.3.3.

If enough people want to be able to rename, and don't care about the effects of that, I could add a switch in Settings to allow it (Use at your own risk!).

As is shown in several previous posts a few pages back, we have been experimenting with this in hopes of coming up with a workaround...

So far, no luck

Yea I don't really care about profession change because once you change the name you usually leave it as is. also it's nice to be able to delete bob jeb and the other 1 I get tired of those 3. But perhaps like you say put a warning or something. But I see why you did it that way. It's just nice to have the choice.

[Papa_Joe]

Yea I don't really care about profession change because once you change the name you usually leave it as is. also it's nice to be able to delete bob jeb and the other 1 I get tired of those 3. But perhaps like you say put a warning or something. But I see why you did it that way. It's just nice to have the choice.

I'm looking at what 5thHorsman suggested as a potential work around. I'm not keen to "hack" the names, but if I can get confirmation that the hack does not impact any career mode features (I'm thinking it won't), then I'll add that in.

Thanks for using SM!

Also, an update. I've determined the cause of scene switching errors and have a working fix in code. Testing it now, but looks good. Release should be soon:

Change log:

Version 0.90.0_4.1.0 - Release xx Feb, 2015 - Solar Panels, Bugs, Mod Refactoring and More Edition.

- New: Added Deployable Solar Panel Management Window. Works like Hatch panel. In realism Mode, respects Rectractable = false.

- New: Refactored Crew Transfer Display code, Hatch Panel code and data management. Relocated some methods to more logical locations.

- New: Added switch to allow renaming Kerbals. Added support for maintaining professions after rename. Adds non printing chars to name, so use at your own risk.

- Bug: After switching scenes and selecting a part with CLS enabled an highligting error occurs.

- Bug: after switching scenes and using Hatch panel, an error occurs in highlighting.

- Bug: After switching vessels, the hatch panel shows the old vessel info and is not updated. Additionally, CLS highlighting causes errors.

[Superfluous J]

Maybe I misunderstood your last post. I was under the impression that the test DLL did not work as described. What you are describing here is different that what I implemented.

I'll take another look at that methodology to see if it does work. I had moved on to the "other" method I had described just after, that did NOT work after all..

Finally, are you using these renamed kerbals in your career games with no issues?

The DLL didn't work, but the concept seems to be perfect.

And I've not played it a lot, but I have a dozen or so such named Kerbals and have played for a few hours with no ill effects.

[Papa_Joe]

I was thinking about making a mod to allow renaming Kerbals without changing professions when I discovered this thread. In my testing I found that Kerbal professions reset when the "onGameStateLoad" event was triggered. So I tried setting the profession at that point and it seemed to persist across scene changes. Perhaps something similar would work for ShipManifest.

I'm looking at the rename with profession save again, and you mentioned setting the profession at OnGameStateLoad. how did you accomplish that?

A code snippet would save me some research time...

[Papa_Joe]

The DLL didn't work, but the concept seems to be perfect.

And I've not played it a lot, but I have a dozen or so such named Kerbals and have played for a few hours with no ill effects.

Thanks. I'm attempting to implement it now. One of the issues is related to the fact that I'm using the random kerbal generator, to get a specific Profesison, as it seems I haven't found the means to create a kerbal by name and then change their profession.

If what badpandabear says is true, then I won't know what the actual profession for a given kerbal is until I persist it via a game save. Looking at that now... Part of why I "thought" i had it earlier was that it does not automatically change the profession upon renaming. It seems it creates the profession at GameStateLoad (when the savegame is loaded - at start up or after a save).

May still be doable, but I may possibly have to perform multiple saves...

Edited February 18, 2015 by Papa_Joe

[badpandabear]

I'm looking at the rename with profession save again, and you mentioned setting the profession at OnGameStateLoad. how did you accomplish that?

A code snippet would save me some research time...

Basically I've been trying to directly set the Kerbal's profession whenever the game automatically resets it based on the name. I'm using a scenario module to persist the name/profession mapping to the saved game. The code looks like:

    // Note I hate the name FlexibleProfession
    [KSPScenario(ScenarioCreationOptions.AddToAllGames,new GameScenes[]{GameScenes.EDITOR,GameScenes.FLIGHT,GameScenes.SPACECENTER})]
    public class FlexibleProfessionScenario : ScenarioModule
    {
//stuff
        public override void OnLoad(ConfigNode node)
        {
            foreach (ConfigNode child in node.GetNodes(FPConstants.KERBAL_SUBNODE))
            {
                KerbalProfessionData loadedKerbal = new KerbalProfessionData();
                loadedKerbal.Load(child);
                if (loadedKerbal.KerbalName != null)
                {
                   KerbalRoster.SetExperienceTrait(crew, loadedKerbal.Title);
                   // Other stuff to store loadedKerbal
                }
            }
        }
//stuff
    };

In my testing I've found that calling "KerbalRoster.SetExperienceTrait( someProtoCrewMember )" will recompute the profession based on protoCrewMember's name. That should be easier for the append non-printable character approach.

BTW The reason I'm trying something different is that I thought it might be cool to try making a new custom profession. When I try that it reshuffles all the professions for the non-orange suited Kerbals--which seems bad for an existing saved game. But I have another problem in that Vessels won't recognize my Pilots as being able to use SAS unless they EVA first. Edited: Now it's fixed! Time for bed

Edited February 18, 2015 by badpandabear

[Papa_Joe]

Basically I've been trying to directly set the Kerbal's profession whenever the game automatically resets it based on the name. I'm using a scenario module to persist the name/profession mapping to the saved game. The code looks like:

    // Note I hate the name FlexibleProfession
    [KSPScenario(ScenarioCreationOptions.AddToAllGames,new GameScenes[]{GameScenes.EDITOR,GameScenes.FLIGHT,GameScenes.SPACECENTER})]
    public class FlexibleProfessionScenario : ScenarioModule
    {
//stuff
        public override void OnLoad(ConfigNode node)
        {
            foreach (ConfigNode child in node.GetNodes(FPConstants.KERBAL_SUBNODE))
            {
                KerbalProfessionData loadedKerbal = new KerbalProfessionData();
                loadedKerbal.Load(child);
                if (loadedKerbal.KerbalName != null)
                {
                   KerbalRoster.SetExperienceTrait(crew, loadedKerbal.Title);
                   // Other stuff to store loadedKerbal
                }
            }
        }
//stuff
    };

In my testing I've found that calling "KerbalRoster.SetExperienceTrait( someProtoCrewMember )" will recompute the profession based on protoCrewMember's name. That should be easier for the append non-printable character approach.

BTW The reason I'm trying something different is that I thought it might be cool to try making a new custom profession. When I try that it reshuffles all the professions for the non-orange suited Kerbals--which seems bad for an existing saved game. But I have another problem in that Vessels won't recognize my Pilots as being able to use SAS unless they EVA first. Edited: Now it's fixed! Time for bed

Interesting. I was looking at that method. wondered if it would behave that way. I'm going to play around with that class and see what I can find.. I'll post my results. I'm very close now...

Edit: That works great! Looks like we have a workable solution. Thanks for the insight! Now I can create a Kerbal with the desired profession and rename as desired.

Edited February 18, 2015 by Papa_Joe