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

[jofwu]

Wanted to report another small bug I've run into.

I'm playing with MKS Lite, and I assume this would be the case for other USI mods... There are a number of inflatable parts which initially can't hold any crew, but after you've deployed them they can. And Ship Manifest doesn't catch on to the change.

If I right click and manually transfer a Kerbal to one of the newly inflated parts then Ship Manifest refreshes and sees the new parts. But before this it doesn't.

[Deimos Rast]

8 hours ago, Papa_Joe said:

Nope that is definitely a bug.   Happens when you open the roster?   always or just in one scene or the other?  Ok I see it in the logs.... that would be every time you open it.

 

Edit:   my copy is running fine.   Win 10 x64, What version of Deepfreeze are you using?  there was a period of incompatability as I understand, based on reading the thread.    I'd been absent for a bit and missed it

 

Version I'm running is:  0.20.3

Yeah, I'm running 0.20.3, I suppose I could reinstall it and try that again. I'll try a clean install of Ship Manifest again too. And I suppose I'll do it on a clean install of KSP while I'm at it.

The thing is, you said in the change log to 5.0 that you were using a Deep Freeze dependency or something, which you moved away from ("Removed need for DFInterface.dll.  Now using new reflection class method for soft dependency to DeepFreeze") Or maybe not, not sure how to interpret that statement, now that I look at it. I already have a copy of DFInterface.dll from JLRepo (I run a number of his mods) - could the two be conflicting? Switching to 5.0 made the problem worse, as the roster closed out completely. In the previous version, it was garbled, but still somewhat usable (and I've switched back to it for the time being).

I looked at the two DFInterface.dll's side by side, and while I don't know how to read them, the bytes both read 10,240 and date modified is Tue 10 Nov 2015 02:40:38 AM CST for both so I'm assuming they're the same.

That is the only thing I can think of. I'll bite the bullet and upgrade to 5.0 again so we don't have to deal with a potentially outdated issues that might no longer be relevant in 5.0.

Any known mod incompatibilities? I have a lot of mods as I mentioned and I'm a bit reluctant to just stab blindly in the dark to try to troubleshoot this.

Anyway, thanks for the response, much appreciated.

[Deimos Rast]

20 minutes ago, jofwu said:

Wanted to report another small bug I've run into.

I'm playing with MKS Lite, and I assume this would be the case for other USI mods... There are a number of inflatable parts which initially can't hold any crew, but after you've deployed them they can. And Ship Manifest doesn't catch on to the change.

If I right click and manually transfer a Kerbal to one of the newly inflated parts then Ship Manifest refreshes and sees the new parts. But before this it doesn't.

Some inflatable habitats are defined in the configs as having 0 crew capacity, but have a module that has an effect that then adds crew capacity to the part upon inflation. How is this any different than what you said? It's not really, except that Ship Manifest probably doesn't read into the the individual modules, only sees their effects. Just a hunch. None of this helps you any, but might help @Papa_Joe understand the problem.

Example from Porkjet's Habitat  Pack:

MODULE
{
	name = deployableHabRestrictor
	animationName = deploy
	crewCapacityDeployed = 4
	crewCapacityRetracted = 0
}

 

[jofwu]

37 minutes ago, Deimos Rast said:

How is this any different than what you said?

That's exactly what's going on. In my case it's a module called USIAnimation that adds crew spots. I don't know if it can be fixed or not, but I just thought I'd mention the problem. Thankfully it's not a major issue since there's a way around it.

[JPLRepo]

3 hours ago, Deimos Rast said:

Yeah, I'm running 0.20.3, I suppose I could reinstall it and try that again. I'll try a clean install of Ship Manifest again too. And I suppose I'll do it on a clean install of KSP while I'm at it.

The thing is, you said in the change log to 5.0 that you were using a Deep Freeze dependency or something, which you moved away from ("Removed need for DFInterface.dll.  Now using new reflection class method for soft dependency to DeepFreeze") Or maybe not, not sure how to interpret that statement, now that I look at it. I already have a copy of DFInterface.dll from JLRepo (I run a number of his mods) - could the two be conflicting? Switching to 5.0 made the problem worse, as the roster closed out completely. In the previous version, it was garbled, but still somewhat usable (and I've switched back to it for the time being).

I looked at the two DFInterface.dll's side by side, and while I don't know how to read them, the bytes both read 10,240 and date modified is Tue 10 Nov 2015 02:40:38 AM CST for both so I'm assuming they're the same.

That is the only thing I can think of. I'll bite the bullet and upgrade to 5.0 again so we don't have to deal with a potentially outdated issues that might no longer be relevant in 5.0.

Any known mod incompatibilities? I have a lot of mods as I mentioned and I'm a bit reluctant to just stab blindly in the dark to try to troubleshoot this.

Anyway, thanks for the response, much appreciated.

Ship Manifest no longer uses DFInterface.dll to interface to DeepFreeze. In fact nothing does. you can delete DFInterface.dll if you want.
@Papa_Joe is investigating... and I took a look at the log provided earlier and could see no errors related to SM or Deepfreeze i that particular log file has had been reported.
Are you sure that this error is occurring NOW with the latest SM and DeepFreeze installed? Because as Papa_Joe had said earlier, this did occur for a brief period but thought we had fixed it.
In fact the last update he did I thoroughly tested the DeepFreeze integration and it was working fine. I ask also because like I said the log you supplied did not contain this error.

 

2 hours ago, jofwu said:

That's exactly what's going on. In my case it's a module called USIAnimation that adds crew spots. I don't know if it can be fixed or not, but I just thought I'd mention the problem. Thankfully it's not a major issue since there's a way around it.

Yep I would say Ship Manifest is not checking for parts that change their crew capacity (given I've spent some time looking at the code) and only and only sees what their CURRENT capacity is at any given time.
 

Edited March 9, 2016 by JPLRepo

[Papa_Joe]

On 3/9/2016 at 1:37 AM, JPLRepo said:

Ship Manifest no longer uses DFInterface.dll to interface to DeepFreeze. In fact nothing does. you can delete DFInterface.dll if you want.
@Papa_Joe is investigating... and I took a look at the log provided earlier and could see no errors related to SM or Deepfreeze i that particular log file has had been reported.
Are you sure that this error is occurring NOW with the latest SM and DeepFreeze installed? Because as Papa_Joe had said earlier, this did occur for a brief period but thought we had fixed it.
In fact the last update he did I thoroughly tested the DeepFreeze integration and it was working fine. I ask also because like I said the log you supplied did not contain this error.

 

Yep I would say Ship Manifest is not checking for parts that change their crew capacity (given I've spent some time looking at the code) and only and only sees what their CURRENT capacity is at any given time.
 

Indeed, SM no longer uses the DFInterface.dll.  The new dependency code was thoroughly tested by JPLRepo.  Additionally, I removed the DFInterface.dll file from the distribution.   If you have it in your SM install, then you did not install SM "clean" as the install instructions say.   Problems "could" occur.

I do check for the Crew Capacity, but do not check for the other values shown in the part.   I can add those specifically for the habitat packs.   I had created compatibility with those a long time ago, but likely the design has changed. 

 

[hab136]

I'm hitting a null ref bug when I EVA or try to climb back in.  This duplicates Kerbals and clears their KIS inventory, which is, uh, bad.

[LOG 16:17:57.298] -INFO- Tac.LifeSupportController[FFA84B74][1246.00]: OnCrewBoardVessel: from=Tomford Kerman(Tomford Kerman), to=PPD-12 Cupola 
Module(East crater base)
[LOG 16:17:57.298] OnCrewBoardVessel 9f737697-6432-422a-b0b0-e7eec2df5ba2 1200365017
[LOG 16:17:57.298] [00:00:11]: Tomford Kerman boarded PPD-12 Cupola Module on East crater base.
[WRN 16:17:57.378] protoCrew seatIdx has been set to -1 ! (no internal ?)
[LOG 16:17:57.378] Setting seat to: 0
[LOG 16:17:57.378] Item transfer | source Tomford Kerman
[EXC 16:17:57.382] NullReferenceException: Object reference not set to an instance of an object
        DF.DeepFreezer.OnCrewTransferred (HostedFromToAction`2 fromToAction)
        EventData`1[GameEvents+HostedFromToAction`2[ProtoCrewMember,Part]].Fire (HostedFromToAction`2 data)
        KerbalEVA.proceedAndBoard (.Part p)
        KerbalEVA.BoardPart (.Part p)
        KerbalEVA.<SetupFSM>m__93 ()
        KerbalFSM.RunEvent (.KFSMEvent evt)
        KerbalFSM.updateFSM (KFSMUpdateMode mode)
        KerbalFSM.UpdateFSM ()
        KerbalEVA.Update ()
[LOG 16:17:57.416] [KerbalMass] Part mass is now 1.76
[LOG 16:17:57.441] Item transfer | destination: cupola (0)

Full Logs: https://www.dropbox.com/sh/b728ehk2vu4ap1p/AAB35ZhaQmVJoD3fq22pUXbba?dl=0

Playing Linux 64-bit with 16 GB RAM.

In debugging I removed TAC life support, EvaFuel, KerbalMass, and ShipManifest trying to find it (since they all trigger on crew transfer), then put them back one by one.  I actually forgot to put Ship Manifest back in, and then wondered why I couldn't reproduce the bug any more.  I said "oh well" and continued playing for a few minutes, then went to transfer some science and realized I forgot it.   Put Ship Manifest back in, and the EVA bug is back.

Everything works fine if Ship Manifest is not installed.

DeepFreeze is 0.20.3, Ship Manifest is 5.0.0.1.

  "VERSION": {
    "MAJOR": 5, 
    "MINOR": 0,
    "PATCH": 0,
      "BUILD": 1
  },
"VERSION":{"MAJOR":0,"MINOR":20,"PATCH":3,"BUILD":0},

 

Edited March 12, 2016 by hab136

[Papa_Joe]

JPLRepo and I are investigating.   I believe we have found the culprit.   It appears I renamed a class namespace without updating the Interface.  Working out a solution now.

[Papa_Joe]

We have a fix

11 hours ago, Papa_Joe said:

JPLRepo and I are investigating.   I believe we have found the culprit.   It appears I renamed a class namespace without updating the Interface.  Working out a solution now.

We have a fix.  I'm packaging it now.  One of the changes is the removal of the SMInterface.dll file.   DeepFreeze will soon be released with a new wrapper class to access features of SM.  This corrects the error, as we have removed the need to keep track of the namespace, 

I'm also looking over other bugs recently posted to be sure I've addressed those as well.

[Papa_Joe]

On 1/4/2016 at 0:13 AM, hash said:

For me tourist contracts don't work with ship manifest: 

Tried with "orbital" or "suborbital" tourists, and the condition never triggered. Saved mid-flight, uninstalled ship manifest, and the contract completed immediately. Also: Final Frontier seems like it doesn't create more ribbons while ship manifest is installed. Both behave pretty much like the crew just isn't there.

Mods that may be related: - Kerbal Construction Time, this has its own dialog to put Kerbals on board at launch. But I doubt it since reloading the game doesn't change it, the persistent file doesn't look any different.

In SM, I had not programmed the the Tourist profession.  I've since added it it.  Let me know if this resolves your issue or if you are still experiencing it.   After the major refactor of ver 5, I'm not sure what bugs will still be there or what new bugs I may have introduced with version 5.

As I'm getting closer to release of 5.0.1.0,  I'm going thru the forum thread to make sure I've not missed anything.  If I have not addressed your concerns please speak up again.  Thanks!

[Papa_Joe]

On 3/6/2016 at 7:37 PM, Papa_Joe said:

Yes, this issue did occur in the past, and I attempted to correct the issue.   It would appear it is not fixed.   I will examine the code to see what may be needed.  I had added an event to allow for crew transfer detection, but it seems that may not be working.

I'm looking at this now, and I'd like to ask:

Do the kerbal inventories move when a kerbal is transferred and not swapped?   Meaning.  only when they swap is the issue coming up, or are no inventories moving?

thanks!

[Papa_Joe]

On 2/28/2016 at 11:15 AM, jofwu said:

I think I found a bug concerning KIS compatibility. I had a few Kerbals swap seats (in the same pod) and it seems like their inventories didn't come along. At first it seemed like I lost everything, and wasn't sure why. Then a little while later I realized one of them had everything that had originally belonged to another. And I'm pretty sure they were two that I had swapped seats with one another. There was a third Kerbal who lost everything as well, and I don't think her stuff every turned up. I think I had her swap seats with an empty seat, and then with nobody in the seat she left the inventory disappeared. Both cases seemed to suggest that the inventories weren't coming along with the seat swaps.

I searched the topic first and it seemed like there were some KIS compatibility issues in the past... but it seems to have been a matter of transferring Kerbals between different parts of the ship. I figure the seat swapping may have been a separate issue that didn't get fixed with that update.

This is the original post That I"m referring to above.... 

 

Edited March 14, 2016 by Papa_Joe

[jofwu]

4 hours ago, Papa_Joe said:

This is the original post That I"m referring to above.... 

 

I'll try to do some tests if I get a chance... but it was ONLY when swapping seats. I moved Kerbals from one ship to another no problem. When I moved one to an empty seat in the same pod the inventory did not come along.

[Papa_Joe]

Just now, jofwu said:

I'll try to do some tests if I get a chance... but it was ONLY when swapping seats. I moved Kerbals from one ship to another no problem. When I moved one to an empty seat in the same pod the inventory did not come along.

thanks.  that helps

 

[Papa_Joe]

New release coming within the hour.

Due to the nature of the update, JPLRepo and I are coordinating releases to ensure maximum compatibility during this update.

DeepFreeze has been updated as well.  We have completely revised the way we communicate with eachother.   hopefully this will improve things going forward.  For those that care, we are now using similar reflection classes as in ToolBar and many other mods.

Change Log for impending Release:

Version 5.0.1.0 - Release 14 Mar, 2016 - Bug fixes and APIs
- New:  Removed DFInterface.dll.  Added Reflection based Wrapper class source code for integration with DeepFreeze.
- New:  Removed SMInterface.dll.   Replaced by SMWrapper, which is also a reflection based wrapper for developer use with SM.
- Fixed:  Crew movement issues with DeepFreeze.
- Fixed:  Roster Window does not display correctly with DeepFreeze installed.
- Note:  The latest version of DeepFreeze (DF) is required if you use it with SM. 
- Note:  EVA kerbals causing a null ref bug and duplicating kerbals.  This fix also requires the latest version of Deepfreeze (V0.20.4.0)    

[Papa_Joe]

Released

Version 5.0.1.0 - Release 14 Mar, 2016 - Bug fixes and APIs
- New:  Removed DFInterface.dll.  Added Reflection based Wrapper class source code for integration with DeepFreeze.
- New:  Removed SMInterface.dll.   Replaced by SMWrapper, which is also a reflection based wrapper for developer use with SM.
- Fixed:  Crew movement issues with DeepFreeze.
- Fixed:  Roster Window does not display correctly with DeepFreeze installed.
- Fixed:  EVA kerbals causing a null ref bug and duplicating kerbals.  This fix requires the latest version of Deepfreeze (V0.20.4.0) if you use it with SM. 
 

DeepFreeze will be released within the hour.

 

[Papa_Joe]

With the release of 5.0.1.0, I'd like get a better handle on what remains to be resolved.  

If you have been experiencing a bug, and you have posted it to this thread, but it has not yet been fixed, please create an issue in Github (link is in my OP).  This will ensure it does not get lost in the ongoing conversation and ensures that I will address it.

I will be going thru the thread and extracting the issues I see.   Please check to see If I or someone else has created an issue before opening a new one.

Thanks!

 

Update:   I've added several issues to the Github repository.  I hope I've captured all of them.   Please let me know if I've missed anything.  

Link:  https://github.com/PapaJoesSoup/ShipManifest/issues

thanks!

Edited March 15, 2016 by Papa_Joe
added update for new issues added to git

[Torgo]

I just installed the newest update, and the sound issues I had reported earlier are now gone.

Thanks!

[Nansuchao]

The new version works flawlessy, congratulations!

[Deimos Rast]

It would seem you've been busy while I was away (sorry about disappearing like that). I downloaded and installed the latest DeepFreeze and ShipManifest and it seems to have worked - I can now seem the roster for the first time in a long time! Reading through the change logs for both ShipManifest and DeepFreeze it seems like a lot of work went into this. Thank you!

On a completely hypothetical level, and completely divorced from reality in any way I assure you: your wrapper class (which I think is something you created to allow other mods to easily talk to yours?) follows a naming convention of "MyPlugin_ShipManifestWrapper" yes? So if I just happened to be reading through the logs and saw a reference to a "DeepFreeze-SMWrapper" that would be the DeepFreeze version of your wrapper class, correct? So if, to continue the example, "DeepFreeze-SMWrapper" were misbehaving in some way, who would be the person I would talk to? If it seems like I'm being annoyingly oblique about this (which I am), I just want to make sure I have the right interpretation and the right person, before potentially spoiling the (well deserved) celebratory mood.

Cheers.

[captainradish]

I apologize if this has been asked before, but is there any way we can get a version that acts similarly to how TAC fuel balancer works? Meaning, I am wanting something that can automatically transfer from tank to tank without me having to manually pump stuff. Is this possible now and I'm just not seeing it?

 

Edit: I want to make it clear Ship Manifest is excellent and something I use all the time.

Edited March 15, 2016 by captainradish

[JPLRepo]

14 minutes ago, Deimos Rast said:

It would seem you've been busy while I was away (sorry about disappearing like that). I downloaded and installed the latest DeepFreeze and ShipManifest and it seems to have worked - I can now seem the roster for the first time in a long time! Reading through the change logs for both ShipManifest and DeepFreeze it seems like a lot of work went into this. Thank you!

On a completely hypothetical level, and completely divorced from reality in any way I assure you: your wrapper class (which I think is something you created to allow other mods to easily talk to yours?) follows a naming convention of "MyPlugin_ShipManifestWrapper" yes? So if I just happened to be reading through the logs and saw a reference to a "DeepFreeze-SMWrapper" that would be the DeepFreeze version of your wrapper class, correct? So if, to continue the example, "DeepFreeze-SMWrapper" were misbehaving in some way, who would be the person I would talk to? If it seems like I'm being annoyingly oblique about this (which I am), I just want to make sure I have the right interpretation and the right person, before potentially spoiling the (well deserved) celebratory mood.

Cheers.

Yes so messages like "DeepFreeze-SMWrapper" is DeepFreeze managing it's interface into SM.
You'll see other messages like "ShipManifest-DFWrapper" - which would be Ship Manifest managing it's interface into DF.
Doesn't really matter where you raise any issue around DeepFreeze - Ship Manifest. Here or DeepFreeze. Papa_Joe or myself will investigate and if we find it's something to do with the other mod we will let you and each other know (we are in contact pretty regularly anyway).

Edited March 15, 2016 by JPLRepo

[Deimos Rast]

8 minutes ago, JPLRepo said:

Yes so messages like "DeepFreeze-SMWrapper" is DeepFreeze managing it's interface into SM.
You'll see other messages like "ShipManifest-DFWrapper" - which would be Ship Manifest managing it's interface into DF.
Doesn't really matter where you raise any issue around DeepFreeze - Ship Manifest. Here or DeepFreeze. Papa_Joe or myself will investigate and if we find it's something to do with the other mod we will let you and each other know (we are in contact pretty regularly anyway).

And he arrives before I even get a chance to offer congratulations. Well, congrats! Seriously, nice work.

From reading your changelog with Deep Freeze, I understand some things are still in a bit of an interim with regards to Ship Manifest (or maybe that was CLS). Specifically, well, I know how much ya'll love selected slices of logs, so here is precisely that:
 

Spoiler

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Getting TransferCrew Instance
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Unable to Instantiate SMAPI object using Reflection
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
  at ShipManifest.SMAddon.get_CrewTransferProcess () [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at DF.SMWrapper+SMAPI.get_getCrewTransferProcess () [0x00000] in <filename unknown>:0 
  at DF.SMWrapper+SMAPI..ctor (System.Object a) [0x00000] in <filename unknown>:0 
 

 

My only in game time consisted of flying a small pod for a couple minutes; didn't try to crew transfer or eva. The only thing relevant about the parts involved is that they...maybe haven't been updated since 0.24. I hadn't intended on actually submitting this until I tried it without said parts and could replicate it, but since JLRepo once again showed up in a flash lightning, I feel like I kind of have to now that the entire crew has been assembled. *sigh*

I can and will provide my log (about to eat dinner). And as always, I'm trying (such as it is) to provide you guys with support, not the other way around. If you fix an issue I'm having great, but I have zero expectations. Mod authors, and you two in particular, provide a tremendous amount of value, and I believe in doing what I can to support that - which is why I am always in certain people's threads providing feedback, bug reports and suggestions.

Now, with that out of the way, is there anything you'd like me to do, besides not installing dodgy mods (it was a one time thing, honest!) and uploading a log?

[JPLRepo]

6 minutes ago, Deimos Rast said:

6 minutes ago, Deimos Rast said:

And he arrives before I even get a chance to offer congratulations. Well, congrats! Seriously, nice work.

From reading your changelog with Deep Freeze, I understand some things are still in a bit of an interim with regards to Ship Manifest (or maybe that was CLS). Specifically, well, I know how much ya'll love selected slices of logs, so here is precisely that:
 

  Reveal hidden contents

 

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Getting TransferCrew Instance
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Unable to Instantiate SMAPI object using Reflection
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
  at ShipManifest.SMAddon.get_CrewTransferProcess () [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at DF.SMWrapper+SMAPI.get_getCrewTransferProcess () [0x00000] in <filename unknown>:0 
  at DF.SMWrapper+SMAPI..ctor (System.Object a) [0x00000] in <filename unknown>:0 
 

 

 

 

My only in game time consisted of flying a small pod for a couple minutes; didn't try to crew transfer or eva. The only thing relevant about the parts involved is that they...maybe haven't been updated since 0.24. I hadn't intended on actually submitting this until I tried it without said parts and could replicate it, but since JLRepo once again showed up in a flash lightning, I feel like I kind of have to now that the entire crew has been assembled. *sigh*

I can and will provide my log (about to eat dinner). And as always, I'm trying (such as it is) to provide you guys with support, not the other way around. If you fix an issue I'm having great, but I have zero expectations. Mod authors, and you two in particular, provide a tremendous amount of value, and I believe in doing what I can to support that - which is why I am always in certain people's threads providing feedback, bug reports and suggestions.

Now, with that out of the way, is there anything you'd like me to do, besides not installing dodgy mods (it was a one time thing, honest!) and uploading a log?

And he arrives before I even get a chance to offer congratulations. Well, congrats! Seriously, nice work.

From reading your changelog with Deep Freeze, I understand some things are still in a bit of an interim with regards to Ship Manifest (or maybe that was CLS). Specifically, well, I know how much ya'll love selected slices of logs, so here is precisely that:
 

  Hide contents

 

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Getting TransferCrew Instance
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Unable to Instantiate SMAPI object using Reflection
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

3/15/2016 4:03:52 PM,DeepFreeze-SMWrapper,Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
  at ShipManifest.SMAddon.get_CrewTransferProcess () [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at DF.SMWrapper+SMAPI.get_getCrewTransferProcess () [0x00000] in <filename unknown>:0 
  at DF.SMWrapper+SMAPI..ctor (System.Object a) [0x00000] in <filename unknown>:0 
 

 

 

 

My only in game time consisted of flying a small pod for a couple minutes; didn't try to crew transfer or eva. The only thing relevant about the parts involved is that they...maybe haven't been updated since 0.24. I hadn't intended on actually submitting this until I tried it without said parts and could replicate it, but since JLRepo once again showed up in a flash lightning, I feel like I kind of have to now that the entire crew has been assembled. *sigh*

I can and will provide my log (about to eat dinner). And as always, I'm trying (such as it is) to provide you guys with support, not the other way around. If you fix an issue I'm having great, but I have zero expectations. Mod authors, and you two in particular, provide a tremendous amount of value, and I believe in doing what I can to support that - which is why I am always in certain people's threads providing feedback, bug reports and suggestions.

Now, with that out of the way, is there anything you'd like me to do, besides not installing dodgy mods (it was a one time thing, honest!) and uploading a log?

Did this occur only once in the log? on initial scene start (like flight mode)? To confirm my suspicions. I think it's a timing issue on scene startup.. Or maybe not. If Not, yes full log please.

[Deimos Rast]

Actually it occurs twice, and toward the end of the log, both times. It's not the cleanest log (baseline is 6 nullrefs, this is at 14) and there is some spam about "Look rotation viewing vector is zero" and Kopernicus being dumb (which I think eventually leads to the final "not enough memory"). None of that is relevant to you, just painting a picture of the environment.

By the way, should we move this to the DeepFreeze thread or?

Link

Reloading game without aforementioned outdated mod to see if I can reproduce the issue.

1 hour ago, captainradish said:

I apologize if this has been asked before, but is there any way we can get a version that acts similarly to how TAC fuel balancer works? Meaning, I am wanting something that can automatically transfer from tank to tank without me having to manually pump stuff. Is this possible now and I'm just not seeing it?

 

Edit: I want to make it clear Ship Manifest is excellent and something I use all the time.

Might I suggest GPOSpeedFuelPump? I run it myself. It works in 1.0.5 if you run the recompiled version mentioned in the later comments and make some of the changes I mention in the thread.