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

WarrenSchultz · May 29, 2015

I thought I remembered this being possible, but I couldn't seem to find it last night. Is it possible in SM to switch kerbals to specific seats? Being able to swap two from the same pod would be handy also. (For IVA flying).

Thanks!

Papa_Joe · May 29, 2015

I thought I remembered this being possible, but I couldn't seem to find it last night. Is it possible in SM to switch kerbals to specific seats? Being able to swap two from the same pod would be handy also. (For IVA flying).
Thanks!

Yes. That feature is discussed in my WIki here: https://github.com/PapaJoesSoup/ShipManifest/wiki/2.1---Crew-Transfers

Look at Seat to Seat transfers. However due to the way that IVA works in KSP, SM will disable itself in IVA mode, so xferring kerbals cannot be accomplished while in IVA mode. Also, if you have tooltips on, when you mouse over the buttons in the crew transfer window, it should tell you what a certain buttons does.

Edited May 29, 2015 by Papa_Joe

WarrenSchultz · May 29, 2015

/facepalm. Thanks. I knew it was something simple, but apparently I needed a big, blinking signpost.

Papa_Joe · May 29, 2015

/facepalm. Thanks. I knew it was something simple, but apparently I needed a big, blinking signpost.

No worries. Remember, there are NO stupid questions.

Papa_Joe · May 31, 2015

Update.

I've been working with JPLRepo on DeepFreeze compatibility. We are getting close, and it's looking good.

I wanted to share a screen shot of the changes to the Roster window to support DeepFreeze and that I've incorporated theses changes into Roster Manager as well.

Enjoy!

With that, the revised change notes for the upcoming release are:

Version 4.3.0.0 - Release xx May, 2015 - CrewTransfer Interface & Refactoring Edition.

- New: Refactored Crew transfers into separate class to improve visibility and state management.

- New: Added DeepFreeze mod support for handling/viewing frozen kerbals.

- New: Added SMInterface.dll for other mods to detect Crew xfers in progress and act accordingly.

- New: Added Kerbal Filter for Roster Window: All, vessel, Available, Dead/Missing. Vessel filter is omitted when in Space Center.

- New: Refactoring - moved window vars from Settings into window level code.

- New: Added InstalledMods static class to support centralized assembly detection and soft dependencies.

- New: Altered Settings Save to segregate Hidden settings for ease of identification by users.

- Fixed: Bug in multi-part transfers that lock transfer in run state, with no progress.

- Fixed: Bug in Crew Transfer with CLS installed. First transfer works fine, subsequent xfers fail, and Transfer is stuck in moving...

Edited May 31, 2015 by Papa_Joe

Papa_Joe · May 31, 2015

I don't have a save that I can currently test for repro on, but there appears to be an issue with transferring crew and losing KIS inventory.
For example: Engineer in one module with the screwdriver in his inventory, transferred him to another module. Realized later when he went to EVA that he no longer had the screwdriver.

I'm following up on this, as part of my KIS integration.

Can you tell me if a stock crew transfer moves the inventory? Looking at the KIS code, it appears that it will. If so, then I believe I have a working fix for the issue. It will also now expose the actual crew transfer to other mods when I've completed my transfer, as I'm going to fire the OnCrewTransferred event. KIS looks for that...

Edited May 31, 2015 by Papa_Joe

Speadge · June 1, 2015

Update:
I have published the code changes for Release 4.3.0.0 to Github. It is ready for integration testing by JPLRepo. From what I understand he will need a bit of time to absorb and integrate (several days).

Hoi,

i experienced some crashes on transfering and wanted to make sure it is fixed now.

can you help me compiling your .cs? somehow i'm just 2 stupid 2 do it on my own

regards.

Papa_Joe · June 2, 2015

In order to compile, you will need to change the references that it points to. in the projects

In particular, the following dlls are typically in different places, depending on your game application installation

1. Assembly-CSharp

2. Assembly-CSharp-firstpass

3. UnityEngine

These file resides in the "KSP_win\KSP_Data\Managed" folder of your game installation.

Additionally, I'm referencing CLSInterfaces, which is in the "GameData\ShipManifest\Plugins" folder

Finally, as part of the post build, I have copy functions that overwrite the dll files in the "GameData\ShipManifest\Plugins" folder These entries should be either deleted, or changed to point to your game installation location.

Hope that helps. If you are still having issues, I can release a pre-release xip of the current code. This file will be subject to change as integration with KIS and DeepFreeze continue.

Speadge · June 2, 2015

I can release a pre-release xip of the current code. This file will be subject to change as integration with KIS and DeepFreeze continue.

If you dont mind, i think that would make thinks much more easier...

and in return i can give feedback if my crashes are really adressed, as u stated in the changelog

Papa_Joe · June 2, 2015

In order to compile, you will need to change the references that it points to. in the projects
In particular, the following dlls are typically in different places, depending on your game application installation
1. Assembly-CSharp
2. Assembly-CSharp-firstpass
3. UnityEngine
These file resides in the "KSP_win\KSP_Data\Managed" folder of your game installation.
Additionally, I'm referencing CLSInterfaces, which is in the "GameData\ShipManifest\Plugins" folder
Finally, as part of the post build, I have copy functions that overwrite the dll files in the "GameData\ShipManifest\Plugins" folder These entries should be either deleted, or changed to point to your game installation location.
Hope that helps. If you are still having issues, I can release a pre-release xip of the current code. This file will be subject to change as integration with KIS and DeepFreeze continue.

I've gone ahead and issued a release candidate on github here: https://github.com/PapaJoesSoup/ShipManifest/releases/tag/4.3.0.0rc

Version 4.3.0.0rc - Release 01 June, 2015 - Crew, Interfaces, & Refactoring Edition.

NOTE: This is a release candidate and not an official release. the contents of this archive are subject to change as testing continues.

- New: Refactored Crew transfers into separate class to improve visibility and state management.

- New: Crew transfers (part to part & seat to seat) now show both kerbals involved as moving, when a kerbal swap occurs.

- New: Added DeepFreeze mod support for handling/viewing frozen kerbals. No more xferring frozen kerbals, and Roster Window now shows frozen kerbals.

- New: Added SMInterface.dll for other mods to detect Crew xfers in progress and act accordingly.

- New: Add onCrewTransferred Event trigger to be consistent with Stock Crew Transfers and to support KIS inventory movement when crew transfers occur.

- New: Added Kerbal Filter for Roster Window: All, vessel, Available, Dead/Missing. Vessel filter is omitted when in Space Center.

- New: Refactoring - moved window vars from Settings into window level code.

- New: Refactoring - Added InstalledMods static class to centralize mod assembly detection and soft dependencies.

- New: Refactoring - Altered Settings Save to segregate Hidden settings for ease of identification by users.

- Fixed: Bug in multi-part transfers that lock transfer in run state, with no progress.

- Fixed: Bug in Crew Transfer with CLS installed. First transfer works fine, subsequent xfers fail, and Transfer is stuck in moving...

As the release notes indicate, this release is subject to change as JPLRepo is still testing the integration with DeepFreeze. I've also added the event trigger for KIS, but this is still untested in terms of it's affect with KIS at the moment. I would be interested in hearing if it is now working with KIS.

The RC is stable, so I don't expect any issues, but as with all pre-release software, backup your game save (standard precaution) and use at your own risk. When I get the good word from JPLRepo or make any needed changes I'll be releasing this version.

Finally, the Wiki has been updated to reflect the changes contained in this release.

Enjoy.

Edited June 2, 2015 by Papa_Joe

Speadge · June 2, 2015

I've gone ahead and issued a release candidate on github here: https://github.com/PapaJoesSoup/ShipManifest/releases/tag/4.3.0.0rc
Enjoy.

Hey Pop,

wanted to give you a short feedback.

the crashes on transfer are really fixed. Was my main problem since it took many time for single-transfer.

Havent found another problem so far. will give you feedback as soon as.

Thanks again for the RC

Papa_Joe · June 2, 2015

Hey Pop,
wanted to give you a short feedback.
the crashes on transfer are really fixed. Was my main problem since it took many time for single-transfer.
Havent found another problem so far. will give you feedback as soon as.
Thanks again for the RC

Good news. Thanks for letting me know!

Speadge · June 3, 2015

ok, lil correction,

it just crashed again.

i was transferring monoprop from 1 tank to ~ 6 other. did this already twice in this flight without problems... the 3rd time it crashed the same way as before.

does the kind of tank matter to you?

edit: i can reproduce it, just aft 1 min gameplay. do yo need a savegame?

(stationscience required)

Edited June 3, 2015 by Speadge

Papa_Joe · June 3, 2015

ok, lil correction,
it just crashed again.
i was transferring monoprop from 1 tank to ~ 6 other. did this already twice in this flight without problems... the 3rd time it crashed the same way as before.
does the kind of tank matter to you?
edit: i can reproduce it, just aft 1 min gameplay. do yo need a savegame?
(stationscience required)

The kind of tank should not matter. I have to consider anything other than ElectricalCharge as a possible candidate. SM will also allow you to choose MonoProp and some other resource and transfer them in proportion.

When you say crashed, do you mean it gets stuck in transferring and never stops, or the game crashes, or what? If it is repeatable, is it possible to turn on verbose logging and save an SM Debug window log?

From the sound of it, it could be possible that i'm not properly resetting some transfer related variable, but not sure.

A savegame will likely not help. I tested transfers using monoprop and 1: 8 tanks, and 4: 8 tanks etc... I have a space station that makes this kind of testing pretty easy.

I'll go over it again..

If you can get a screenshot that would also help...

We definitely want to put this to bed with this release.

Edited June 3, 2015 by Papa_Joe

Speadge · June 3, 2015

If it is repeatable, is it possible to turn on verbose logging and save an SM Debug window log?

game is crashing with hanging sound.

i tried the logging, but it didnt seem that it logged something - or i just did not look in right folder...

trying for a screen...

sorry i couldnt scroll the debug down.

Its not related to the 0.11 left, as it happens randomly, sometimes few milliseconds after starting.

game crashes in a frozen screen (thats why th pic looks not that sharp;) ) & sound keeps running.

btw: often it helps not setting for full amount but a littl less. - which is not helping if one of the destination tanks is full already

Edited June 3, 2015 by Speadge
pic

Papa_Joe · June 3, 2015

Thanks. This will help loads.

Off to get it fixed...

Speadge · June 3, 2015

Thanks. This will help loads.

nice to know.

Looking forward to a stable version.

many thanks for your time!

Short addition: it happens now far less than before.

And i have seen, that the amounts to transfer vary each time i chose the tanks to transfer from.

Its within the last 5 digits after the dot (.)

Perhaps it would fix if you dont make it that detailed but just round (down) to 2 digits?

I think its because it wants to transfer sth that is not available or is no storage for (storage left calculation on the right is also too detailed and varies with each (de-)selection of the tank).

Edited June 3, 2015 by Speadge

Papa_Joe · June 4, 2015

nice to know.
Looking forward to a stable version.
many thanks for your time!
Short addition: it happens now far less than before.
And i have seen, that the amounts to transfer vary each time i chose the tanks to transfer from.
Its within the last 5 digits after the dot (.)
Perhaps it would fix if you dont make it that detailed but just round (down) to 2 digits?
I think its because it wants to transfer sth that is not available or is no storage for (storage left calculation on the right is also too detailed and varies with each (de-)selection of the tank).

Well, I've refactored the Resource transfer system. (needed it anyway). also made some changes to the crew transfer interface and cleaned up Non Realism crew transfers (portraits were not updating properly...)

I've beat the resource transfer to death, and cannot reproduce the error you are getting.

Going to update the RC with the new code. When you get a chance, play with it and let me know.

Thanks!

Oops, spoke too soon. Duplicated the issue with a multi resource transfer...

Back to the drawing board... Time to instrument it a bit differently and add a timeout feature to aid in troubleshooting.

I'll let you know later today.. Time for sleep for me.

Edited June 4, 2015 by Papa_Joe

Papa_Joe · June 4, 2015

Well, I've refactored the Resource transfer system. (needed it anyway). also made some changes to the crew transfer interface and cleaned up Non Realism crew transfers (portraits were not updating properly...)
I've beat the resource transfer to death, and cannot reproduce the error you are getting.
Going to update the RC with the new code. When you get a chance, play with it and let me know.
Thanks!
Oops, spoke too soon. Duplicated the issue with a multi resource transfer...
Back to the drawing board... Time to instrument it a bit differently and add a timeout feature to aid in troubleshooting.
I'll let you know later today.. Time for sleep for me.

Ok. Found the issue.

It was indeed double var resolution. I divide the an amount that is calculated against a flow rate and an elapsed time counter (timestamp) by the number of parts to which I will be moving a resource. as a result, it can get numbers that are very small... if i divide an extremely small number, I exceed the resolution of the double, and end up with a zero as a result. So, I end up with an endless loop because I never actually move ALL of the amount I request.

So I changed the equality statement looking for remainder = 0 to remainder < 0.0000001. This provides a reasonable resolution, and still provides reasonable accuracy.

I also included a "timeout" feature to prevent deadlocking of the loops I run "just in case" .

I've tested, and it is working. New release candidate is out at GitHub.

Edited June 4, 2015 by Papa_Joe

JPLRepo · June 4, 2015

Ok. Found the issue.
It was indeed double var resolution. I divide the an amount that is calculated against a flow rate and an elapsed time counter (timestamp) by the number of parts to which I will be moving a resource. as a result, it can get numbers that are very small... if i divide an extremely small number, I exceed the resolution of the double, and end up with a zero as a result. So, I end up with an endless loop because I nvever actualll move ALL of the amount I request.
So I changed the equality statement looking for remainder = 0 to remainder < 0.0000001. This provides a reasonable resolution, and still provides reasonable accuracy.
I also included a "timeout" feature to prevent deadlocking of the loops I run "just in case" .
I've tested, and it is working. New release candidate is out at GitHub.

Well done.

Speadge · June 4, 2015

Gonna be a long night testing:D

Thank you.

Papa_Joe · June 4, 2015

Gonna be a long night testing:D
Thank you.

No. Thank YOU for the testing effort to make SM better.

TheReadPanda · June 4, 2015

I experienced today for the first time ever a thing where I transfered a kerbal from one part of a minmus base to another... and they just 'vanished'.

Happened a few times, all using ship manifest kerbal transfers. Anyone else have this happen? Is this a known anything or other?

later I was able to make it work okay so it seemed to be isolated, but thought I should mention it.

Papa_Joe · June 4, 2015

I experienced today for the first time ever a thing where I transfered a kerbal from one part of a minmus base to another... and they just 'vanished'.
Happened a few times, all using ship manifest kerbal transfers. Anyone else have this happen? Is this a known anything or other?
later I was able to make it work okay so it seemed to be isolated, but thought I should mention it.

Did you have realism off? Also, were your transferring to a full part?

I noticed when I refactored the crew transfer code that this condition was possible if you transferred a kerbal to a full part with realism off.... poof gone.

Crew transfers were significantly refactored for the new version to support DeepFreeze, so I fixed this issue in the Release candidate above.

New "official" release soon. JPLRepo is nearing completion of his testing...

Edited June 4, 2015 by Papa_Joe

Papa_Joe · June 5, 2015

Did you have realism off? Also, were your transferring to a full part?
I noticed when I refactored the crew transfer code that this condition was possible if you transferred a kerbal to a full part with realism off.... poof gone.
Crew transfers were significantly refactored for the new version to support DeepFreeze, so I fixed this issue in the Release candidate above.
New "official" release soon. JPLRepo is nearing completion of his testing...

Update: New Version released:

Version 4.3.0.0 - Release 04 June, 2015 - Crew, Interfaces, & Refactoring Edition.