User talk:Harakoni

I made 2 edits to the Golden cube page. One was to add "vEriFiCatIoN" for the fact that "Cube-Fascinated colonists will go on periodic mental breaks" is true, linking to a screenshot of such a mental break. This edit has yet to be approved. I then made an edit to remove all the spurious ^[verify] tags. As a moderator, you haven't approved my first edit, which provided verification of the "claim", but you did revert my edit removing all the unnecessary and distracting verify tags. Why? Memotype (talk) 21:59, 14 June 2024 (UTC)

So first, I should explain that when your edits are passed through to moderation, they're all merged into one edit unless someone else makes an edit in the meantime. All we get to see is the total combination of all your changes and your last edit summary. Your edit with the screenshot link was approved and reverted as part of the same edit.

As for the reversion itself, a few points:

1. The check tags were unclear - a lot of just said "verify" when they shouldn't and many were not adequately descriptive. I've done a pass over the remaining ones to address that.
2. The verification you added didn't actually address what the check tag was asking for. The tag was absolutely unclear, so its 100% understandable, but it was asking for the MTB or mean time between the breaks - not just whether the breaks happened at all. "Periodic mental breaks" does not describe the frequency. The check tag is one of those since updated to be clearer as to what its requesting.
3. Lastly and most importantly the check tags serve a purpose. They are there to identify information that is missing from the pages, but that would be useful to have. Having the tags there keeps track of what info is still missing and prompts users that might have the information to add it. It can be hard to look at a large page and realize that there is still information missing. They are also not spurious - a reader is fairly likely to want to know how often their colonists get interrupted by mental breaks if they're trying to work out whether they can live the cube or need to rush its destruction, or how risky it is to destroy a cube sculpture, or who to ally with to be eligible for the cargo quest.

Reading this all back, it sounds harsh but please understand that it is not meant to be - I just want to explain that there is a reason for why things are as they are. I am more than happy to discuss this further, including any critique you want to raise re: the status quo or my moderations (facilitating that is in fact why you even saw the reversion in the first place - mods can just reject edits and they would never shown in the histories. I wanted to address it more directly)

On the page I was just editting, I noticed the target chances on the centipede's head assumes that the brain provides coverage for the head. Other internal parts are calculated the same way. Intuitively that doesn't seem right, and it doesn't match the human body parts table, but I wanted to be sure that was a mistake before I go filling out all the target chance fields on the other pages

I'm so sorry but I'm afraid I've forgotten the specifics of how they're calculated since I last made a body part table. I thinks its been almost 2 years ago now.

There was a dev mode tool to extract information to .csv that I used, but I can't remember the specifics. Bork on the community discord might be able to tell you, he's very proficient and even he doesn't know off-hand it might pique his interest.

I do remember that the human table is wrong, however, so please don't use it as a model.

I'm sorry I'm not more help on this one - this is why I write for the wiki. Because otherwise I forget half the stuff I find out :S

Ah okay, I'll ask around then

There's another thing I think you could help me on, the documentation for the animal health table doesn't work with templates that have an underscore in the name. When it tries to load the template for mech_tunneler, it converts the underscore to a space and fails to locate it

Could you take a look at that please? I'm not very good at the referencing stuff

Oh I think I've coincidentally just fixed that - I noticed it wasn't working properly when I was simplifying how the documentation isolated the right variable from the page name.

Check and see if fixed on your end?

Yep, that's all working now, cheers

Hello Harakoni.

Have you recently modified the dark theme ?

The light grey is really too bright, and on some pages, like this one, the text is still white on a light grey background. Also, some parts like tables are dark on this grey background, it makes reading quite incomfortable.

Regards, Şÿℵדαχ₮ɘɼɾ๏ʁ 23:29, 4 February 2024 (UTC)

User:Ickputzdirwech recently implemented a dark mode that keys off the browser preferences. If you're set to use Dark Vector in your wiki preferences, it could be conflicting with the browser toggled one. Try switching to Vecor and seeing if that resolves your issue.

If that doesn't work, revert to DarkVector and check if you have a Dark mode preference in your browser, and see if turning it off or adding an exception for the wiki helps.

If that still doesn't work, then if you can please provide screenshots that'd be a big help.

I have a dark mode on Firefox (or rather automatic, aligning on system dark theme), and I had Dark Vector also. Going back to Vector stops making the pages light grey, but then the background is black, which I find more tiring for the eyes than white. There is a "Light mode » option at the top right, between Preferences and Watchlist, but it isn't a proper link (screen shot : ). I prefer the dark grey colours of the Dark Vector apparrance, but I can't seem to have it without having all the other web pages in light theme.

What is strange is it was working fine a few days ago, and now I have either the wrong colours with Dark Vector (), or the pitch black background without it ().

The colours are fine on my preference page (), but not elsewhere on this wiki.

Sorry for the images, I really don't know how to just put a link, and now I'm not even able to edit my message properly (Flow is terrible for discussions...)

I don't seem to be able to put an exception on Firefox's automatic or dark theme.

What do you think of the current, softer version of the browser only darkmode (vith darkvector off)? Sorry for the delay in getting back to you.

I'm new to editing, so I'm not sure if this is the right place to put this, but I tested some of the questions on your user page:

Blind pyrophobic pawns do trigger the fleeing fire mental break

Deaf pawns do not get disturbed sleep debuffs (Not 100% certain of this one since it's disproving a negative, but I couldn't get disturbed sleep to trigger with anything I tried, including gunfire and lightning strikes)

Elbow blade can be installed with field hands and power claws, and despite claiming to replace the arm in it's ingame description and stats, it is actually an implant, it doesn't replace any parts.

I'm gonna look into luciferium treat order in a sec, I was just doing that for healer mech

Should I put that stuff in the respective pages or what?

Oh thank you! And yes you're 100% welcome to hmu here for anything you need, let alone when you're answering my questions for me.

And absolutely, if you're willing please put the info on the pages.

You're welcome to put it where you think appropriate but if you're looking for suggestions: Sight and on the Genes table entry for pyrophobia, Hearing and wherever the sleep disturbed thought is described (if it is anywhere), and luci on the luci page. Elbow blade and hand replacements are probably best on either the massively incomplete Body part weapons page or on Elbow blade. In both/either case, in analysis rather than summary.

Thanks, I was just adding a couple of those and taking a look over the body part weapon page, but I couldn't for the life of me work out how to add the type of body part (implant or prosthetic) to the table, any idea how? Sorry to bother you

You're not bothering me. Always feel free to ask.

As for the table, you mean this table, Body part weapons#Comparison table?

If so I can see why you're confused. That table uses #ask to find anything that matches its parameters and then it feeds the matches' information (each of the properties with a ? In front of it) into a template to generate each row. This lets it automatically update when the pages are changed and also lets us avoid making all the tables manually.

The template it feeds into is Template: Body Part Weapon Table Row . That template is pretty simplistic - all it does is format the properties the ask feeds in. It doesn't even call True Melee DPS Calculator.

These properties are set by the infobox main template on the respective pages. That template is where you would add the new cell (and then on the page itself, add a new cell to the headings as well)

Atm there is a property for what body part a thing goes into/replaces Property: Body Part (which seems underused) but there isn't one for whether it's an implant or a replacement. This leaves you with a few options -

1. you can create a list of implants and then check if the name is on the list in the template, this is the easiest but obviously needs to be updates manually and doesn't let us use the implant/replacement info elsewhere
2. you can add the property to Template: infobox main and then add the call to the pages of each, then add the ? Property to the #ask then add a cell to the template. This lets us use the property elsewhere and it mostly is just copying what's already there and changing the names, but it's the most complicated and most work. You might want to hit up User: Ickputzdirwech, another Moderator here. They were doing work on the DPS Calculator and might have input on how to implement the property as it'll be useful for that too.
3. tag it with {{Recode|section=1|reason=Add "implant or replacement" column to table}} and let someone else handle it.

I know it's a bit overwhelming and not new editor friendly but the templatisation saves so much time and effort long term. I can help you with any of the options you wish to take, and you're perfectly justified to just go "nah someone else fix it".

I think we could get away with checking if the body part weapon is in Category:Implant.

I was trying to do what ick said, using category:implant and category:artificial body part, because that seemed like the only place the two are distinguished, but I couldn't figure it out. Thanks for the help, but I think you're right about this not being new editor friendly, I'll stick to just regular text editing for the time being

I added two columns to the table. Does it somewhat fit your expectations?

Ooh thank you, that's great

Had to change discord accounts.

I have been locked out of my discord account while I was absent due to a work trip. I've asked Khitrir to relay this information and any issues posted on the discord to me and he's been nice enough to agree.

If you see any activity from my discord account before I confirm on this page, please let me know via Khitrir or the Wiki itself. I don't believe my account was compromised but I do not want to responsible for any harm if it was.

Thank you, sorry for the inconvenience!

Gotcha. No worries, I'll keep tabs on the Discord in the meanwhile.

After being jerked around by discords help service, I've just made a new account (harakoni254)

Gotcha. Thanks for the update.

The exaggerated gain of 144,000 total experience is an exaggeration and assuming they all hit a skill with passion, since the multiplier for other skills is 35%, a baby growing from 0 to 18 would never gain passions so no I could never win 8000, that's only for children over 13 who already have their maximum passions, but they could only be in growth vat 5 years (15 days) that is 8,000x5=40,000. If a child, as the wiki text says, spends the full 54 days, he would never gain passions, so he would only increase 2,800 (8000x35% no-passion skill), and therefore, after 54 days, he could never gain that amount of experience. Babies are not born with passions, unless they have some specific hereditary gene as in the case of the Yttakin, Great animals. But babies from 0 to 3 can only gain experience in shooting, melee and social. That's why a boy from Cuba would really be useless, after all, but you would have 1 adult of 18 in less than a year, and all the abilities fairly uniform, he would have 6 abilities at level 2 (almost 3 for being 5600 exp ) and the other 6 skills at level 1 (almost 2 for being 2800 exp)

some calculations

5,600x6=33,600 2,800x6=16,800 33,600+16,800=50,400

That is why the change from 144,000 to 50,400 is necessary.

If you were lucky that they all went up to any of the first 3 skills, shooting, mele or social, they would reach level 9 halfway to reaching 10 If the child was born with passions that should be possible with mods, it would be something else.

It's not a matter of exaggeration, it's how the mechanic actually works. It grants 8k experience every 3 days, and THEN the pawn's passion or lack thereof applies its multiplier. Saying the actual experience value granted is the standard on the wiki. Between assuming the reader knows the correct mechanic or misunderstands the mechanics in that specific way, the wiki HAS to assume the former. We can then mitigate the latter by specifying that its listing pre-passion multiplier values. Doing otherwise is wrong and confuses people that actually do know the mechanics, especially when you change the values to post passion values while still keeping the "pre-passion" disclaimer.

Meanwhile, it's not even correct in practice because there are ways to affect passions and still use the vats. Players might have yttakin as you mention, or custom xenotypes, or only keep pawns on the growth vats for part of their childhood, or hell, even want to know how the vanilla mechanics work to better understand their mods. Mixing the value types given with the 3-daily value as pre-passions and the full time as post is also a non-starter for obvious reasons.

Now if you want to add more language to clarify, please go for it, but changing the base experience goes against the standard for a reason, especially when you make it explicitly wrong by leaving the section saying it's the pre-passion multiplier value.

I'm trying to replace: https://rimworldwiki.com/wiki/File:Nutrient_paste_dispenser_no_hopper.png but getting an error message: "File extension ".png" does not match the detected MIME type of the file (image/jpeg)." even though both original and replacing images are .png. I hope I didn't accidentally create 50 new image uploads for you to sort through

Hmm odd. Are you sure the file itself is a png. As you probably know, you can't just change the file extension, the file itself has to be converted, so often things get named wrong and the file type and extension disagree.

Just try uploading it under a new file name for now.

When the upload didn't work initially I opened the file in photoshop and tried to upload a jpg and a png version and got the same error message regardless. I think I already put a new image in the approval queue and if I didn't a new one will be soon. How would I mark the outdated file for deletion/ review?

Use Template: Delete

For clarification, should references to modded gameplay exist on pages such as Temperature or in general? I feel that mentioning modding disrupts pages dedicated to essential vanilla mechanics without contributing anything but a side note.

Generally speaking, references to modded gameplay should be avoided (outside of modding or technical pages obviously) except where it provides clarity or context to vanilla mechanics. Even where that exception applies, it generally should not document or reference specific mods. Basically we want to 1) keep the wiki focused and unconfusing, and 2) not turn into a documentation site for mods. You should feel free to use your judgement in achieving that goal - if you feel it does contradict that, you're not only welcome but encouraged to change it.

For some examples on how I would personally achieve it, I'll take the references on Temperature.

"The minimum temperature is not encountered during normal unmodded gameplay" is fine as it explains that the system and limit exists and is functional in vanilla, but won't be seen by most players. It could also be changed to "normal gameplay" without significant issue but removing the context of "unmodded" does mean that it now raises an implicit question of what constitutes "normal gameplay". It could mean unmodded, or just that the chance is vanishingly rare, or only exists in specific, unusual combinations of vanilla gameplay.

But for "No amount of added heat, even with modding tools, will affect or change the outdoor temperature." I'd remove "even with modding tools". It doesn't meaningfully add anything to the explanation of the vanilla mechanics, and worse it also speaks authoritatively about mods in a way that can't be done. There are a huge amount of mods and there are some, like ProxyHeat, that do let you do that.

That said, that's my opinion on how to achieve those goals. You're welcome to disagree and implement the changes you think better the wiki. Be bold.

On the technical side, do you know what the lowest obtainable temperature range is? Lowest I've seen in ~-100°C

I'm very late to replying to this, but the temperature is capped at -270 Celsius (game probably rounds to 3 Kevlin). When temperature was first added, I made a bug report for being able to go below absolute zero and it was fixed shortly after.

https://youtu.be/sn1oyE8DbIU

Greetings! As you may know, I am very new to this wiki (but have lurked for a while) and would like to ask a question. I play a highly modded Rimworld and know that making a page pertaining to a modded game is definitely inappropriate for normal pages. Would this be a good use for user namespace pages, keeping it separate from the main wiki while still having it accessible?

Within reason, sure go for it. We have another user hosting a category system for mod recommendations on their user page for instance.

Thats within reason though - making 100 pages for different mods is probably outside of reason for example. Detailed documentation of a mod (i.e. replicating the current wiki style but for that modded content) also probably isn't going to successful. Its been tried before, by people that think they are willing to do it, but its pretty much always failed. Most of the time they don't even get the first version complete, let alone keep it updated. I'd also ask that you be careful using some of the more complicated templates - they tend to set properties and things to allow for automatic calls from other pages, so if you use them without knowing how, you might inadvertently mix modded content in with vanilla. I can help with that if you want to try it.

Hope that doesn't sound too harsh, but we get a lot of people wanting to put up modded content but it never gets maintained. Heck, we struggle to keep the modding tutorials updated. All that in mind, Guides like the one you've posted are probably the ideal, especially for something as popular as CE. It has a moderate chance of staying updated, it can keep a lot of info confined to one page, and it won't accidentally pretend its a vanilla item,

Good luck and lemme know if you have issues.

I obviously can't be online 24/7 but I'll do my best to semi-regularly update the page on top of regular wiki activity. Thanks for being so helpful.

• Combat in Darkness

From what the game tooltips say, darkness precept applies after shooting/weapon accuracy, but before cover. I don't have the means to test if its true. Regardless the precept is absurdly good and why i mention it everywhere it's relevant

• LMG & Darkness precept:

Good quality, Shooting 10, Distance 18, Combat in Darkness precept, no cover. Game displays that LMG has 50% to hit. AR has 68% to hit. Results in (Optimal DPS * expected accuracy) of 7.89 vs 7.34 respectively.

LMG staggers. But AR has a shorter TtK, which is relevant for killboxes. Shorter burst time = good. AR has its usual advantages like outranging centipede blasters. Plus this isn't considering HSMG (55% acc, 6.787 dps at this range) or CR (61% acc, 8.07).

If you're in a mountain then you would probably be using shotguns / HSMGs instead. If you weren't in a mountain you are most likely fluid + sunblocker and it's not worth the effort to make an entirely different set of weapons. Roofing over everything doesn't work unless the enemy is considered "indoors", which while possible would deviate from the normal set up.

• Haygrass vs corn

I think one of the biggest pros of haygrass is growing speed. In year-round or like 50/60 you can just make the pen bigger or use dandelions (which should probably be added to more places inc. haygrass).

• Turret cover

As of 1.4, apparently mini turrets use cover (see here)

• Cheapest 100% comfort

MARKET VALUE:

• Masterwork wood dining chair - $185
• Excellent armchair - $322.5 (0.99 comfort)
• Legendary cloth kneel pillow - $230
• Legendary wood pew - $210 per seat, 630 all

However I believe the super wealth-managey meta would be to use bi-phasic or some other form of rest schedule, due to how quickly comfort rises and how slowl it falls.

Thus without considering wealth, dining chair better if you have production specialist and/or plenty of wood + work to burn. Armchair easier to make.

splitting into second comment for length:

• Mechanoid page format

My reasoning for the current format (like centipede gunner as-is) is as follows:

1. Have parity between the 5 combat mechs in core, and combat mechs in biotech. Ideally it would apply to all mechs, but that is what to be improved.
2. For existing mechs, put all biotech summary stuff in its own subsection. This would be less confusing for players who dont own the expansion

I would agree that it's messy. But I would at least request for "as an enemy" and "as an ally" be completely separate and grouped up.

Maybe the following order could work

• Occurrence: Enemy appearances & enemy AI
• Summary: mechanoid summary template & combat & possibly work
• As an ally OR mechanoid creation OR acquisition: Biotech stuff. Creation & power need
• Analysis / Analysis - as an ally

For the worker mechs it would make more sense to have acquisition over summary. As I'm writing this I realize that it would be the same as the format as-is but with enemy stuff closer to the top

Re: Template:Xenotype Faction Table

Would it be possible for A. Factions with 0% chance to be suppressed, or B. have the table be collapsable? Thanks

Either can be. A was considered but the reasons it wasn't implemented were:

1) the question of whether there will be instances where you want to directly compare two different tables like the its sister template, Faction Xenotype Table, does at Pirates#Xenotypes. Having different row number and orders makes comparing them frustrating. 2) The risk that suppressing the rows will confuse absence from the faction for absence of information, and vice versa. For example, a reader might see that the base game tribes are missing from table and assume the information is just missing rather than that non-baseliners don't spawn in them. And on the flip side, the tables don't currently list Ancients because I don't have xenotype distributions for them, not because they're all 0% (though they might be, idk).

Feel free to weigh in/disagree/agree with me on that, but there was reasoning behind it.

If you're happy with B instead, would you prefer that a single command collapsed all examples of Xenotype Faction Table on the same page (e.g. if you want to do something similar to Pirates#Xenotypes, one click collapses them all), or collapse them individually (more flexible)

I suppose the other option would be to make better use of horizontal space, by making multiple columns. I forgot to ask for this but probably the better solution with that considered,

That makes it very wide and breaks sorting.

Edit: Actually rereading that, I'm not certain what you mean by making multiple columns in this regard. Columns for each xenotype make the template a lot more complicated and processor heavy.

Columns for factions.

IE:

Gentle tribe | Friendly outlanders
Fierce Trible | Rough Outlanders
etc.

This is only in regards to the table found in the xenotype pages like Highmates.

I'm not sure what the actual utility of sorting factions is. For not-baseliners: every xenotype has, like 2-4 factions in which they can appear at all. Other than world generation, there's no way to explicitly choose a faction other than ally/enemy. And because there's like 2-4 factions per xenotype, the sorting wouldn't be very helpful

Columns for each faction would be very wide, and dynamically merging them (e.g. Pirates and Cannibal pirates have the same) would make maintaining the template a bitch when the whole point of this was to make it all updatable from one source (or 1 and 2 very very minor and easy addtions if new factions are added).

And sorting is handy and future proof. Each DLC has added factions and there are likely to be more and that is in additional to the current ones changing and the factions currently missing from the table that need to be added (Ancients etc). The current xenotypes and factions are already getting enough entries to justify sorting. Dirtmoles have 5, hussars and genies 6, neanderthals 7, baseliners 11. And its not just world gen when its relevant. Say you want a neanderthal pawn for whatever reason but didn't add the neanderthal tribe at world gen, you can pick fights with the factions that have the most, become friendly with the rest, and preferentially have raids with the chance of pawns you want.

And tbh the tables aren't that large. But I will make them collapsible regardless.

Collapsing implemented. Looks better when theres a title but it works with the base as well.

Also includes a precollapsed version for use on highmate, just add "collapsed" as the third argument to the template.

{{Xenotype Faction Table|Highmate|Highmate|collapsed}}

Re: Raid points & wealth management & wealth

Asking for feedback on recent changes to these pages. Added more derived calculations to raid point page, and removed them from wealth management. Also any other feedback is advised (I think wealth management is a suitable quality article at this point)

Re: Nearsighted

As I understand it, nearsighted lowers Medium range accuracy of the weapon. Since accuracy is linearly intropolated between Short (12 tiles) and Medium (25), then it would have an impact past 13 tiles, am I wrong?

Re: Nearsighted, I thought so at first too, given how the rest of the mechanics work, but according to the tooltip thats not how its implemented. See here for an example. Then again the tooltip is not infallible as the recurring turret cover issue showed.

Re: The other three How recent is recent? You've been working on those pages on and off for a while. Gonna assume the last few days, and only talk about the changes relative to the page state before. Lemme know if you wanna talk about a longer block of time/go over the page as a whole in depth.

Re: Raid points, taking recent as since the 19th of Feb.

• The edits are pretty much perfect. The only issue I have is that the "1 pawn point is worth x storyteller wealth" might get confused as a true equality, where it adds to storyteller wealth directly. This should be understood by people reading the whole page, but its a pretty convoluted topic, and people might skip sections. Basically just idiot/newb proofing. I'd probably reword it to something like "Given (threshholds/pawn count etc), pawn points increases by 1 for every increase of x in storyteller wealth". I know its not something you started, its used elsewhere on the page but it is something I'd fix.

Re: Wealth, taking recent as since 17 of January.

• No issues with those edits themselves, though the page does overlap significantly with the other two. The examples might be best on Wealth Management, the raid points are largely duplicates of parts of Raid Points. Duplicates like that make it harder to maintain and keep everything consistent (For example: Genes gets updated but the xenotype pages listing gene details don't - one reason I'm considering making their lists more like Hussars or template-izing them). It might be better to treat the page as a sort of "big disambiguation" or summary - give summaries and basics but leave detail to the main pages - basically all the other subsections would be fine as-is but analysis and raid points would shrink. But honestly that is just nitpicking.

Re: Wealth Management taking recent as since 20 Feb.

• Again perfect. Solved the info duplication issue I had with the page, but left the important details. You could add the same short eqn summary for the other wealth bands, but again just nitpicking. The page as a whole is in a good state, and can definitely have the under construction banner removed now. Long term, some worked examples of common strategies people use might be good and some analysis of the expectation thresholds (and likely more importantly, how they trigger other things like Ideo requirements). The examples from Wealth are a good basis for the first one - a lot of the things people avoid like the plague actually have minimal effect on raid points.

Re: Wealth management

The reason I left out the other wealth bands was, that if you are at 400k wealth, you are very likely at lategame or endgame stuff (bionics, charge rifles, etc.), so you should be able to handle the raids. The explanation for that was kinda clunky so I left that out.

---

Re: Wealth

Yeah, the idea [of the wealth page itself] was to put all the stuff together in 1 place.

The extra detail on raid points from of today/yesterday were to move the calculations from wealth management to a different place. The number crunching for wealth managmeent's 1 point = X wealth should be somewhere, but it'd be clunky on the raid points page (you'd have to place the "1 raid point = X wealth for real" section after all the actual factors to RPs). So the wealth page was the next best place.

I put the worked examples in the analysis in the Wealth page, mostly due to search optimization. Ideally the page should have some example of "wealth doesn't impact raids at <= 100%". Because when people say "wealth" / "too high wealth", they imply wealth management.

TOPIC: User:Hordes/Basics Guide

I have 2 generalish questions that have to do with the basics guide rewrite and its content.

1. Wood generators vs wind turbine

What should be recommended for early game power? Wood-fired generators take a lot of work - even more so if you don't optimize base layout - and I often hear it's kind bad, even in the early game. Wind turbines are definitely easier, but are still inconsistent.

I really have no stance on this.

2.. Freezers

What should I recommend with freezers? Freezers make a new have to worry less about food. But as I write in the current version of the article, you shouldn't need to worry in the first place. There'll be details on how to make a freezer, regardless or not I actually recommend.

Being congruent with other rimworld guides (which do, most often, recommend a freezer) is also a positive.