Please add the function of extensions to the fridge please. We run a multiplayer server with weight, volume and CPU and the small fridges is so anoying.
walk in freezer maybe.. wouldnt mind one on big builds.. but also.. why do you even need so much space? have the food processors work a bit harder? usually people make MREs.. they dont need to be stored cool. an/or did you guys find the bigger fridges already? they hold twice the amount of the standard ones.
Actually, bigger fridges are a myth. I was pretty sure about what I was thinking but I just did a test to be sure. Fridge1 and Fridge3 both say they hold 875SU and Fridge2 says it holds 1.75kSU. They all actually hold 1.75kSU, 1Tonne or 8,335 vegetables. The tooltip description is wrong. Personally, I don't like eating MRE's all the time. I know it's just a game but I've been there, done that in real life and those things can be nasty. In game I'll have some on me for emergencies (thus the name), but generally I like a variance in my diet. My storage fridge tends to fill up as well and I only play in single player. I think fridge extensions are an awesome idea.
Ye tested the bigger freeze but they are just damm ughly. ;-) Prob is that water containers and stone weigh so much so it fills the firdge when we want to make everything, Also want to save everyting for bad days. Then its a mess moving and sorting between fridges.
very true.. if only the food processors could be linked to 2 inputs.. that would give a lot of space in the fridge.. and who puts stone in a fridge anyway
Well, it is a required ingredient for some templates made in the food processor, so...... When they originally added the cargo controllers and extenders we were told in a follow up post that they were working on a fridge cargo controller as well. That obviously never happened though.
There are no more IDs available to make new devices/ items. You can modify this yourself in the config files to add more capacity : Example, the CV fridge T2 (from the Config_Example.ecf) : { Block Id: 583, Name: FridgeMS02 Group: cpgFridge LootList: 72 Material: metal ShowBlockName: true IsLockable: true IsOxygenTight: false, display: true Volume: 200, type: float, display: true, formatter: Liter Mass: 150, type: float, display: true, formatter: Kilogram StackSize: 100 BlockColor: "110,110,110" Info: bkiFridge, display: true Category: Devices TemplateRoot: FridgeBlocks VolumeCapacity: 1750, type: float, display: true, formatter: Liter CPUIn: 120, type: int, display: true EnergyIn: 5, type: int, display: true, formatter: Watt BlastRadius: 1 BlastDamage: 50 }
They could create a workaround by adding a second Input dropdown, both for foodprocessors and constructors alike.
Would be easier to make constructors able to keep food. This could surely be modded by making the SV/ HV constructor not spoiling food, as it has all "crafting" categories tabs (food, medical, etc) and it has the input-output dropdowns already. The Food Processor is a "constructor" and can be made to keep food fresh by just adding 1 line, so probably the same could be done with the SV/ HV constructors.
So we've run out of numbers? Pretty sure there's an unlimited supply of numbers out there. If this is a limitation of Unity, then perhaps it's time to move to a new engine that doesn't have a problem with +1. I bet Empyrion in the Unreal Engine would look and feel amazing.
It's not a limitation of Unity per se, it's a limitation of how the devs have set up the item id's. We still don't know if they are going to rework it to add more available item id numbers yet. Moving to a different game engine entirely is pretty much out of the question though. That would basically require starting the game completely over from scratch at this point.
That, at least, makes more sense. I can only see it as beneficial to rework the method to allow for more item ID's. As progress is made and the story implemented, I can only see a need for more item ID's and items. But I disagree - moving to a different engine would not mean starting from scratch. Most all of the art assets could be imported rather easily, and I suspect a large portion of code could be ported rather painlessly as well. See: https://docs.unrealengine.com/en-US/GettingStarted/FromUnity/index.html See: https://connect.unity.com/p/project-exodus-unity-to-unreal-conversion-plugin Engine changes are far from unheard of - just look at Star Citizen as a grand example. Yes, there is always a bit of a learning curve, and yes, this can slow down production for a time, but it's hardly an impossibility. Of course, I don't know the back-end details as far as licensing, or what size of a cut of profits either takes - I do recall from some number of years ago, Epic took a pretty decent bite out of a studio's profits, but I have heard this has become far more reasonable of late. I merely bring this up as a POSSIBLE means of growing what is already a tremendously great game into something truly next-gen.
