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

[JPLRepo]

8 minutes ago, Papa_Joe said:

From a realism point of view, that would be exactly right.  You can't just short the batteries to ground, you would burn them up and your vessel too.   Discharging across a resistor grid will generate heat, so you have to discharge at some rate to prevent overheating.  So, electric charge follows the same "rules" as other resources, and is dumped at a flow rate.

Turn off realism and Electric Charge is instantly dumped.

Good point... so is SM going to generate Heat whilst dumping EC?

[Papa_Joe]

33 minutes ago, JPLRepo said:

Good point... so is SM going to generate Heat whilst dumping EC?

Also a good point.  I suppose it would need to.   now to figure out how to make that happen....

 

That also resurrects the issue of resource dumps.   there should be an ejection point, and it should have some sort of animation, and it imparts a thrust component....

Edited July 5, 2016 by Papa_Joe

[JPLRepo]

13 minutes ago, Papa_Joe said:

Also a good point.  I suppose it would need to.   now to figure out how to make that happen....

 

That also resurrects the issue of resource dumps.   there should be an ejection point, and it should have some sort of animation, and it imparts a thrust component....

Oh dear... we've opened a can of worms...
For heat generation take a look at Part.AddThermalFlux

[blu3wolf]

Additionally, you might want to consider the effects of venting fuel from a station - jetsam is going to build up around the station.

Easy to disregard that though, same as the thrust component of unbalanced resource dumps, and the animation for it, or the heat build up from dumping EC. 

[Papa_Joe]

7 minutes ago, blu3wolf said:

Additionally, you might want to consider the effects of venting fuel from a station - jetsam is going to build up around the station.

Easy to disregard that though, same as the thrust component of unbalanced resource dumps, and the animation for it, or the heat build up from dumping EC. 

When I first considered dumps in realism mode, I "assumed" that any venting would be a zero sum thrust component.  you would vent from opposite sides and the net would be zero.  so I "fudged it" if you will.  There are discussion in this thread concerning that if you care to research back about 6 months or so I think.

But, for the sake of "purity", I probably should create a part to allow "real" dumping. and allow for heat generation as well, so that there is a reason for heat dissipation.

 

Edited July 5, 2016 by Papa_Joe

[blu3wolf]

Im still confused over the use case, in honesty. I spend most of my time working out how to most efficiently increase the amount of fuel stored on orbit, not carting the stuff up there then dumping it overboard...

[Papa_Joe]

2 minutes ago, blu3wolf said:

Im still confused over the use case, in honesty. I spend most of my time working out how to most efficiently increase the amount of fuel stored on orbit, not carting the stuff up there then dumping it overboard...

I certainly can understand, but remember that this mod is used by both casual and hard core gamers.   So the use case may not be apparent to you, but is "required" by someone else

[DStaal]

I've had a couple of low-TWR Mun landers where the ability to thrust to a more eccentric orbit at a low ISP would have been helpful...  (Flight to Mun was more efficient than expected - I needed to dump fuel to get sufficient TWR to successfully land.)

[blu3wolf]

1 hour ago, Papa_Joe said:

I certainly can understand, but remember that this mod is used by both casual and hard core gamers.   So the use case may not be apparent to you, but is "required" by someone else

Im not disputing that, but I am interested in what that use case might be, nonetheless.

[Tokamak]

46 minutes ago, blu3wolf said:

Im not disputing that, but I am interested in what that use case might be, nonetheless.

I actually often use it to dump remaining fuel during re-entry, either to lighten the load or to balance. Especially when I am aerobraking and I have a pile of spare monoprop.

[b0ss]

What advantages does dumping electrical charge have?

8 hours ago, blu3wolf said:

Applying a potential difference across a conveniently located resistor grid.

So basically redirecting the electrons to a diode where they are forced to turn into dissipating heat energy?

Edited July 5, 2016 by b0ss

[blu3wolf]

Well, no. The electrons are not consumed in the process, and are not turned into heat. You probably could achieve it with diodes, but anything with resistance will achieve the goal. Technically, the process is to apply your PD across or through a material with a high resistance, which will soak whatever the stored charge is (some form of energy, likely chemical potential from bonds being formed). The electrons flowing in the material as a result of that PD transfer some kinetic energy to the molecules of the resistive material as they move through it, which is an excessively verbose way of saying that it makes it heat up. Sorta what you said, aside from the electrons not turning into anything other than electrons with a slightly lower energy.

If you like, another way of looking at it is that a resistor grid is a way of turning stored electrical energy into heat. I dont see a reason to use that capability on a spacecraft, but that doesnt mean no reason exists.

Edited July 5, 2016 by blu3wolf

[eberkain]

On 7/4/2016 at 10:51 PM, Papa_Joe said:

When I first considered dumps in realism mode, I "assumed" that any venting would be a zero sum thrust component.  you would vent from opposite sides and the net would be zero.  so I "fudged it" if you will.  There are discussion in this thread concerning that if you care to research back about 6 months or so I think.

But, for the sake of "purity", I probably should create a part to allow "real" dumping. and allow for heat generation as well, so that there is a reason for heat dissipation.

 

I like that idea, a new setting that only lets you dump if you have ejection ports installed, and if you put them on symmetrically it should be a zero sum thrust.  And a new VFX showing your fuel or whatever getting shot out into space.  Could probably rip off the part from the stock single port thruster and just make some tweaks to how it works. 

[blu3wolf]

Which is basically another way of saying there should be an engine that runs on anything...

[Papa_Joe]

5 hours ago, blu3wolf said:

Which is basically another way of saying there should be an engine that runs on anything...

I disagree.  an "engine" implies some sort of combustion or reaction imparting a greater thrust component than the flow rate of the material itself.  I would liken this to more of a vent.  there would be thrust based on the mass of the resource, the size of the vent orifice, and the flow rate out of the vessel, but no reaction, and it would be fixed and not vary.  Think of like "urine" dumps or leaking o2 tanks on apollo...

[Phineas Freak]

@blu3wolfventing a stage after CCAM != propulsive maneuver with an engine. Propellant vents usually are non - propulsive (saying "usually" since the Soyuz Block I uses a LOX vent valve to induce a tumble to the stage after cutoff) and their thrust and ISP are minuscule..

[Papa_Joe]

Just an update.  I will be release a new version of SM and CLS later today.   testing is complete, so packaging an upload is all that remains.   I will post more after my workday (Day job) is complete.

[Papa_Joe]

Release:

Version 5.1.1.0 - Release 07 Jul, 2016 - KSP 1.1.3 Compatibility Edition.
- Fixed:  NulRef errror with DeepFreeze installed and a frozen kerbal in RosterListViewer.
- Fixed:  (maybe) Window display issues during launch and stage separation, explosion of ship.
- New:  SM window can now be displayed in IVA and in Map mode.
- New:  Added logging to output.log.  this will make the output.log more useful for troubleshooting.  Captures all log entries, verbose or not.
- New:  Refactored Highlighting to clean up FPS issue. Now causes significantly less impact to frame rate.
- New:  Refactored Stock Crew Transfer Beahavior.  When override is on, changes to KSP 1.1.3 now allow capturing transfer before it occurs.
- New:  Added a switch to disable Stock Crew Transfers in general.  Found in SM Settings WIndow, under Realism.

Enjoy.

 

Also a little tidbit.  I found a part property crewTransferAvailable.  if this is set to false, you can disable the transfer buttons on the part action dialog.   However, it does not work in all cases.  For example, the lander can still shows the transfer button.  I will be investigating this further, but I've included a check for this value when setting Enable Stock Crew Transfers off in the Settings window, under Realism.

Edited July 7, 2016 by Papa_Joe

[rasta013]

5 hours ago, Papa_Joe said:

- Fixed:  (maybe) Window display issues during launch and stage separation, explosion of ship.

Hate to be the bearer of bad news but the window is still disappearing after a stage explodes after separation.  This is the only place I've had it happen though with the latest version.  Standard stage separation has not caused the window to disappear on me yet and the exploding stage scenario has only happened one time and that when I was still in physics range of the exploding stage.  Still, even with this, the disappearing window situation so far seems drastically improved.

[Deimos Rast]

Thanks for the update!

Does this fix the SM colored overlay persisting after crew transfers and the like? The easy work around is to just go to the map and back to the ship and things are cleared up (that's why I never mentioned it prior).

[Papa_Joe]

Just did some research and testing.   I can now disable the Stock Crew Transfer completely.  The crew transfer button will not appear in the part action dialog at all if Enable Stock Crew Transfers is set to off.

I will be releasing a point update tomorrow with this new feature fully implemented.  The release Today, only partially implemented it..

1 hour ago, rasta013 said:

Hate to be the bearer of bad news but the window is still disappearing after a stage explodes after separation.  This is the only place I've had it happen though with the latest version.  Standard stage separation has not caused the window to disappear on me yet and the exploding stage scenario has only happened one time and that when I was still in physics range of the exploding stage.  Still, even with this, the disappearing window situation so far seems drastically improved.

Thanks for the update!

22 minutes ago, Deimos Rast said:

Thanks for the update!

Does this fix the SM colored overlay persisting after crew transfers and the like? The easy work around is to just go to the map and back to the ship and things are cleared up (that's why I never mentioned it prior).

yes

Edited July 8, 2016 by Papa_Joe

[blu3wolf]

17 hours ago, Papa_Joe said:

I disagree.  an "engine" implies some sort of combustion or reaction imparting a greater thrust component than the flow rate of the material itself.  I would liken this to more of a vent.  there would be thrust based on the mass of the resource, the size of the vent orifice, and the flow rate out of the vessel, but no reaction, and it would be fixed and not vary.  Think of like "urine" dumps or leaking o2 tanks on apollo...

I would have to disagree. There is never a thrust component greater than the mass flow rate of the propellant. In the case of a chemical rocket, you have greater than the mass flow rate of the fuel, but not the exhaust. Chemical rockets are not the only option though. Nuclear rockets have no combustion or reaction occurring in the propellant, but still impart a thrust.

Picking terminology to suit the point aside, that doesnt actually change the point I was making at all. Even slightly.

17 hours ago, Phineas Freak said:

@blu3wolfventing a stage after CCAM != propulsive maneuver with an engine. Propellant vents usually are non - propulsive (saying "usually" since the Soyuz Block I uses a LOX vent valve to induce a tumble to the stage after cutoff) and their thrust and ISP are minuscule..

This I am not disputing.

[Papa_Joe]

Release:

Version 5.1.1.1 - Release 08 Jul, 2016 - KSP 1.1.3 Compatibility Edition.
- New:  Implemented Disabling of Stock Crew Transfer system using Realism setting "Enable Stock Crew Transfer". When set to off, Stock Crew transfer buttons no longer appear.

 

Enjoy.
 

[Papa_Joe]

On 3/9/2016 at 0:15 AM, 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.

Just going through the thread from when I was inactive.  I saw this.   I recall having this issue awhile back.  let me revisit and see what may have changed.

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.
 

I recall this.   Re refactored how the part lists are managed.   I will have to go back and check for USI modules.

 

[the_Demongod]

Hey, love the mod but I'm getting a crash that may or may not be caused by this. Just randomly today I started getting a crash upon trying to load certain vessels. The game hangs and/or crashes without producing a crash log so I'm just going off of KSP.txt in the root directory here. While it's not the very last thing in the log, less than a second before the log ends, it says:

[LOG 15:36:02.674] [ShipManifest] - Error:  Error in:  SMAddon.UpdateSMcontroller.  System.NullReferenceException: Object reference not set to an instance of an object
  at ShipManifest.SMVessel.UpdateDockedVessels () [0x00000] in <filename unknown>:0 
  at ShipManifest.SMVessel.RefreshLists () [0x00000] in <filename unknown>:0 
  at ShipManifest.SMAddon.UpdateSMcontroller (.Vessel newVessel) [0x00000] in <filename unknown>:0 
[LOG 15:36:02.677] [ShipManifest] - Error:  Error in:  SMAddon.UpdateSMcontroller.  System.NullReferenceException: Object reference not set to an instance of an object
  at ShipManifest.SMVessel.UpdateDockedVessels () [0x00000] in <filename unknown>:0 
  at ShipManifest.SMVessel.RefreshLists () [0x00000] in <filename unknown>:0 
  at ShipManifest.SMAddon.UpdateSMcontroller (.Vessel newVessel) [0x00000] in <filename unknown>:0 
[LOG 15:36:02.681] RemoteTech: ModuleRTDataTransmitter::OnLoad
[LOG 15:36:02.682] RemoteTech: ModuleRTAntenna: Find TRANSMITTER success.
[LOG 15:36:02.683] RemoteTech: ModuleRTAntenna: Add TRANSMITTER success.
[LOG 15:36:02.684] [ShipManifest] - Error:  Error in:  SMAddon.UpdateSMcontroller.  System.NullReferenceException: Object reference not set to an instance of an object
  at ShipManifest.SMVessel.UpdateDockedVessels () [0x00000] in <filename unknown>:0 
  at ShipManifest.SMVessel.RefreshLists () [0x00000] in <filename unknown>:0 
  at ShipManifest.SMAddon.UpdateSMcontroller (.Vessel newVessel) [0x00000] in <filename unknown>:0 
[LOG 15:36:02.687] [ShipManifest] - Error:  Error in:  SMAddon.UpdateSMcontroller.  System.NullReferenceException: Object reference not set to an instance of an object
  at ShipManifest.SMVessel.UpdateDockedVessels () [0x00000] in <filename unknown>:0 
  at ShipManifest.SMVessel.RefreshLists () [0x00000] in <filename unknown>:0 
  at ShipManifest.SMAddon.UpdateSMcontroller (.Vessel newVessel) [0x00000] in <filename unknown>:0 

Seems like something isn't getting instantiated correctly? Sorry for the vagueness but this is legitimately the only information that might be related to my crash that I could find and I thought I might let you know. I just re-installed the mod in case it was an issue on my end (which is rather likely since this issue just randomly appeared 30 minutes ago) and I'll go test right now to see if that fixed it.

 

EDIT: Well it doesn't seem to be the cause of the main issue I'm having (game hangs on loading vehicle, stuck in some sort of recursive loop that spams log with 'PartChildAttached'), but I'll leave this here just in case it's useful information.

Edited July 9, 2016 by the_Demongod