[1.12.x] DeepFreeze (v0.31.0) 12th Sep 2021

[JPLRepo]

4 hours ago, maxix said:

It worked! Gregmal and Alnie are fine, they started yelling at the KSC since they found out that they have been sleeping 4 years more than what was planned, but as Gene explains them how great it is to discover a new bug that will save another kermans and that it's all about them, they start to feel more confident about their return trip.

Thank you JPLRepo

Phew! That was all the guys at the KSC who had been working overtime to revive Gregmal and Alnie breathing a sigh of relief. Finally they can all go home and get some rest. 
On a more technical note, for anyone else having similar symptoms I shall publish a fix today (hopefully). But this error I think was an isolated one. I could not reproduce your error and the error itself was something to do with your actual vessel not having a reference transform. How that happened I am not sure. But at least we have a fix for anyone else who might manage to build a vessel with a similar problem. Glad Gregmal and Alnie are back! 

[JPLRepo]

V0.20.3.0 fixes a bug when thawing some kerbals where their vessel reference transform was not set in some cases.
Modified debugging and error messages during thawing to assist easier bug hunting in the future.

[AlexSheFF]

Hello JPLRepo! I think I've found a bug. If I switch on temperature and electricity options in DeepFreeze, then launch a ship with any freezer, freeze kerbal(s) and switch to another vessel (or go to tracking station or KSC) and then warp - the electric charge (EC) on vessel with freezer starts slowly decreasing and eventually it depletes completely (no, I don't forget to install enough solar panels and radiators). But when I switch back to this vessel the EC is full although I'm getting messages that freezer is critical and I have to thaw kerbal(s) in 300 seconds or they'll die. Moreover, the freezer in that situation doesn't consume any of EC.

Checked on a clean install with only TACLS 0.11.2.1 (with replacement dll) and DeepFreeze 0.20.3.0 installed. Here's the output_log https://yadi.sk/i/Hi-J5hPDoqjHM with debug option on. May take screenshots if you need but tomorrow (it's 0:45 AM here).

Sorry for possible mistakes (non-English speaker actually) and starting forum activity with bug report 

[JPLRepo]

2 hours ago, AlexSheFF said:

Hello JPLRepo! I think I've found a bug. If I switch on temperature and electricity options in DeepFreeze, then launch a ship with any freezer, freeze kerbal(s) and switch to another vessel (or go to tracking station or KSC) and then warp - the electric charge (EC) on vessel with freezer starts slowly decreasing and eventually it depletes completely (no, I don't forget to install enough solar panels and radiators). But when I switch back to this vessel the EC is full although I'm getting messages that freezer is critical and I have to thaw kerbal(s) in 300 seconds or they'll die. Moreover, the freezer in that situation doesn't consume any of EC.

Checked on a clean install with only TACLS 0.11.2.1 (with replacement dll) and DeepFreeze 0.20.3.0 installed. Here's the output_log https://yadi.sk/i/Hi-J5hPDoqjHM with debug option on. May take screenshots if you need but tomorrow (it's 0:45 AM here).

Sorry for possible mistakes (non-English speaker actually) and starting forum activity with bug report 

First, thanks for bringing this to my attention and providing your log file and the detailed info you have provided.
What you are seeing in the DeepFreeze GUI is PREDICTED time to EC running out. The thing is KSP by default does NOT consume EC for vessels that are not loaded (IE: When you are not in flight mode or when you are in flight mode and the vessel is to far away (you are switched to another vessel more than 2.x KM away)). When you switch back to the vessel in flight mode DeepFreeze will CONSUME all the EC it would have used while you were away from the vessel. IF the amount of EC required at that time is > the EC your vessel has stored then it will consume 95% of your EC only. This is a compromise that I built into the code to cater for the KSP limitation of not consuming EC when vessel is not focused.

What I think you have discovered is in fact a bug, looking at your log when you have done your timewarp at the tracking station and then you loaded the vessel it did NOT consume 95% of your EC. If you run out of EC with frozen kerbals in your vessel a timer will start that lasts for 4 minutes. After 4 minutes either your kerbals start dying (if you have the fatal option on) or they will emergency thaw. But from your log you thawed them all out before the 4 minutes occurred. The bug seems to be how I am checking when your vessel is loaded. According to the KSP API documentation the gameevent I am checking is meant to fire when a vessel loads, switches, launches, but it looks like this is not true. At least it is not firing in all cases when the vessel loads which is the case here. So I have coded a fix for this and currently testing it.

Until I can publish the fix what you can do to get around this problem is one of the following:
EVA a kerbal from your vessel and have them re-board the vessel. 
Switch away from the DeepFreeze vessel to another vessel and then back to the DeepFreeze vessel using the map view in flight mode 
(don't return to the KSC or Tracking station, just click another vessel in the mapview in flightmode and switch to it and then back again).
Or, switch back to the KSC and back to the vessel, which should trigger the emergency thaw/kill procedure.
BEWARE: If you have Fatal option ON and you have not dealt with the EC problem even with this bug your Kerbals will start to DIE after the 4 minute time limit unless you thaw them. If you have the fatal option OFF, then the worst that will happen is they will be emergency thawed and become tourists for 5 minutes then become active again.

A better result/gameplay experience can be had by installing BackgroundProcessor mod with DeepFreeze (llnk in the OP as a recommended mod).
With this mod installed your vessels WILL consume EC even when your vessels are not loaded. If you have this mod also installed, DeepFreeze won't predict the EC using, but will actually see the real EC (with backgroundprocessor consuming your EC in the background) and it won't consume all the EC when you switch back to your vessel. I recommend installing backgroundprocessor along with DeepFreeze if you are using the Consume EC option in DeepFreeze.

Edited February 15, 2016 by JPLRepo

[AlexSheFF]

Hello JPLRepo, it's me again! Thanks for detailed answer! I've installed BackgroundProcessing as you recommended, but the EC is still only slowly depleting up to zero (when switched to another vessel or to Tracking station) and it isn't replenishing when on the bright side until I switch to the vessel with freezers again. Here's some screenshots:

Test vessel. BackgroundProcessing is installed. Freezed 3 kerbals.

Switched to this vessel via Map view. LastUpd keeps 00:00:00 now but TimeRem is decreasing even though the vessel with freezer is on the bright side.

And the TimeRem is decreasing 3 times faster than expected (42 seconds of real time and 128 seconds of TimeRem).

 

Edited February 15, 2016 by AlexSheFF
Readded images

[JPLRepo]

41 minutes ago, AlexSheFF said:

Hello JPLRepo, it's me again! Thanks for detailed answer! I've installed BackgroundProcessing as you recommended, but the EC is still only depleting up to zero (when switched to another vessel or to Tracking station) and it isn't replenishing when on the bright side unti I switch to the vessel with freezers again. Here's some screenshots:

Test vessel. BackgroundProcessing is installed. Freezed 3 kerbals.

Switched to this vessel via Map view. LastUpd keeps 00:00:00 but TimeRem is decreasing even though the vessel with freezer is on the bright side.

And the TimeRem is decreasing 3 times faster than expected (42 seconds of real time and 128 seconds of TimeRem).

 

Interesting. Yes - LastUpd will remain ZERO all the time with BackgroundProcessing installed while in flight. As this time indicates the last time EC was taken. You might see it flicker between 1-2 seconds and back to zero. Depending on your PC. The fact that your EC is not increasing may be a bug with BackgroundProcessing as it is the mod doing the EC add/take when you are not switched to the vessel.  It looks like DeepFreeze is requesting and taking EC from your vessel but BackgrounProcessing is not adding EC from the solar panels. I will have to investigate. Not sure why the times are incorrect either. I will have to do some further testing to see if I can replicate the problems you have reported and report back. Surprised no one else has noticed this?

[AlexSheFF]

One more important finding here (BackgroundProcessing is installed).

Spoiler

 

Full EC, TimeRem says D4:03:39:57. All is OK.

Then I switch to the second vessel and timewarp until EC ALRT (or EC LOW on another case). TimeRem says 00:02:10.

After that I switch back to the freezer vessel using Map view and...

...and the EC is actually FULL  and TimeRem is showing right numbers again. If I stop warping when the freezer ship is on the dark side, the EC is starting to slowly decrease as it should.

So I think it may be something with TimeRem parameter counting some its own "virtual" EC reserves and not taking into account the "real" EC. But it is only my logical conclusion.

 

Here is a new output_log.

Hope it helps you a little bit more 

Edited February 15, 2016 by AlexSheFF
output_og added

[JPLRepo]

On 15/02/2016 at 11:04 PM, AlexSheFF said:

One more important finding here (BackgroundProcessing is installed).

  Reveal hidden contents

 

Full EC, TimeRem says D4:03:39:57. All is OK.

Then I switch to the second vessel and timewarp until EC ALRT (or EC LOW on another case). TimeRem says 00:02:10.

After that I switch back to the freezer vessel using Map view and...

...and the EC is actually FULL  and TimeRem is showing right numbers again. If I stop warping when the freezer ship is on the dark side, the EC is starting to slowly decrease as it should.

So I think it may be something with TimeRem parameter counting some its own "virtual" EC reserves and not taking into account the "real" EC. But it is only my logical conclusion.

 

Here is a new output_log.

Hope it helps you a little bit more 

@AlexSheFF Sorry been busy with real life... I checked your log. There isn't anything to go on. so I did some of my own testing/debugging and yep, looks like something may have changed in KSP that means BackgroundProcessing is no longer calculating solar panel EC correctly. Once I figure out the fix for it I will have to post my own version of it until JamesPicone (author of BackgrounProcessing) returns to the forums (he hasn't logged on since Sep last year).

Bit more testing and it looks like everything is working for me. I'll keep testing and report back.

Edited February 18, 2016 by JPLRepo

[Deimos Rast]

Hey there, not entirely sure if this is the right spot for this report, or if I should post it in TACLS's thread, since I'm using you're modified version from the first page. I suspect the problem is within TACLS, and thus outside of the realm of your responsibility (if so, say so, it's all good), since I've had this issue for a few versions of Deep Freeze now (which leads me to suspect the problem originates with TACLS).

Page after page of this in my player.log:

(Filename:  Line: 4294967295)

-INFO- Tac.LifeSupportController[FFA5582A][12434.49]: Error attempting to check DeepFreeze for FrozenKerbals
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

-INFO- Tac.LifeSupportController[FFA5582A][12434.49]: Object reference not set to an instance of an object
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

MissingFieldException: Field '.TemperatureGagueSystem.showGagues' not found.

You'll note at the end that "gauge" is spelled "Gague" at the end, which I suspect is the issue (but I really have no idea). I thought it was that I had temperature gauges disabled in game, but I turned them back on, and it didn't change a thing. Also, obviously, his mod is also trying to talk to your mod, so maybe you know more about this too.

My question is: is the typo in the modified version that I got from you or in the original version?

Basically, my player.log is 6.5 million lines long and over 300 mb in size, heh. Granted, I do have a hundred other mods installed (including all of your other ones by the way, big fan) and even more null refs, errors and exceptions, but this is the number one re-occurring error, and if I could knock it out, that'd be swell.

You manage a lot of mods and I know you're busy, so again, if this is his issue, don't hesitate to let me know and I'll hustle over to his thread (which, unfortunately seems a bit lonely).

Thanks either way,

Cheers.

(oh, and I'm on Linux x64bit)

[JPLRepo]

3 hours ago, Deimos Rast said:

Hey there, not entirely sure if this is the right spot for this report, or if I should post it in TACLS's thread, since I'm using you're modified version from the first page. I suspect the problem is within TACLS, and thus outside of the realm of your responsibility (if so, say so, it's all good), since I've had this issue for a few versions of Deep Freeze now (which leads me to suspect the problem originates with TACLS).

Page after page of this in my player.log:

(Filename:  Line: 4294967295)

-INFO- Tac.LifeSupportController[FFA5582A][12434.49]: Error attempting to check DeepFreeze for FrozenKerbals
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

-INFO- Tac.LifeSupportController[FFA5582A][12434.49]: Object reference not set to an instance of an object
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

MissingFieldException: Field '.TemperatureGagueSystem.showGagues' not found.

You'll note at the end that "gauge" is spelled "Gague" at the end, which I suspect is the issue (but I really have no idea). I thought it was that I had temperature gauges disabled in game, but I turned them back on, and it didn't change a thing. Also, obviously, his mod is also trying to talk to your mod, so maybe you know more about this too.

My question is: is the typo in the modified version that I got from you or in the original version?

Basically, my player.log is 6.5 million lines long and over 300 mb in size, heh. Granted, I do have a hundred other mods installed (including all of your other ones by the way, big fan) and even more null refs, errors and exceptions, but this is the number one re-occurring error, and if I could knock it out, that'd be swell.

You manage a lot of mods and I know you're busy, so again, if this is his issue, don't hesitate to let me know and I'll hustle over to his thread (which, unfortunately seems a bit lonely).

Thanks either way,

Cheers.

(oh, and I'm on Linux x64bit)

Thanks I noticed that myself on the weekend. I think it's because I have compiled my fixed TAC LS with DEBUG on and it's issuing all these info msgs. I'll take a look if you can turn it off in settings or if I have to recompile it with debug off and report back. That temperature gagues msg I'm not sure is TAC or some other mod. I'll check through the TAC code to see if it's in there or not. If it's not I'd say it's not TAC. Again I'll report back.

EDIT/UPDATE: @Deimos Rast ok all those INFO messages from TAC LS are normal log messages that TAC LS issues. Personally I'd add a setting to turn them on/off (as all my mods do this via a debug option in their settings), but it appears there is no way to turn these off and are intended to spam your log. (I have not changed this behaviour from TAC LS for my modified version).
Also, that message about gagues, Refer to this post. It's nothing to do with TAC or Deepfreeze.
 

Edited February 23, 2016 by JPLRepo

[Kielm]

Hello!

I'm using USI Life Support 0.3.12.0 (latest) and the latest version of this mod, and I'm experiencing the same problem as is described for TAC-LS. Specifically, upon thawing Kerbals, supplies are consumed retrospectively (so if frozen for 100 days, 100 days worth of supplies are consumed). 

I'll post in as an issue on GitHub as well.

[Deimos Rast]

Just a quick follow up to my previous post: it would seem I resolved the issue. It turns out the problem was a conflict with another (out of date) mod, which I uninstalled. No more spam in my log, and everything seems fine.

Thanks again for the help.

[JPLRepo]

22 hours ago, Kielm said:

Hello!

I'm using USI Life Support 0.3.12.0 (latest) and the latest version of this mod, and I'm experiencing the same problem as is described for TAC-LS. Specifically, upon thawing Kerbals, supplies are consumed retrospectively (so if frozen for 100 days, 100 days worth of supplies are consumed). 

I'll post in as an issue on GitHub as well.

I can confirm this appears to be the case... DeepFreeze is correctly triggering USI LS to stop tracking frozen kerbals, but when they are thawed USI LS is then consuming resources for the period they were away. There has been a lot of changes to USI LS lately. I'm investigating.
 

@Kielm UPDATE: This is actually a bug in USI LS, not DeepFreeze.
You can confirm this by doing one of the following:

Launch an empty vessel with USI LS 0.3.12.0 or empty a vessel (EVA all the crew) and leave the vessel for a while.
When a kerbal then enters the vessel after it has been empty for a period of time they start consuming supplies (with major munchies ) for the entire period the vessel was empty. So I can easily reproduce the problem with no Freezer/DeepFreeze involved.
Of course, the same happens when you freeze ALL your kerbals on the vessel with the latest USI LS installed.
The fix is to have at least one awake kerbal on board at all times, until Roverdude updates USI LS. I have sent him a fix and PM.

Edited February 26, 2016 by JPLRepo

[Kielm]

Allegedly the consumption bug has been fixed in the latest USI-LS, will test tonight

[JPLRepo]

6 minutes ago, Kielm said:

Allegedly the consumption bug has been fixed in the latest USI-LS, will test tonight

@KielmWell I was the one that submitted the fix, and when I tested it, it worked.
There was another potential timewarp bug that has cropped up .. So I did not post back here an update, until I understand if that is a bug we should worry about or not. But Roverdude has posted that   0.3.15  should have fixed that which he just released last few hours. So yes, try that.

On 18/02/2016 at 9:08 AM, JPLRepo said:

@AlexSheFF Sorry been busy with real life... I checked your log. There isn't anything to go on. so I did some of my own testing/debugging and yep, looks like something may have changed in KSP that means BackgroundProcessing is no longer calculating solar panel EC correctly. Once I figure out the fix for it I will have to post my own version of it until JamesPicone (author of BackgrounProcessing) returns to the forums (he hasn't logged on since Sep last year).

Bit more testing and it looks like everything is working for me. I'll keep testing and report back.

@AlexSheFF and everyone else using BackgroundProcessing - there are a couple of bugs in the last version of this mod.
The author of that mod has become active again on the forums, you can track progress on the BackgroundProcessing thread.
I'd recommend for anyone to perhaps uninstall BackgroundProcessing in KSP 1.0.3 and above until some bugs are fixed.
I have my own personal version of BackgroundProcessing that I am testing to see if all is resolved, but I won't release it unless the author does not release an update soon.

Edited March 3, 2016 by JPLRepo

[Kielm]

Hello @JPLRepo!

I've been experiencing a bug entering the tracking station while using this mod. It renders the tracking station UI unusable and requires ending the game via alt-f4 or task manager, and I didn't have a chance to look into it until today. Please see the screenshot of the debug screen spamming errors when this problem occurs:

http://images.akamai.steamusercontent.com/ugc/499143085899298410/F70070FFEE84DCF901E389C71937CF48D339FAA2/

Output.log is available if you need it. I'm not 100% sure that it's this mod causing the problem, but if not hopefully you can help pin down where the issue lies. I have 3 Kerbals frozen on one vessel at the moment, and this error occurs intermittently (sadly it's not reliably reproducible). 

 

I will put this on github as well. 

 

EDIT: It's a large output log file, but it's available here.

Edited March 5, 2016 by Kielm

[JPLRepo]

4 hours ago, Kielm said:

Hello @JPLRepo!

I've been experiencing a bug entering the tracking station while using this mod. It renders the tracking station UI unusable and requires ending the game via alt-f4 or task manager, and I didn't have a chance to look into it until today. Please see the screenshot of the debug screen spamming errors when this problem occurs:

http://images.akamai.steamusercontent.com/ugc/499143085899298410/F70070FFEE84DCF901E389C71937CF48D339FAA2/

Output.log is available if you need it. I'm not 100% sure that it's this mod causing the problem, but if not hopefully you can help pin down where the issue lies. I have 3 Kerbals frozen on one vessel at the moment, and this error occurs intermittently (sadly it's not reliably reproducible). 

 

I will put this on github as well. 

 

EDIT: It's a large output log file, but it's available here.

That's a shame.. but a log snippit doesn't help much. I can see you are getting an error, but no idea why.
I have tried to reproduce based on the little information I have to go on.. so I put a vessel out there with 3 frozen kerbals....
went back to the tracking station... no errors for me.
For assistance I will need all the info as per this post.
(IE: Steps to reproduce the error, and full detailed log).
Sorry but if I can't reproduce the error or have a log to debug then I can't help.

[Kielm]

4 hours ago, JPLRepo said:

That's a shame.. but a log snippit doesn't help much. I can see you are getting an error, but no idea why.
I have tried to reproduce based on the little information I have to go on.. so I put a vessel out there with 3 frozen kerbals....
went back to the tracking station... no errors for me.
For assistance I will need all the info as per this post.
(IE: Steps to reproduce the error, and full detailed log).
Sorry but if I can't reproduce the error or have a log to debug then I can't help.

Sorry, the full output log is linked at the bottom of my post as an edit, and also in the first comment on the GitHub issue.

i will backup a save and see if there is a reliable way to reproduce it this evening. All I know for sure is that I hadn't even looked at (flown) the vessel in question so far that time, but as I said I'll try again later. 

I'll grab another output log next time as well.

[Deimos Rast]

FYI: You're big ol' download button on the front page points to kerbal stuff still.

And that error I posted about above with your rebuild of tacls awhile back? Gone. Turns out it was a bad install on my part.

Yep.

[JPLRepo]

1 minute ago, Deimos Rast said:

FYI: You're big ol' download button on the front page points to kerbal stuff still.

And that error I posted about above with your rebuild of tacls awhile back? Gone. Turns out it was a bad install on my part.

Yep.

1) Thanks fixed.

2) Glad you resolved your problem.

[Deimos Rast]

Yeah, me too, I'm just, kind of embarrassed it was just such a trivial thing and for bringing it up in the first place.

In all honesty, I do my damnest not to burden mod authors, and instead try to provide support (such as it is) rather than receive it. But this one slipped through. Sorry about that.

[JPLRepo]

On 05/03/2016 at 0:07 AM, Kielm said:

Sorry, the full output log is linked at the bottom of my post as an edit, and also in the first comment on the GitHub issue.

i will backup a save and see if there is a reliable way to reproduce it this evening. All I know for sure is that I hadn't even looked at (flown) the vessel in question so far that time, but as I said I'll try again later. 

I'll grab another output log next time as well.

Have you reliably been able to reproduce this? or have a save that reliably produces this that you can share.
See my comments on the GitHub issue. I've made some error handling updates to the code (for next version). But not a lot more I can do about this one.

[JPLRepo]

On 03/03/2016 at 5:37 AM, JPLRepo said:

 

@AlexSheFF and everyone else using BackgroundProcessing - there are a couple of bugs in the last version of this mod.
The author of that mod has become active again on the forums, you can track progress on the BackgroundProcessing thread.
I'd recommend for anyone to perhaps uninstall BackgroundProcessing in KSP 1.0.3 and above until some bugs are fixed.
I have my own personal version of BackgroundProcessing that I am testing to see if all is resolved, but I won't release it unless the author does not release an update soon.

Ok @ShotgunNinja has made some adjustments for KSP 1.0.5 to BackgroundProcessing and it's available here. All you need is this DLL file. (click "View Raw" to download it) and then put it into your /GameData/BackgroundProcessing-0.4.1.0/ directory.
Make sure you DELETE your existing /GameData/BackgroundProcessiing-0.4.1.0/BackgroundProcessing-0.4.1.0.dll file in the same directory.

[Kielm]

 

13 minutes ago, JPLRepo said:

Have you reliably been able to reproduce this? or have a save that reliably produces this that you can share.
See my comments on the GitHub issue. I've made some error handling updates to the code (for next version). But not a lot more I can do about this one.

Sadly not. Comments are on GitHub.

Thanks for the improved error handling though, it may help shed light on the root cause.

Good luck with the most excellent mod

[ShotgunNinja]

Hey @JPLRepo, I've updated my interim version... now do ad-hoc raycasting against celestial bodies, instead of relying on the game engine raycasting capabilities. I believe that was the reason of multiple problems. Right now it seems to work fine. No further changes are in plan from my side, promise  Cheers!