Messages

Thanks for the info, i did not realize that it went that deep... I think they just need to add a patch to allow peoples computers to use there full potential allowing for much more CPU. memory, and GPU performance to eat thru the updating

Memory - different problem.
GPU - not at fault (Rimworld graphics really aren't that resource intensive).
CPU - current design is using as much CPU as it can (single threaded). Redesign for multithreading probably would help, but adds lots (read: tons of) of other problems and different types of complexity.

As an analogy, sending 2 cooks into a kitchen doesn't mean you'll get your meal in half the time. Some parts of the process can be done in parallel (one cook can cut the veggies while the other prepares the meat), but others simply can't (if there is only one pan, only one cook can use it at a time). If you want to use 2 cooks efficiently under those conditions, you'll have to completely rethink the cooking process (who does what when in which order, e.g. how to prevent both cook trying to use the pan at the same time and still get your meal done). Having a single cook makes this much easier to reason about (there is no one else who could already use your pan, or your knife, or ...), but comes with different trade-offs (it is slower on parts that could be done in parallel).

So why is it that the game lags so hard late game? I read all about less mods and grass sway and so on. [...] But can somone tell me a technical reason [...]?

As far as I can tell, the majority of this problem lies in the way the game performs its updates. Each ingame tick (base time unit) the game has to iterate over (nearly?) every entity (colonists, plants, animals, item stacks, ...) and perform more or less complex update logic on each of them. The more entities you have in your game and/or the more complex the update logic gets, the longer it takes until the game finishes the updates for the current frame and it can be rendered.

So, why does this escalate over the course of a game? Well, the game is always creating new entities, and those entities just rarely go away. For example, each raid on you spawns very likely at least as many entities as raiders (unless you get raided by the same guys again). Most of the time, even if you kill the raiders, their entity is kept alive for future stories (e.g. the next raid from that faction might have the daughter of the raider you just killed). And every frame, those entities will have to be processed somehow (e.g. checking if their dead corpse might rot).

So, the longer your game last, the longer the list of entities to process in each frames becomes.

If you play with mods that either complicate the update logic further (= more time for each update) or add additional entities (= more updates), the situation gets worse.

IIRC Zhentar made some mod for A16 that removed some of the entities, e.g. ones that were dead and incinerated (so they didn't even have a body left which would need update). Of course, this removed those entities for future story telling (so, to take the example from above, the raider that would have been the daughter is then just another raider without that relation). I don't know if that mod still works for A17 (or even, if it would still be needed, as this might have been one of the performance improvements that were announced for A17).

I have a high end MSI gaming laptop all games i play on max no issues but rimworld late game is like watching a picture being taken.

Well, this game is CPU bound (so the graphics card has to wait until the CPU finishes its processing). Most other games, especially the AAA titles, are likely GPU bound, so their fps depend mostly on the time needed by the graphics card instead.

[...] or if they plan to fix this major issue sometime in the future?

Well, this "major issue" is by design. Yes, there are ways to improve this, but significant improvements require a complete overhaul. If it gets really bad I guess Tynan and his crew will look into reworking this process, but that would require a lot of time that can't be used for other things (e.g. new content) and might break existing things in many little ways.

I wish fire was harder to put out..its never much a threat and it would love to have my base burned!

Well, with a bit of preparation fires aren't that much of hassle, true. Still, they can (and with Murphys help, will!) come to surprise you in the worst circumstances. Just lost a full freezer to fire during a tribal raid. But it couldn't spread further, so the colony survived with an near empty stomach

@OP: Just noticed you have a lot of steel walls. I hope you do know they can burn, too! (It's a bit weird with rimworld, steel walls burn, yet steel based floors don't...)

Is it intended that a colonist with the Wimp trait is completely sidelined by pain from diseases, in this case Fibrous Mechanites? Normally Wimp would be a minor annoyance (this pawn can't even fight in the first place), and the mechanites are a mixed blessing, but combine them and he literally just spent 25 consecutive days totally bed-ridden... which actually made it much more debilitating than the lethal diseases I've encountered this game.

This was on the slightly-easier-than-normal Cassandra, incidentally, not that it makes much difference.

Sounds like an interesting game system interaction. What a wimp!

Sounds more like a completely useless pawn.

I don't know that I would call it interesting. I had enough other colonists that it wasn't critical, I would just glance over ever now and then and yup, he's still bedridden.

From an emergent system interaction standpoint, it's kind of neat, and from a story standpoint, it kind of makes sense, but from an actual gameplay standpoint it was really very dull and uninteresting.

Well, ...
Wimp plus short term pain is ok - it's what the trait should do.
Wimp plus long term pain can be a pita - but it can still be worked around, which makes it a somewhat questionable, but bearable.
Wimp plus permanent pain is just bullshit - yes, you could hope for a lucky luciferium trigger, but otherwise that colonist is worse than dead.

Ok, you can disable the trait with a painstopper - but try getting that one when you need it.

I was wondering, could things like rain and standing in water alleviate heatstroke illness?

No.

Just to be clear..

I know they don't in game at current, but could they be coded too in future.

Actually, if its hot, the last thing you want is humidity (so rain won't help, as it just helps to increase said humidity).

The human cooling mechanism (sweating) relies on water evaporation, which gets less and less efficient the higher the humidity in the air is. There's a reason why a "dry heat" is much more bearable than "jungle climate".

OTOH taking a bath in cooler water would help, but that requires a bit more soaking than just "standing in a river".

Some feedback on A17:

The good stuff:

• Animals feel really useful again (all of them, not only the hauling ones)!
• The general difficulty increased quite a bit - playing on extreme feels extreme now!
• Caravan quests are interesting - if you ever get to do them.
• A lot of stuff was rebalanced, and mostly for the better.

The bad stuff:

• Rivers, the novelty map feature, are a bit underwhelming IMO. Playing a river map feels weird, if you want to settle near the river, you basically have to build a wall along its shore or deal with raids coming that way, but not settling near the river forces you quite a bit near the edge of the map, reducing reaction time if a raid comes from there. Maybe having fewer options where you can cross a river (or even walk in a large one!) could help with that...
• Some jobs, like stonecutting or drug making, belong to different skills than indicated in the workbench menu. E.g. stonecutting (now belonging to construction) can still only be restricted on crafting skill levels, which is rather weird and confusing.
• I feel like it's getting much harder to control your wealth now, especially early game. Trading caravans are unlikely to buy what your excess veggies or cloth, and if you're focusing on herding animals, they account for great values. I don't really like fighting against 14 man pirate raids on day ~12 with only minimal defenses with my 3 starting colonists just because my tamer got a bit lucky...

I know you've done a great job so far, and that this update was a big amount of work, but in some aspects (e.g. options 1 and 2 of "the bad ones") it just feels like A17 was released in a halfhearted state.

Funny trivia: I got a kind, abrasive wimp named Val in one game, and he got into a social fight after insulting another colonist while eating. I wonder what he said? "Pass me the salt, you gorgeous fluffy bunny?"

Err... you get enough starting materials for a solar panel or a wind turbine, a battery and at least one cooler air conditioner (that you would most likely need anyways for a freezer)...

I don't think that's too much to do in 7 days (I normally have my freezer running on day 2).

Usually the game tries to give you a joining wanderer somewhat soonish at the start, but it can take a while. Raids don't care about your condition, but they won't feel much better about the heat (and if they do, you might be able to get some of their better suited clothing).

Generally, I feel with A17 that the importance of your performance on the first few days has increased by a lot.

just keep in mind sappers AI aims for beds

Any beds, or specific ones (e.g. in use by colonists)?

Just tested: A colonist with trait wimp and some scars (>15% pain in total) is basically dead.

If you start the game with such a pawn, he can actually do stuff - until he gets his first additional source of pain (e.g. a squirrel bite). Just receiving it triggers the wimp trait (as expected), but since you won't get below 15% pain even after that additional source of pain is completely healed, the wimp will stay triggered forever (well, unless you get lucky with luciferium). He will only survive by other people force feeding him.

This might make for some really hard challenges ("play this without taking any damage ever"), but if this is your starting pawn in a rich explorer scenario (because you didn't know or didn't realize the implications of the combination wimp + scars), you can basically forget about playing that game...

Petition: for starting pawns, please set wimp to ignore the pain from its starting scars (one could set the pain threshold of wimp to sum of scar pains plus 1% if sum of scar pains >= 15%) or force the default character generation to not give him scars with a sum greater or equal to 15% pain, as starting with such a pawn really is no fun.

As they guy who made that 3 K freezer: I'm not 100% all coolers were needed to only reach 3 K (i just put them there to test it, it is by no means optimal). Also, the temperature wasn't stable, there were small bumps somewhat regularly (but only for a short moment) that increased the temperature to ~80 K (-190 °C) (I guess that's when the game does the insulation calculations). One might be able to optimize this design.

Also, Volcanic winter did nothing AFAICT, and cold snap was hardly noticeable (IIRC like -10 °C overall).

When looking at Rimworld skills, I see basically 5 orthogonal skill groups:

• Fighting: Shooting, Melee
• Survival: Medicine, Cooking
• Production: Construction, Crafting, Art, (Research)
• "Dumb labor": Growing, Mining
• Interaction: Animals, Social

How did I get to those groups? Well...

• Fighting: These are the only skills that matter once you've entered combat. Depending on your play style you might only need them until you've built your killbox, but even then they don't become totally useless (e.g. if you get hit by a drop pod raid).
• Survival: These skills are needed to keep a baseline colony running. Well, one could argue about cooking since it could be replaced by eating stuff raw or getting a nutrient paste dispenser, but I'm currently thinking more along the general concept behind the skill.
• Production: These skills are necessary to create a stable living (and working) environment. You can absolutely survive without these, but it will be a challenge to keep your colonists mood above the breaking point.
• Dumb labor: These are skills that absolutely don't require mastery to be useful. I personally see them on the same level as hauling or cleaning: You probably want someone in your colony to be able to do these (depending on your map), but you don't really care about how good they are at it (well, ignoring the growing level requirement on healroot/devilstrand).
• Interaction: These skills can be powerful under the right circumstances (e.g. training massive amounts of hauling animals or recruiting valuable prisoners), but don't influence the basic colony survival much.

As you can see, the different groups all have their own aspects and are more or less independent from each other. However, I still have some issues with this arrangement.

First of all, the "Dumb labor" section feels really a bit out of place. There are some cross-cutting concerns to Survival (Growing) and Production (Mining), but the skills themselves are too basic to really compare to the skills in the other categories. I think these should be moved to the same level as hauling or cleaning, as they really are about the absolute basic tasks one could do (basically anyone having a more or less functional body could do these).

Then, let's look at the Production skills:

• Research: While I think it does fill a balance gap in the game (tribals creating power armor from the start would be a bit weird), I don't really like how it is implemented. It affects nearly every other skill in some way (by basically unlocking new possibilities there), but the researcher by itself doesn't have to be capable of doing anything in those skills. I'm really doubting someone incapable of cooking would be able to "research" pemmican, or someone without any knowledge in crafting could investigate the creation of power armors. I feel like this skill could be split up among the other skills (e.g. add an "experimentation" bill to existing workbenches that lets you research new technologies).
• Construction: I think this skill currently is too broad. It covers basics (walls, doors, roofs, ...), furniture (tables, chairs, workbenches, ...) and electric installations (generators, heaters, coolers, ...). And while I'm not too set on the distinction between basics and furniture (making a door kinda seems similar to making a table), there is a huge level of difference when comparing these to electric installations regarding required know-how, tools and details. (Also, I'm not too clear on why the comfort level of furniture is tied to its beauty level, but more on that in the next point.)
• Art: If you want a perfect example of cross-cutting concerns, it's the art skill. Art is basically about making beautiful things (or, possibly, making things more beautiful). And while sculptures fit the first interpretation quite well, I don't get why the art skill isn't used when determining the beauty of other stuff. Like, how does a constructor determine how beautiful he should make a certain piece of furniture? Or, what makes a colonist think their clothing is really awful when it has barely been used? One possibility to address these interesting questions would be to include an artist (think: designer) in the creation process: An artist might make a polishing pass on a piece of furniture, or design some fancy cuts/patterns for clothing. This could be the same guy creating the chair or t-shirt, or someone else (so your main constructor/crafter can focus more on making a functional piece instead of worrying about aesthetics).
• Crafting: If you think construction is overloaded, I don't know what Crafting is. It covers creating drugs, clothes, weapons, armor, fuel, resources, and I'm sure I'm still missing some (I'm starting to wonder why cooking got its own skill). The question is now: What to do? Should one split this skill up, and if yes, in how many parts? 3 as per the work schedule? 4 with an additional "military stuff" skill? What about drugs (move them to wholly to Medicine or an extra skill)? Add a "dumb labor"-like refining skill for stuff like stone-cutting and smelting? Or something completely different?

Other than that, I think Social is a bit too weak right now, but there were some good suggestions in this thread already.

(Also, on another note: I'd like some way to train colonists in Melee, maybe something like a dojo? Currently that is the only skill where you really have to risk your colonists life to train it...)

Well, these ideas still don't fix the "mastering" problem that's currently in Rimworld, but just increasing the number of skills (e.g. by splitting construction and/or crafting) should increase then number of masters needed to cover all skills (which would require larger colonies, with more pawns able to do dumb labor, and so on).

Well, since filling those spaces with wires seems (not too sure if it was fixed in A16) to work, I have no reason to think filling them with walls wouldn't. Then again, it might just be more useful to have a designated location with a high infestation chance so the rest of your base is relatively safe...

There is a reason why manual allocate/deallocate, if done right, gives you better performance, and why you'd rather use pointers than have multiple copies of 'same' data. And that's also when it gets tricky because you have to do manually in code what's already automated away for about a decade.

Well, the main reason why manual memory management can get you better performance is having the absolute control about where in memory you create your objects (so you can abuse the hardware prefetching mechanisms). Of course, the control alone doesn't do anything, to really gain measurable improvements you need to layout your data structures in a cache-friendly way to help the prefetcher do its thing (arrays/object pools can really help with that).
Contrarily, having to jump through main memory every time you access a new object (that isn't in an array or similar contiguous memory region) basically sets you up for cache misses every time you access that object!

Managed C#/C++ doesn't have 'real' pointers. You have managed objects, everything goes through garbage collection [...]

But every reference to a managed object is basically a "fancy" pointer under the hood (even though you can't really manipulate it). So just accessing an object requires you to dereference a pointer (which can point anywhere the GC/runtime thinks appropriate).

Many CS students I speak nowadays don't even know what a pointer is, let alone the benefits and possible dangers of using them, until they get in their third year. And only if they pick specific advanced subjects like Algorithms or Networking and Operating systems (with mandatory lessons in 'classic' C).

Interestingly, I am a CS student, and those subjects you mentioned were mandatory in 2. to 4. semester at my university in Germany (minus lessons in C, the only language we were taught in any way was Java - so people had to figure out any other language used on their own...). Yes, most of my fellow students aren't always comfortable using pointers, but they really should know their dangers!

I guess you are speaking from an American point of view?

AFAIK only muffalos and dromedaries count as "caravan pack animals" (so if you don't have any of those, you caravan capacity won't increase, even with animals that would otherwise haul stuff)

Yes, that is exactly what I'm asserting. A16 RimWorld is not actively working harder in order to constrain memory usage. It does not unload textures and load new textures from disk. It doesn't load anything from disk at all during game play (except background music in some cases, and that's both very light and easily cached by the OS). It's not compressing anything. Using more memory just for the sake of using more memory actively harms performance; more memory means more paging, more TLB misses, more L3, L2, and L1 cache misses. And when you need to use a 64 bit address space to get that memory, the problem is even worse; now all your pointers are twice the size. The 'Thing' class (one of the more common objects in RimWorld) would grow by over 50%; now everything that uses Thing (which is pretty much everything) is slower just because we might want to use more than 4GB of RAM, never mind the cost of actually using that much. RimWorld doesn't do much (maybe not any) 64-bit math, and already agressively inlines performance critical code paths; it benefits fairly little from the x64 instruction set.

The only users that would benefit from a 64 bit build are the ones experiencing out of memory crashes. The rest would, at best, have a performance neutral experience while consuming more system resources, and at worst see significantly worse performance. Offering a second build is giving users a false choice - there's one right answer, giving people the opportunity to choose otherwise implies that there is an important difference, creating confusion and leading people to make the incorrect choice. Even if the second version is offered "without support", it still creates a support burden simply to explain to users which build they should use.

While you raise some good points against a 64bit version, you aren't telling the whole story, either.

Modern processors employ quite an arsenal of predictors, especially for memory accesses, which are quite good at their job when you are using predictable memory access patterns. If done well, more memory means about the same amount of TLB/L3/L2/L1 misses (or sometimes those numbers even decrease).

Yes, your pointers are twice the size compared to 32bit. However, you shouldn't really be chasing pointers in performance critical code (unless you really can't avoid it), as those are the cause for said TLB/L3/L2/L1 misses. If that 'Thing' class (your example) consists of more than 50% pointers, it means that there are some performance and software architecture issues right there. (This problem is independent from 32bit vs 64bit.) I know, it's the "OOP way" to have pointers and references to every object everywhere, but sometimes this isn't the "right" approach (especially when you are considering high performance applications like games). But I digress...

Also, while it's true that the 64bit and 32bit instruction sets don't differ much if you aren't using 64bit math and the additional registers (!), just using 64bit basically allows you to assume the presence of other CPU features (like the SSE2 instruction set), as some modern 64bit OSes (windows *cough*) require those for their 64bit version. (yes, there might be some very old 64bit CPUs or some very exotic 64bit Linux platforms that don't support those features, but those can still use the 32bit version.)

Also, you're just contradicting your earlier point ("Using more memory just for the sake of using more memory actively harms performance") with your remark about aggressively inlining: Sometimes, you can speed up execution by using more memory. In the case of inlining, that means using more memory for instructions, thereby saving the overhead of a function call. In other cases it could mean using look-up tables, memoization and/or other dynamic programming techniques.

I can't really disagree with your final argument, though: Providing multiple versions has some burden when trying to direct your users to the correct one. That said, you could still have the 32bit version as default and only direct them to the 64bit version (with warning labels!) if the 32bit version has problems or a user is explicitly looking for it.
Finally, I really hope that the Rimworld code base isn't as bad as to warrant your grim outlook on a 64bit version. And remember: This is all speculation until we can measure the difference

(I really hope I wasn't too aggressive in the representation of my arguments. I don't have anything against you personally )

@XeronX:
Games are wonderfully complicated programs that try to do many things at the same time. But in order not to stumble across their many parallel tasks, they need to synchronize at certain points. These synchronization points can be rather expensive (computationally speaking).

One of these synchronization points is usually when sending info to the graphics card driver about which elements should be drawn (as this data really should not be in a corrupted state!). This is sometimes called the "single thread bottleneck", as there can normally only be one thread talking to the graphics driver (yes, there are some exceptions, but those just shift the real point of synchronization around). Other threads can of course work on other stuff like playing sounds or updating the game state - but the frame rate (and therefore the perceived update rate) is still mostly dependent on the one thread that has the most computationally expensive work to do between synchronization points.

What Zhentar wrote about the difficulty of writing correct multithreaded programs is also relevant FYI: Just checked in task manager, my currently running Rimworld instance uses 53 threads!