Messages

A whole bunch of cool tips!



It's a slow day...sorry...

I just released a quick update to fix a bug a couple people found in the new update. Download links and Steam have been updated to 1.0.1.

- GSH

Major update just released. New view for thoughts (let me know how it can be improved!), lessons for the Learning Helper (take a look, you might find a feature you missed), and a whole bunch of fixes and minor enhancements. Check out the first post for more details.

- GSH

Cooking, growing, medicine, and shooting are the skills I usually try to make sure have covered when starting a new game. For all of these I generally accept either a moderate starting score (8+) or a passion with pretty much any value. I prefer but do not require a burning passion. Of these, I consider cooking the least important since that skill will level quickly anyway from constant use. Growing is very important since it has gates at skill level 6 and 8 for important things like herbal medicine and devilstrand and I usually want to be able to start growing those as early as possible.

I consider construction important, but not when starting a colony. Even with no passion someone can work their way up easily enough. I don't consider a high mining skill important at all. When I mine I throw the whole colony at the job so it doesn't matter if a few are slow, with everyone working it goes pretty fast. This is also how I feel about early game construction, but later on it's more important to have a high skill to upgrade quality items.

Everything else is just nice to have in various ways in my mind, although generally speaking I try not to have any skills that all colonists refuse to do.

I know there are posts about hauling, but they're either pre-A16 or have solutions suggested that are just way to complex to warrant consideration. Plus I want to emphasize that I think hauling needs at least a little tweaking despite Tynan's comments to the contrary, so new post it is! I'll try to keep it short.

Two situations:
1) Done mining or fighting, go back to camp, leave the mined resources or raider drops where they lay.
2) Run across the whole map, pick up one thing (e.g. a gun), leave another thing on the ground next to it (e.g. a single meal).

I completely understand Tynan's concern about making the AI too complex and then having to fight with solving the first bug while introducing others and ending up in a frustrating cycle. But I think some sort of simple solution that addresses the most tedious situations is warranted.

For example, for #1, after completing a mining job or being undrafted and getting a new job, check if there is something within X tiles of the current location and a stockpile within X tiles of the new job's location. Similarly, for #2, when starting a hauling job, check if there is available inventory capacity on the pawn and if there is another thing within X tiles of the initial hauling target that can be hauled to within X tiles of the initial target's destination. Effectively turning hauling into a "haul a bunch of stuff from this area" task rather than a "haul this one thing only, not anything else" task. Which, let's face it, is how people do hauling in the real world (i know i know, games != real world).

I tried to avoid more complex solutions like checking along the entire path etc. Regardless of the solution, I feel pretty strongly that it's not added difficulty but purely added frustration when these two situations occur. The second case isn't even a matter of micromanagement. There's nothing you can do about it as a user and it's painful to watch.

Generally speaking, for a game in Alpha I would much prefer more frequent updates, especially in this case given how much it sounds like has been fixed and tweaked. In alpha you want feedback and the best way to evaluate the bug fixes and balance changes you've done towards A17 is to release them without new features to focus players on those changes.

As a player specifically I would prefer more frequent updates for similar reasons...I want to be able to evaluate the changes without the distraction of new features.

As a modder I prefer more frequent updates because it makes it easier to update my mods. Sure, I have to update more often, but the set of changes is easier to manage and allows me to get an updated version out sooner. The more often RimWorld is updated, the more involved I remain on a regular basis, making the turnaround time for updating my mods faster.

The camera use is probably to re-use the existing business logic that renders pawns instead of having to replicate that logic for another drawing routine. Otherwise the colonist bar would need to check what gear is equipped, what gear is visible, clip some textures for partially visible items, determine whether or not to draw a weapon, where hands should be, etc etc etc. Then it would have to make a 2D image out of all that logic. Instead, they are probably making a self-contained view, rendering the 3D pawn, and pointing a camera at its face.

Not sure if that is more or less efficient than the alternative, but it seems easier and may result in less redundant code.

I'll put up with almost anything but a slowpoke. I cannot deal with slowpokes. Always late to the fight.

While not technically a bug, it does seem like a poor solution. The business logic based on vanilla stats should not allow selling for more than you can buy if that is the intent in vanilla, without an arbitrary check and cap. That way mods could allow selling for profit if they want without having to detour.

It's not so much "business logic" just a sanity check.  When you are able to sell a good to a trader, you may buy goods from the trader too.  So if you sell them a component for 40, close the window and buy it for 1, nothing stops you from selling it again for 40, buying it for 1 again, and so on.  It means that you can essentially buy out every item from every trader as long as you're willing to make the clicks by trading, accepting, trading again. 

It's quite a reasonable thing to want to prevent, and I think it actually helps with mods that affect stats because it doesn't cause a surprise edge case to completely break trading.  What is the point of trade related stats anyways if you immediately have infinite money?

Is there a better way to correct it? I don't know.  You could set pricePlayerBuy = pricePlayerSell instead, but then prices get higher as your skill gets better.  Maybe even better is pricePlayerBuy = pricePlayerSell = (originalBuyPrice + originalSellPrice)/2 which if buy and sell price diverge at the same rate will mean that you'll just stop getting any benefit once buy and sell price meet.

You're just pointing out further weaknesses with the current system as an argument for keeping it. What's to stop that situation? Well, the vanilla stats primarily. If a modder wants to be able to make a profit off sales why should an arbitrary "sanity check" prevent that? In such a case it becomes effectively an "insanity check", since it causes hard to identify problems just like the one that started this thread.

It would make more sense to disallow rebuying for starters. Whether or not a trader is willing to buy something, and for what price, could also be impacted by their current inventory. Just a couple ways the system might be improved without the need for an arbitrary "sanity check".

While not technically a bug, it does seem like a poor solution. The business logic based on vanilla stats should not allow selling for more than you can buy if that is the intent in vanilla, without an arbitrary check and cap. That way mods could allow selling for profit if they want without having to detour.

Your google doc is not shared properly. I was given a permission denied error.

I can't help too much with specifics right now since I am at work and don't have the code handy, but I'll try to remember to take a look tonight.

Hello! Great mod, love it!

I do however have a small QoL feature request; could it be possible to make it so it only displays colonists present on the current map in Moody? Or maybe have a toggle between the normal full-colonist display and localmap-colonist display?

A filter mechanism for large games, such as by map, is not a bad idea. I'll give it some thought.

Just a thought regarding the WorldPawnGC. I like that RimWorld keeps these pawns around, but clearly they don't need to be updated every tick. Maybe if there was a detour that skipped updating these pawns but didn't delete them that would be a good alternative solution. Might be more work than is reasonable, but thought I'd bring it up.

I'd like being able to undock the bar and move it around, if possible.  Resizing the window would be great too.  I'd like to be able to see what weapons my pawns are carrying.  There was another mood mod (I think it was called colonist KF bar) where you could zoom into the pawn icons and see what they were using for weapons.  Hotkey support would be good (a way to toggle the bar on and off with a key). Thanks for your consideration.

You can already move it around, just click (almost) anywhere and drag. You can also resize using the handle in the lower right. The skills view (third tab) shows the currently equipped weapon and has a tooltip with the weapon name and quality. Other inventory/gear is not displayed though.

I've thought about a zoom feature actually, but it would require a large rework of how I am rendering the tables currently.

Since the data is already in the wiki, I wrote a quick query to list out the animals' gestation period and maturity period. The numbers are not guaranteed accurate, because the game changes so much... but if you point out any wrong data, I'll fix it.
The page is a sandbox and is subject to change, but not anytime soon.
http://rimworldwiki.com/wiki/User:Jimyoda/Sandbox2
You may need to click "... further results" to see everything.

Hope that helps.

Edit: I added a column for meat yield.

Out of curiosity, why didn't you just add the gestation period to the existing table instead of adding a new table? Having overlapping data in multiple places is much less convenient and harder to maintain.