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

[Adampeay]

I downloaded the mod but there is no button to bring up all the transfer methods. I copied the contents of the game data folder into the ksp gamedata folder, but it's like nothing changed. Did I do something wrong.

[Pecan]

@Adampeay - have you installed all the dependencies, as explained in the OP? "NOTE: Dependencies now exist with CLS, Module manager, and Toolbar ... Toolbar is included with the release, but the others are not."

[Adampeay]

@Adampeay - have you installed all the dependencies, as explained in the OP? "NOTE: Dependencies now exist with CLS, Module manager, and Toolbar ... Toolbar is included with the release, but the others are not."

No I didn't catch that. Thanks

[Adampeay]

I accidently deleted the tool bar in the staging view. It's still in the orbiting view. Is there any way to get it back.

[Papa_Joe]

You can edit the toolbar config to re-enable it in that scene. \GameData\toolbar-settings.dat

Also, Blizzy78 likely has answers to these questons in his thread. that thread is linhked in my OP, near the top.

and here: http://forum.kerbalspaceprogram.com/threads/60863

[Papa_Joe]

So when I create a Kerbal in Crew Roster, how exactly do I put him in the vessel? There is no option to do so, only the fill crew thing which fills the ship with every single kerbal I hired.

The short answer is you don't. (other than the fill crew thingy)

Tbh, the Roster feature is largely untouched from it's origins in Crew Manifest. It certainly does need some love, and some enhancement.

I will put that on the short list for addressing.

I want to correct this statement. There IS a way to Add a Kerbal in the current version and likely a few versions back.

1. When in Pre-flight, Open Ship Manifest.

2. Then Open the roster and go to your available kerbals.

3. Select Crew in the Ship Manifest Window, and open the Transfer window.

4. Select the source part in which you want to place your Kerbal.

5. The Roster window "..." button text for the available kerbals will change to "Add" (if there is room in the part).

6. Add your kerbal.

Edited April 24, 2014 by Papa_Joe

[Aedile]

Hi, I am experiencing a weird glitch. When using this together with TACLS. I have a station build of modules. When I transfer crew, my LS resources get totally messed up - I get extra from everything. So basically everything gets topped up.

EDIT- possibly botched the udate

Edited April 25, 2014 by Aedile

[Papa_Joe]

Hi, I am experiencing a weird glitch. When using this together with TACLS. I have a station build of modules. When I transfer crew, my LS resources get totally messed up - I get extra from everything. So basically everything gets topped up.

EDIT- possibly botched the udate

It is also possible that recent changes are manifesting this. It was reported in the first version with CLS. I thought I may have corrected it, but I don't use TACLs. In order to support Texture Replacer, I've added an eva and a board action to the kerbal to facilitate proper texture updates. I'm thinking that this may be causing the conflict.

I will examine the TACLS code to see if I can notice anything.

[Gristle]

-1 to CLS requirement for this otherwise excellent tool.

[Fraz86]

Until you find a permanent solution, would you consider releasing an alternate version without the EVA & board actions for those of us who use TACLS but not texture replacer?

[Papa_Joe]

-1 to CLS requirement for this otherwise excellent tool.

-1 for the dependency, or for the integration?

if for the integration, you can set a switch and turn it off.

If for the dependency, I understand, and am considering some reflection code (thanks codepoet), to make CLS "optional".

Finally, the previous version 0.23.3.1.5, does not have this dependency and can be found on my Github repository http://github.com/PapaJoesSoup/ShipManifest, along with other previous releases.

Thanks for the feed back!

Edited April 25, 2014 by Papa_Joe

[Papa_Joe]

Until you find a permanent solution, would you consider releasing an alternate version without the EVA & board actions for those of us who use TACLS but not texture replacer?

If you are willing to help me troubleshoot, I will be glad to release a "revised" version to see if it helps. Then at least we will have narrowed the issue and I can see about correcting it.

[Fraz86]

If you are willing to help me troubleshoot, I will be glad to release a "revised" version to see if it helps. Then at least we will have narrowed the issue and I can see about correcting it.

Absolutely, I'd be happy to help with troubleshooting.

[codepoet]

-1 for the dependency, or for the integration?

if for the integration, you can set a switch and turn it off.

If for the dependency, I understand, and am considering some reflection code (thanks codepoet), to make CLS "optional".

Finally, the previous version 0.23.3.1.5, does not have this dependency and can be found on my Github repository http://github.com/PapaJoesSoup/ShipManifest, along with other previous releases.

Thanks for the feed back!

Reflection code to make CLS a soft rather than hard dependency is half written on my hard drive. If you can be patient I suggest waiting for it rather than writing your own.

[Papa_Joe]

Absolutely, I'd be happy to help with troubleshooting.

Okay.

https://github.com/PapaJoesSoup/ShipManifest/releases/download/0.23.5.3.2.1a/ShipManifest.23.5.3.2.1a_04252014.zip

I added a config file switch to enable/disable the Texture Replacer code. It is disabled by default.

Also, since I was mid update, you now have the ability to transfer crew members into a full Part. Crew members will swap places, just like when you move a karbal within a part. That will be included in the official 3.3 release as well.

Give it a whirl.

Reflection code to make CLS a soft rather than hard dependency is half written on my hard drive. If you can be patient I suggest waiting for it rather than writing your own.

Not a problem. There are options for those that have "heartburn" with it atm.

Edited April 25, 2014 by Papa_Joe

[TK421d]

i would like to see the CLS dependancy become optional too.

[Pecan]

As a rule optional dependencies are always good, for memory/processing reasons if nothing else.

That said - and I know you're reading this too codepoet! - I'm really starting to like, and design for, CLS and probably wouldn't have downloaded it if it hadn't been for SM. Kudos all around, in other words :-)

[codepoet]

As a rule optional dependencies are always good, for memory/processing reasons if nothing else.

That said - and I know you're reading this too codepoet! - I'm really starting to like, and design for, CLS and probably wouldn't have downloaded it if it hadn't been for SM. Kudos all around, in other words :-)

Thanks for the encouragement - it really helps! There is no reason that the CLS dependency needs to ruin anyone's gameplay as you can opt not to use it in SM, and of course having CLS support in SM enhances gameplay for those who want to use it. However, as has been already recognised, an optional dependency will be the best way forward.

[Papa_Joe]

As a rule optional dependencies are always good, for memory/processing reasons if nothing else.

That said - and I know you're reading this too codepoet! - I'm really starting to like, and design for, CLS and probably wouldn't have downloaded it if it hadn't been for SM. Kudos all around, in other words :-)

You are of course, correct, and I'm a proponent of choice for the community. I still have to learn how to do it, and with codepoet already into that, I'll be grateful to benefit from his efforts.

I'd planned on adding space awareness to Ship Manifest. I had seen it as a long term goal, as there was a bit of work to do to better understand parts. codepoet saw the need from a bigger picture and acted. I'm grateful for that as well.

As folks see the potential, and it is gradually realized, the dependency issue will become moot, even as I implement support for it being optional.

Mech Jeb is "optional" as well, right?

While CLS is not MechJeb (and neither is SM), living space IS at the heart of space exploration, is it not?

Imagine this scenario...

".. Jeb's kethane storage unit attached to the lab sprang a leak and is spewing kethane into the lab. Doomla living space atmosphere sensor units pick up the change in the space's atmosphere, and trigger alarrms. it also commands the closing of hatches to the lab, sealing it off from the rest of the station.

Jeb is alerted..."

That sounds very cool to me...

Potential Mods from that little scenario:

- LS stmospheres

- LS Disaster Emulator

- LS Emergency Automation.

- ...

Hmm... got some ideas....

Edited April 25, 2014 by Papa_Joe

[Fraz86]

Give it a whirl.

The TACLS resource duplication bug appears to be fixed in this version.

However, in the course of my testing I identified a different, equally problematic bug. ShipManifest does not seem to recognize the change in status of "deployable" living space modules, such as PorkJet's inflatable habs. In CLS terms, these habs begin as "passable" but without room for Kerbals to stay. Once inflated, the habs have space for Kerbals. CLS correctly identifies this change, with the habs immediately changing from yellow (passable) to green (habitable) when inflated. Unfortunately, though, the newly inflated hab is not added to ShipManifest's list of crew transfer locations.

[Papa_Joe]

The TACLS resource duplication bug appears to be fixed in this version.

However, in the course of my testing I identified a different, equally problematic bug. ShipManifest does not seem to recognize the change in status of "deployable" living space modules, such as PorkJet's inflatable habs. In CLS terms, these habs begin as "passable" but without room for Kerbals to stay. Once inflated, the habs have space for Kerbals. CLS correctly identifies this change, with the habs immediately changing from yellow (passable) to green (habitable) when inflated. Unfortunately, though, the newly inflated hab is not added to ShipManifest's list of crew transfer locations.

Good catch. I do not refresh the part list as often as i previously did, in an effort to conserve memory and processing time. However, that means that changes to the characteristics of the part may not be recognized.

Do you know if this behavior is exhibited in 3.1.5? If not, then I need to rethink portions of my scope for parts...

Another thing to try. If you change scenes (or move a kerbal) after the inflation, does it now show up in the list?

In any case, I'm going to have to spend a bit more time with CLS, as there are some things I want to try...

Edited April 26, 2014 by Papa_Joe

[Fraz86]

Do you know if this behavior is exhibited in 3.1.5? If not, then I need to rethink portions of my scope for parts...

I'll test it when I get home. Also, I'm curious, what do you mean by scope for parts?

My programming knowledge is limited, but given that CLS is already adding the module to a living space in real time, shouldn't there be some way for ShipManifest to simply refer to or "mirror" the CLS list of connected habitable modules with minimal burden on memory? In other words, the necessary monitoring of dynamic parts is obviously already taking place within CLS, and I would imagine there must be a way for ShipManifest to utilize this efficiently, without a need for redundant memory-intensive updating, right?

[Papa_Joe]

I'll test it when I get home. Also, I'm curious, what do you mean by scope for parts?

My programming knowledge is limited, but given that CLS is already adding the module to a living space in real time, shouldn't there be some way for ShipManifest to simply refer to or "mirror" the CLS list of connected habitable modules with minimal burden on memory? In other words, the necessary monitoring of dynamic parts is obviously already taking place within CLS, and I would imagine there must be a way for ShipManifest to utilize this efficiently, without a need for redundant memory-intensive updating, right?

You can instantiate an object at the scene level and "do things" at the frame level. (amongst many other hooks into the engine) This is the scope I describe.

When I started with Crew manifest, the code to generate the part lists used was instantiated at the frame level, refreshing every frame. Makes things convenient, but chews up memory as you are creating and throwing away objects at ~60 frames a sec.

So, to reduce the garbage collection, and any potential memory creep, I moved them to instantiate at the Scene level, taking care to update them only when needed, not every frame.

I would indeed need to do what you describe. I'm currently grabbing the list at the creation of the scene and checking part.CrewCapacity. I update when events occur.

I will have to consider the method that CLS is using, or use CLS as my source for creating the Part List. I may also not be capturing the Vessel.OnVesselChange Event correctly...

Edited April 26, 2014 by Papa_Joe

[Gristle]

-1 for the dependency, or for the integration?

if for the integration, you can set a switch and turn it off.

If for the dependency, I understand, and am considering some reflection code (thanks codepoet), to make CLS "optional".

Finally, the previous version 0.23.3.1.5, does not have this dependency and can be found on my Github repository http://github.com/PapaJoesSoup/ShipManifest, along with other previous releases.

Thanks for the feed back!

-1 for the dependency. Integration with related systems is good, but requiring your users to install something else that they may not want is bad. When I use Ship Manifest to move crew around I assume that either the vessel was constructed with a way for crew to move between the crew spaces (crawl tube, etc.) or that Ship Manifest handled the crew's EVA between spaces so that I didn't have to.

[Fraz86]

-1 for the dependency. Integration with related systems is good, but requiring your users to install something else that they may not want is bad. When I use Ship Manifest to move crew around I assume that either the vessel was constructed with a way for crew to move between the crew spaces (crawl tube, etc.) or that Ship Manifest handled the crew's EVA between spaces so that I didn't have to.

If you turn off CLS integration in the config, ShipManifest will work exactly as you describe. CLS itself doesn't actually do anything, so if remove its icon from your toolbar, it's basically as if CLD isn't even installed. Technically it continues running in the background, but has no effect on gameplay other than consuming some small amount of memory.