JPLRepo

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.

I'm looking at how to incorporate this mod (once released) into Roster Manager to manage radiation exposure as part of a kerbal's lifespan and other attributes.

I'm still investigating the issues in KSP 1.0.5. and trying to figure out the models benjee10 has provided as they aren't quite what I am used to. As he has supplied the raw models I can look to fix the collider issues. But I have to go and re-create them all in unity to create the actual .mu files for KSP. I'm playing around in KSP with it and had a few questions for people a bit more familiar with the mod: 1) Did the attach nodes on the ring for the modules appear in the editor or only when you try to place a part. I've noticed the nodes aren't visible unless you grab a module and move it over the ring then it appears behind the part. IS this behaviour how it has always worked? 2) Seems to be a big issue with placing the docking port onto the ring, so it's nodes are messed up and the ring has unity collider issues which is why you can't place it correctly. Is this what people have been experiencing? 3) I can't place the vtol engines on the lander (again believe this is collider issues). 4) I can't place the deep space engines on the endurance (again believe this is collider issues). UPDATE: I completed a re-configure of the Endurance main ring part today. Got it's colliders set up and working correctly in KSP 1.0.5. There is some lag when loading the part either in the editor or flight (up to 10secs) this is because of the new colliders/model changes which to me is unacceptable. I will refine the model and colliders to gain some performance improvements over the next few days and check all the rest of the parts. But the good news is I can build the Endurance and attach the parts and dock/un-dock and fly through the ring. Also the docking port connectors and the attach nodes on the parts need work to refine. Anyway, work progresses. Stay Tuned.

Caution on that. Are you sure the reset method does not reset partially / completed contract parameters? I'm not sure and unless someone knows for sure I'd test that use case.

Clicking on the buttons will transfer the specific amount (as a percentage) of Reserve power to Main EC or vice versa.

I've started looking into revival of this mod. No commitments or guarantees yet. Just making an assessment of the work involved to get it working again (given I already have 4 other mods). If someone can go through and compile a list of the issues with this mod in 1.0.5 that would be great. Far as I know so far there are issues with the part models colliders and attach nodes. Is there anything else?

Any plans to handle solar radiation? Also - FYI you could use BackgroundProcessing Mod to handle unloaded vessels as well.

Yes so in the VAB AmpYear would be using the 18 EC for roll, yaw, pitch (ie. x3) plus data transmitter at max, etc. So it is working correctly. I think the issue here is not understanding that or having the breakdown of that information. So I think I will look at providing that breakdown of the pods EC usage he parts list screen. That way you can see the info in the VAB and plan appropriately.

Not active craft can be handled using something like backgroundprocessing mod. Curious to know - is this mod still being actively developed?

Without knowing the part(command pod) you are using (as I've never seen it before) I would say sounds about right. AmpYear can only guess the power usage in the editor (VAB/SPH) so it guesses the MAXimum amount. The part list was added to assist people in seeing what each part is being reported at. The main problem with command pods is reaction wheels. And life support mods etc that add variable power consumption to a command pod. I'm guessing in this case your command pod has large reaction wheels and they are heavy EC user. I might look at splitting command pod modules up to show every power consumer within them as this has been asked a few times now. oh, and Megajoules - that is from KSP Interstellar and Ampyear does not support that mod right now. See posts above, it's something I'm working on re-adding but it's taking time as KSPIE has so many parts.

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.

Sounds good. Just think about laying them on their side etc. That the user still has to be able to click on them to remove them using KIS/KAS. You need to look at all the boards and come up with something reasonable that you can gain miniaturization/merge boards together through the science tree. but with limits.. Say you can only merge 2 together into 1. That way you still need more than one board usually. Anyway look forward to seeing it. And if @micha030201 comes back you can always roll your changes into his. Good Luck.

Given we now have service bays. I think they look good in service bays as-is. But if I think I know what you are thinking, you want to have one that is 'exposed' (radially attached outside the vessel) then you should re-model it to have a door on it to open/close. You can then re-write the config files for the boards so they burn up in atmospheres quite easily if they are outside a cargo bay or have their door open. All this you can do just creating new models and new config files using existing stock modules. While you are at it, you should look at what science experiments can be modularize onto a board from other mods, etc. And once you have done that, you should look to have up-gradable boards that allow you to merge several functions from other boards onto one through miniaturization (Tech tree nodes).

I'd PM @@micha030201 and leave this here and wait and see what happens for several months. Keep checking their profile to see if they logon. for AmpYear SodiumEyes had already passed on that anyone can take over, so that was ok. TST - Tobyb121 never responded to my PMs and has logged on sometime middle of last year, but I've never heard from. DeepFreeze - Scottpaladin eventually responded to my PMs and gave his blessing to take over. But in all cases none of them had been online for over 6 months before I re-released them. I'd say do your re-model of the parts, at least for yourself and wait and see. As for having to re-do configs for 1.1. That's a wait and see game. I have a feeling Squad are not going to change the configs etc that much and they have said in devnotes and other threads they still backward support things. EG: MU files will still be supported even though they are being replaced with Unity packages.

All good, it's a minor technicality. It is only a config file using TSTScienceHardDrive module from TST mod. But it doesn't distribute the TST DLL. Not sure of the license rules on that. I would have err'd on the side of caution and just included a reference anyway. As an experience "continuer" of other author's mods. General rule I would think is wait 6 months... If nothing go for it. As long as the license allows and you follow those license rules and give credit should all be fine.

@Stone Blue I'm not going to do that.. but here is a dropbox file of the last version seeing how this mod author hasn't been on the forum since the start of December. License allows me to do this, although it has not followed the licensing of other mods that is has 'borrowed' from. eg: TST but never included the TST license in it either.

If you have Raster Prop Monitor version 0.23.0 or up you can right click the parts in the editor or flight and turn transparency ON,OFF,or AUTO. Turn them to OFF.

@Mitchz95 - Yes it is. and other Kopernicus planet packs.

Let me know if you do so we can collaborate.. until JamesPicone comes back to the forum. I'm currently investigating a potentially reported bug with the solar panels code. Debugging it as I type this actually.

@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.

I like the new GUI

@Flagelop Nope. But I have a copy of the source as my mod uses it. I will get a link up on github for those that want it and publish it given that the author hasn't been on the forums since September last year. Here is a link to my github fork of this mod until jamespicone returns to the forum and provides a new download repository. The license allows me to do this (included in the zip). The source code is here.

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?

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.

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.