Messages

I noticed that the coolers are still defective, and still produce excess heat and use excess power when successfully hovering at the selected target temperature. I first posted this over a year ago in this thread. And because higher temperature on the exhaust side reduces cooler effectiveness, this can cripple coolers where it makes no sense, such as an array of coolers dedicated to a small room, with an exhaust duct that is not directly connected to outdoors, but should still be adequate, producing runaway and persistent problems. See my posts from before, including a working code snippet that can be copy+pasted into the vanilla core, to fix the problem. Fixes don't get any "cheaper" than that. (Well, it won't work now, some of the code has changed, the fix needs minor updating, for example compTempControl doesn't exist anymore.)

https://ludeon.com/forums/index.php?topic=174.msg154082#msg154082
https://ludeon.com/forums/index.php?topic=174.msg154259#msg154259
https://ludeon.com/forums/index.php?topic=174.msg156834#msg156834

Oh, and see this:
https://ludeon.com/forums/index.php?topic=18853.msg209266#msg209266
I wanted to reply there, but I could not, perhaps the thread was locked but it doesn't indicate so.

"(Originally I thought there was some actual issue with the coolers, but now I feel like this is too minor to warrant the effort of looking at!)"
There is an actual issue with the coolers.

"What you'll see happen in this save is the "hot" room will keep getting hotter, even though the outside temperature is below the cooler target temperature.

So to answer Tynan's questions:
1)   2 rooms, 1 cooler.   Cooler cold side in 1 room, hot side in the other room.     Outside temperature below cooler target temperature.
2)  Hot room keeps getting hotter (but seems to stop once the heat dissipation is high enough to outdo the cooler)"

This is an issue! The title of the thread is not useful, and is addressed by Tynan in the last post, but the coolers do have an issue. When you have one or more coolers that are doing little to no actual cooling, they should not be exhausting full heat and using full power, as if they were producing maximum cooling. That is the error in the code, because they *do* operate at full exhaust heat and power, even when only pushing out a very, very small amount of cooling, which leads to all sorts of other issues and unintuitive inconsistencies, which can be dramatically bad in certain specific scenarios, especially with an array of coolers on the same room set to the same target temperature. Especially when you consider that higher temperature on the exhaust side will limit how much cooling they can do.

This problem has probably affected every player noticeably at least once, though they might not have known it was a bug. "Why aren't my coolers working, there should be enough of them." "Oh, exhaust is hot, well why is it so hot, I don't have to do very much cooling right now." "Why do I have to stagger the target temperatures of the cooler array to get them to work semi-efficiently? Why don't they work properly in the first place?" (The last one is only for those who realized that staggering targets will result in fewer dysfunctional units in an array of coolers.)

Perhaps a better version than my fix should go into the release, such as one which changes all coolers on the same room to operate at the same level, rather than some high, some idle, and one in between. And perhaps it should have a separate string for "in between", rather than saying high or full. I could implement those as well, but it would take a little more work than my current fix, which only modulates one cooler, because the game ordinarily processes all things and their effects in sequence, not in parallel, including coolers. So two coolers might be determined to be high, then one is intermediate, then two more are idle, for example. Which results in the same total effect, and same total power draw, but it would be better if each cooler displayed an average level when selected, instead of only one out of an array showing an intermediate draw, with the rest showing maximum or idle.

-Inhalt-

Yeah, you discussed a lot about igloos. The no tools thing doesn't matter since we don't use tools for anything unless it's a table. Even with that idea, they'd still freeze to death if they couldn't produce heat using what materials they spawn on the ice sheet with on the first day or as they tried to sleep through the night.

-Inhalt-

As for this, balance matters more then realism. You need the resources that all maps have in mountains, the ores and such. You couldn't have pure ice mountains on an ice sheet, as you'd be completely devoid of resources except for ice and snow and what you start with.

The 'no tools thing' matters for the sake of realism, for plausibility, and that's always an important aspect in any kind of science fiction. It also matters for the sake of the niche I was explaining. Also, igloos are warmer on the inside purely from the presence of people. It doesn't need a heat source to be warmer. If it did require a heater, that too would defeat my whole point.

I think you missed both the point and the niche.

As complex as hauling is, I would kind of like to make it far more complex still.. I mean, smarter. So the colonists don't waste so much time, doing stupid things. So efficiency of my deep-mountain base with crops, defense and power outside doesn't double (or more) whenever I feel like micro-managing the hauling. So skilled colonists use more of their time doing skilled labor, and haulers waste less time on trivial hauls, and I waste less time constantly ordering manual hauls and changing zone priorities.

(omitted) But u can make an ice freezer, and use blocks of ice from traders in othe biomes to have a power free freezer

That's how freezers/fridges use to work. They used iceboxes, and had an ice block delivery guy, like milk bottle delivery, and you put it in your icebox to preserve food. Delivery person hauled it in with big metal tongs and dropped it where needed.

"Iceboxes date back to the days of ice harvesting, which had hit an industrial high that ran from the mid-19th century to the 1930s, when the refrigerator was introduced into the home. Most municipally consumed ice was harvested in winter from snow-packed areas or frozen lakes, stored in ice houses, and delivered domestically as iceboxes became more common." - Wikipedia "Icebox"

In filling the niche of, landing with information but without parkas or building materials, and needing to survive the night, similar niche as camp fire, even something really simple might be adequate. Such as, 'construct igloo sleeping spot'. It takes a few hours, depends on construction skill, can have multiple simultaneous workers, requires no tools to pack snow and stack blocks, can only be built on deep snow, has a flat temperature increase vs. the outside, and has 3 adjacent sleeping spots. Using ice or pykrete walls, built of craftable packed snow or ice blocks, is kind of outside of the exact niche I had in mind. The realism of the igloo means it has to be hyperboloid in order to support a roof with discrete blocks, and the game is rectangular, so using manufactured 'blocks' of ice or packed snow to lay out a wall design is less realistic for the particular niche I had in mind. Even campfires and pykrete require wood (pykrete would probably be strong enough for actual structures, not just igloos, assuming temperature stays below freezing), but igloos don't require you to land with raw wood, and there's no trees to cut down on an ice sheet. (The idea, is to avoid frostbite and 'slept in the cold' when spawning with few resources and no parkas or leather clothing, and unable to construct rooms with campfires or heaters+power source before the first nightfall.)

Hunting trophies could be made at... butchering tables.

Can the same table use different skills for certain jobs?  Because I'm not so sure cooking would be the right skill for making trophies.

It'd make more sense for butchering to produce animal heads, which will eventually rot, and used by crafters at a taxidermy table to produce mounted trophy heads, and maybe even cute squirrels. To produce the heads, would result in less leather, and to taxidermy a whole animal like a squirrel would require the whole corpse at the taxidermy table.

Read some of the wikipedia article on igloos, it's really interesting. There were different sizes used for different purposes, one per family, and perhaps a 'town hall', perhaps a community dining hall, even hallways connecting them. Some of the smaller ones were made as temporary housing, didn't take long to make, and were only used for a few days, less than a week. Some had windows, and I imagine might have had vents for oxygen. Igloo as makeshift short-term shielding from the cold, wind and rain (snow, I mean...), built in less than a day, fits perfectly with the existing campfire as makeshift short-term heat source and means to cook - it fits perfectly with the story of emergency landing on a planet's ice sheet (or more realistically, a planet that's mostly unlivable with some 'ice sheet' areas, therefore an 'ice sheet' planet... if you have a planet like the ones generated by this game, with ice sheet, tundra, boreal forest, tropical rainforest, and desert, and the ship computer manages to pick out a livable planet and make an emergency landing on it, it is *not* going to choose the ice sheet area). And realistically, a small campfire in the open in conditions that cold is going to be hard to start, and won't really keep you warm, just from freezing to death. I think the article mentioned some kind of smoldering heat source used for cooking inside igloos, and combined with body heat and shelter from wind it kept the inside dramatically warmer than the outside. And if anyone didn't know, the entrance from outside dips a little under the surface and then back up through a hole into the igloo floor, like a U-bend or water trap in plumbing, so that the heat is trapped inside, just as how the air is trapped inside a diving bell with no floor... air floats in water, warm air floats in cold air. The same things that made it good for some humans to use igloos here on earth, would also make it perfect for the scenario of being ejected for emergency landing on a water ice sheet, totally unprepared except for dredging up survival information from the libraries in their pods... they'd dig up instructions for making ice bricks of the right sizes out of snow, and laying them into a hyperboloid, so that they can somewhat comfortably survive the night.

I forgot to mention, for Jorlem and if anyone else uses the cooler fix mod, it doesn't apply to existing coolers. So if you turn it on, load an existing game, then coolers you already have made aren't affected, but new coolers you make are. So if you replace them all via god mode, it'll affect them. This threw me for a few minutes, until the nice people in the chat told me that game saves with old coolers are still old coolers. After all, the original coolers are still in the core, the mod just adds a new cooler and points construction to the new one.

That bedside music player needs to loop trololololo

Why not just use dropbox or something similar? Alot of mod users on this site have other options other than Moddb, and as an added bonus i'm pretty sure your file won't need to be authorized there.

I went there first, it asked to install something on my computer, and I said nooo. I don't regularly upload files like this, they're all (upload sites) a hassle.

Igloos!

+1 for the music player feature, that sounds really nice. The balance trade off would be that it gives joy at a lower rate than anything else, a continuous trickle that's just enough to keep joy from dropping while bedridden, and only works while awake (and bedridden), so it's useless for any other purpose.

Would you be willing to post that as an actual mod, for those of us that don't know our way around the game's code?

Sure, but I've never made any mods other than this one just for me, and I don't know how it might interfere with other things. It's ugly, has no standard documentation or comments or anything, and I haven't really done any modding yet (no using mods, I mean), so I don't know about the protocol for that.

Okay, I just went through fun hoops to use "moddb", made an account, told me given info was invalid without giving a clue why, make up some bogus thumbnail image (that wasn't big enough for them at first), just to upload a small bug fix, forced to select an incorrect category because none of them pertained to mechanics or fixes, and... "currently awaiting authorisation. Authorisation can take a couple of days during which time a site administrator will check the file" what fun! No, sorry, guess I can't give it to you in mod form.

Maybe in a few days, but probably not.
http://www.moddb.com/games/rimworld/addons/arucooler

Oh, maybe the "mirrors" button will give it.

I commented earlier about the defect in the coolers, that they use more energy and produce more heat than they should when they are successful in maintaining their target temperature. I implemented the fixed cooler as a mod, it works perfectly and it doesn't use PushHeat or ControlTemperatureTempChange. I could make it more compact, but instead I made it lazier, and a little more verbose, so it doesn't perform certain calculations until necessary. This fix should completely defeat the workaround that I and probably others use abundantly, of always putting coolers together and staggering their target temperatures, and it's even more significant for people who like to put a cooler on every room or anything like that, and also for people who like to actually use the thermostat-style feature instead of just setting coolers to extremely low targets.

This segment here is suitable for copy+pasting directly into the Building_Cooler class, over existing code (for addition to vanilla core). It uses the same variable names that ILSpy gave me when possible, even though they're not the best. edit: I also compacted a few things things, like calculation of energyLimit.

Code Select Expand

if (compPowerTrader.PowerOn) {
    // This version is lazy, it saves time when possible
    IntVec3 intVec = Position + IntVec3.South.RotatedBy(Rotation);
    IntVec3 intVec2 = Position + IntVec3.North.RotatedBy(Rotation);
    if (!intVec2.Impassable() && !intVec.Impassable()) {
    // temperature (the red side) is not used, only temperature2 is needed
    float temperature2 = intVec.GetTemperature();

    if (temperature2 > compTempControl.targetTemperature) {
    Room roomBlue = RoomQuery.RoomAt(intVec);
    // energyTarget, and energyLimit, correspond to energy change of blue room; therefore, energyLimit is negative, energyTarget is too if cooling
    float energyTarget = (compTempControl.targetTemperature - temperature2) * roomBlue.CellCount;

    // this conditional is a simplification of (energyTarget < 0f && !Mathf.Approximately(energyTarget, 0f) )
    if (energyTarget <= -1.121039e-44f) {
        // not idle
        compTempControl.operatingAtHighPower = true;
        // energyPerSecond / 60f * 250f is energy per TickRare
        float energyLimit = compTempControl.props.energyPerSecond / 60f * 250f * Mathf.Max(0f, 1f + EfficiencyLossPerDegreeDifference * (Mathf.Min(temperature2, 40f) - intVec2.GetTemperature()));
        Room roomRed = RoomQuery.RoomAt(intVec2);

        if (energyLimit < energyTarget) {
            intVec.GetRoom().Temperature = compTempControl.targetTemperature;
            intVec2.GetRoom().Temperature -= energyTarget / roomRed.CellCount * HeatOutputMultiplier;
            compPowerTrader.PowerOutput = -compPowerTrader.props.basePowerConsumption * (compTempControl.props.lowPowerConsumptionFactor +
                (1 - compTempControl.props.lowPowerConsumptionFactor) * energyTarget / energyLimit);
        } else {
            intVec.GetRoom().Temperature += energyLimit / roomBlue.CellCount;
            intVec2.GetRoom().Temperature -= energyLimit / roomRed.CellCount * HeatOutputMultiplier;
            compPowerTrader.PowerOutput = -compPowerTrader.props.basePowerConsumption;
        }
        return;
    } } }
    // idle
    compTempControl.operatingAtHighPower = false;
    compPowerTrader.PowerOutput = -compPowerTrader.props.basePowerConsumption * compTempControl.props.lowPowerConsumptionFactor;
}

How's that for cheap?

(edit: there was a little problem in the paste, fixed it, forgot the two lines for idle)

Make solar panel power generation affected by heat. At 25˚C they work at 100% efficiency. As the temp rises they drop in efficiency by a max of 15%(probably at around 40˚C), and as the temp lowers they rise in efficiency by a max of 15%(probably at around -20˚C). This would make solar panels less useful in deserts where they currently operate best, and better in ice sheet where players could probably use the help early on in power generation.

This would be brutal in a long heat wave, all those coolers need power.

On the world map, when you select a landing site, add some filters. Should be pretty cheap (if you don't worry about speed, which you shouldn't have to, since it's a one-time thing for players). Filter by stone type, min and max temperatures, growing season months.

Especially stone type. I love the granite and marble maps.

+1 for this... of the 5 stone types, granite is strongest, and marble is prettiest.

Tynan, Instead of insta-jumping when you click on a 'jump to event' perhaps you could have it scroll there instead? that way you know which direction they are from your base (as well as not having to go searching for said base)

+1 this, so much, this *needs* to be a thing.

Flywheel capaciters: Batteries that don't explode into fire.
(omitted)

Usually when a flywheel at full speed explodes, it's far more uh, explosive than an electrical fire. All that energy is released not only much more rapidly, but as kinetic energy rather than heat. Would easily kill everything in the room, and neighboring rooms.

I thought I'd add, that it's not uncommon to put a high speed flywheel in a hole in the ground, for the sake of safety, then it wouldn't hurt anyone or anything in the event of failure, although it would still be completely destroyed, leaving behind only scrap metal. And a flywheel would probably require research, for materials, bearings, housing, mounting (must be aligned with planet's rotation axis), etc.

(aside about flywheels: It might be a nice energy recovery system for power stations... in many areas, energy prices are lower at night, during reduced load. Many flywheels are small, designed for spacecraft and hybrid cars (not talking about the traditional mechanical piston flywheel). Some are large diameter, I think there was a set of ~3 big ones used for some particle collider. The small ones need vacuum enclosures, kinetic 'armor' lining, magnetic bearings (possibly HT superconducting), and very advanced materials (carbon fiber) for the disc. (See "flywheel energy storage" wikipedia article.) The big ones are often totally exposed and lower tech, with lower edge velocity. Sometimes there's a safety mechanism to discharge excess energy in electrical resistors. Also, I believe the planned "Ford class" American carriers use flywheels to power the electromagnetic catapult, since flywheels can discharge their energy rapidly (electrical generators and structural integrity being the limiting factors)... I think most catapults are currently steam driven, interesting stuff.)

What about one way conductors? It would make it much easier to make redundant batteries, that gets powered by power generators (solar panel, geothermal...), and in the case of power shortage not every system will run out of power at the same time.

I use switches to make a redundant array. I can add more batteries to the back as the colony grows, and I can add more sets if I want (don't think I need to). See attached image.

[attachment deleted due to age]