User talk:Harakoni

Jump to navigation Jump to search

About this board

GingerWolf (talkcontribs)

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

Harakoni (talkcontribs)

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

GingerWolf (talkcontribs)

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

Harakoni (talkcontribs)

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?

GingerWolf (talkcontribs)

Yep, that's all working now, cheers

Reply to "Target chance for internal body parts"
SyntaxTerror (talkcontribs)

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)

Harakoni (talkcontribs)

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.

SyntaxTerror (talkcontribs)

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 : GPUqXBS.png ). 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 (JpV0vjc.png), or the pitch black background without it (Wb7aQW5.png).

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

SyntaxTerror (talkcontribs)

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...)

SyntaxTerror (talkcontribs)

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

Harakoni (talkcontribs)

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.

Reply to "Dark theme"

I tested some of the questions on your user page

GingerWolf (talkcontribs)

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?

Harakoni (talkcontribs)

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.

GingerWolf (talkcontribs)

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

Harakoni (talkcontribs)

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".

Ickputzdirwech (talkcontribs)

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

GingerWolf (talkcontribs)

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

Ickputzdirwech (talkcontribs)

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

GingerWolf (talkcontribs)

Ooh thank you, that's great

Reply to "I tested some of the questions on your user page"
Summary by Harakoni

Had to change discord accounts.

Harakoni (talkcontribs)

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!

Zesty (talkcontribs)

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

Harakoni (talkcontribs)

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

Zesty (talkcontribs)

Gotcha. Thanks for the update.

Miscalculation del Growth vat (Growth vat child)

Mong (talkcontribs)

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.

Harakoni (talkcontribs)

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.

Reply to "Miscalculation del Growth vat (Growth vat child)"
Falmingkitter (talkcontribs)
Harakoni (talkcontribs)

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.

Falmingkitter (talkcontribs)

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?

Harakoni (talkcontribs)
Reply to "error replacing file" (talkcontribs)

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.

Harakoni (talkcontribs)

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. (talkcontribs)

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

Zesty (talkcontribs)

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.

Reply to "General referenced to modding"
Admiral Zubr (talkcontribs)

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?

Harakoni (talkcontribs)

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.

Admiral Zubr (talkcontribs)

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.

Reply to "User namespace pages"

Investigation To-do and other stuff i may have

Hordes (talkcontribs)
  • 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


  • 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.

Hordes (talkcontribs)

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

Hordes (talkcontribs)
Harakoni (talkcontribs)

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)

Hordes (talkcontribs)

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,

Harakoni (talkcontribs)

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.

Hordes (talkcontribs)

Columns for factions.


Gentle tribe | Friendly outlanders
Fierce Trible | Rough Outlanders

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

Harakoni (talkcontribs)

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.

Harakoni (talkcontribs)

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}}
Faction Chance
GentleTribe.png Gentle tribe 0%
FierceTribe.png Fierce tribe 0%
SavageTribe.png Savage tribe 0%
CannibalTribe.png Cannibal tribeContent added by the Ideology DLC 0%
NudistTribe.png Nudist tribeContent added by the Ideology DLC 0%
FierceNeanderthalTribe.png Fierce neanderthal tribe 0%
SavageImpidTribe.png Savage impid tribe 0%
Civil outlander.png Civil outlander union 0%
Rough outlander.png Rough outlander union 0%
RoughPigUnion.png Rough pig union 0%
Pirate.png Pirate gang 0%
CannibalPirate.png Cannibal pirate gangContent added by the Ideology DLC 0%
YttakinPirates.png Yttakin pirates 0%
WasterPirates.png Waster pirates 0%
Empire map marker.png Shattered empire Content added by the Royalty DLC 0%
Hordes (talkcontribs)

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?

Harakoni (talkcontribs)

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.
Hordes (talkcontribs)

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.

Hordes (talkcontribs)

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.

Reply to "Investigation To-do and other stuff i may have"
Rab (talkcontribs)

Hi Harakoni... Just to let you know that I've started making some checks and corrections to the surgery section and other related pages.

The entire thing seemed to have become a bit confused on the wiki - bits and bobs had been added in different places: some repeating the same thing, some contradicting, some just wrong, as I'm sure you're already aware.

I noticed that:

  • some of the pseudocode on the Doctoring page was incorrect (like outdoors modifiers etc.)
  • the pseudocode itself it was incessantly complicated for a non-developer to understand.
  • The explanations on the Doctoring page mish-mashed the concept of surgical success chance of the doctor, with the type of bed, with the instance of bed.
  • The explanations appeared to get confused with environmental factors such as cleanliness and light level - in fact these affect the bed's surgery success chance multiplier which is a separate stat.
  • The concept that operations have their own individual success modifiers appeared to be missing completely.
  • The concept that facilities such as vitals scanner could modify outcome probabilities wasn't mentioned.
  • The concept of lighting was alluded to, but contradictory and not complete.
  • Generally the nomenclature "surgery" and "operation" seemed to be inconsistent across the Doctoring page; the entire wiki, and references back to the Doctoring page. It's quite confusing from a new reader's standpoint as they sound like two different things. It's admittedly a bit inconsistent in the game itself especially the descriptions - but one thing is clear, that the action on the colonist is an "operation".

So what I've done is:

  • Simplified the pseudocode into simple, worded equations like you'd see on wikipedia - no mathematical symbols, variables or logical control statements (viz. "if"s).
  • Broken up the different concepts onto their respective pages: Colonist Medical surgery success chance/Doctoring, Bed Surgery Success Chance Factor, medicine potency and operation chance multiplier.
  • Broken up the concept between the type of bed and the placement of a bed in-world (i.e an item or instance of a bed). This is explained fully, with the equations on the Sleep Furniture's Surgery Success Chance Factor stat.
  • Added previously omitted per-operation success multipliers to the Doctoring page.
  • More consistently referred to operations as "operations" on the Doctoring page (at least in the scope of my edits so far).
  • Checked contradictions or questionable claims against the latest game version and adjust as necessary.

What I'd like to also do is (pending acceptance of the further edit):

  • Put in a redirect for Surgery -> Doctoring#Operations (Surgery) (there's already one for Operations -> Surgery).
  • Consider further breaking down the doctor's stat calculation to the Medical Surgery Success Chance page (where from an engineering standpoint it should really live) - then refer to it from the Doctoring page.
  • Do a quick check regarding nomenclature across the wiki wrt surgery vs operations - and make any changes needed if it will make things clearer. They should always link to the right place regardless.

Apologies that the diffs from my edits must look hefty and complex - however if you look at the resulting pages it makes the entire thing simple to understand, plus from an algorithmic standpoint it's accurate and complete. The changes are very localised and specific to the operation chance factors, even verbose. I've tried to ensure that no pertinent information has been discarded (if you see this, they have probably been moved to the correct page). I hope this explains my string of edits! It's difficult to explain this in an edit summary.

Harakoni (talkcontribs)

Sorry about the delay in responding, been a hectic week and I wanted to make sure I could read everything in one go lest I miss or misremember anything.

I appreciate you keeping me apprised but its ultimately its unnecessary - you made your edits in good faith, you didn't needlessly blank good information, and added more - the edits speak for themselves. I do want to say I'm very glad you took the time to go through and organize it all, it is massive improvement over what it was. You're absolutely right that it used to be a mess - it mixed up sources, it conflicted with other information and itself, and was outdated in parts. I really appreciate you putting the effort in.

That said, I am always happy to help if you need anything though. Always feel free to HMU if you need a hand. So regarding some of the things you mentioned:

Re: Moderation permission. Permission for all those edits should already have passed through when or not long after you posted this, and I've quickly checked & approved all the pending ones you put in today. You also shouldn't have issues waiting for moderation from now on either.

Re: Medical Surgery Success Chance, what more do you want to add beyond whats already tagged for addition via the recode tag? Just an equation with the sight and manipulation percent? (also the stub tag can probably also be resolved now because of what you've already finished) Feel free to be bold on this, I'm just curious about what you intend and whether I can help, not requiring information to grant permission.

Re: Operations vs Surgery, afaict the closest thing to a differentiation might be the surgeries have a risk of failure, while operations are the hypernym - including surgeries but also everything else, but even there the game is not consistent. Given this lack of consistency I'm happy for everything to be placed under Operations and "Operations (Surgery)" to be changed to "Operations". A line that mentions that sometimes things refer to them as surgery in the intro is all it really needs and would be cleaner than the double section title.

Some minor notes on the edits:

  1. The capitalization of the first letter is ignored when linking, so [[Doctoring]] and [[doctoring]] turn out as Doctoring and doctoring and go to the same place without a redirect. Capital letters elsewhere do matter though. Stat names being capitalized is annoying but its a standard I inherited rather than implemented, and unfortunately there are some things that depend on it. Another thing for the to-do list.
  2. Related, things added after links without a space are also included as part of the link. So instead of [[Carcinoma|carcinomas]] you can instead just go[[carcinoma]]s and get carcinomas. This and the first one might make it a just slightly easier when editing, so thought I'd point them out.
  3. STDT tables aren't necessary for the equation boxes, also have a look at Templates or other uses of them for color options. Theres a rough color coding - purple for psychic for example, but there are no hard and fast rules.
  4. The line specifically calling out inspirations not affecting the cap was added because its a common misconception - what you've written is still 100% accurate, but sometimes spelling it out for people aids clarity.

Lastly, the Skills section of Doctoring seems somewhat redundant and linking to it rather than the dedicated stat pages seems like you'll run into issues with factors again. Any plans for that? Is that included as part of your intended changes to Medical Surgery Success Chance? If not, thats OK, I just don't want to get in your way if I make changes. After the effort you've put in, I'm happy for you to take the lead on it.

Rab (talkcontribs)

Oh thanks so much for replying; I realise it's not necessary to constitute my edits, but given that there was an overall "strategy" to a series of edits (and the fact that I am a new user) I thought best to explain.

Operations vs. Surgery; so glad you said this. Absolutely, my first thought was to simply call it "Operations" but didn't have the guts to in case there was some hard and fast reason why a member of the edit team staunchly stuck by "Surgery". I'll call it operations as suggested, thank you. It certainly suits me as it's what the game calls it when clicking on the "Health" tab of a colonist. Also, indeed, the most appropriately suitable in-game hypernym† as pointed out.

1. I realise this should be the case regarding case-sensitivity. However when referring to "doctoring", my links went red in preview. I figured it was probably just rendered incorrectly (two links in the same section were precisely the same; one blue, one red). Maybe I should have just committed. But what with it being pre-moderated, I couldn't quickly double-check if it was OK once published. Still trying to prove myself I didn't want my first edits to potentially contain dopey-looking dead links. I've got a bit more confidence with your kind response now, plus as you state I should now be automoderated... (thank you) so if the worst does happen I can sneak back and make a re-edit if the link is genuinely dead. Point noted for future; any resulting weird aliases I notice I've put in I'll go back and correct.

2. Ok that I didn't know! Thanks for setting me straight.

3. I'll revisit and put them in as a wikitable again; taking Nutrition and Doctoring as examples they do that. I was actually under the misapprehension that wikitable wasn't used. NB. I did originally look for the "math" template (I think that's the one; the Wikipedia template for LaTeX) but that didn't seem to work. I kind of expected some kind of serif font based template for equations.

3a. Regarding colours I did have a detailed look through and indeed concluded it was a tad inconsistent; I concluded for that reason to go with grey as some other pages did so to be safe. (I noted Doctoring was red... it didn't "feel" very medical!) But thanks for pointing it out... I'll have a look at revisiting and putting in appropriate colours, thank you.

3b. Just on the subject of equations I wondered where most of this stuff is figured out. I tried to stick primarily to what was there already; refactoring and simplifying the pseudocode and suchlike, then trying out the resulting equations in-game. But do we ordinarily do something to come up with these equations in the first place? Has someone decompiled the IL and figured out what the precise equations are?

4. Ah - yes I had a note to put that back in when I was juggling everything around. I actually thought it was such a good point that I went looking for a good tip box template. My conclusion was that I couldn't see anything used across the site other than the "meta-note" (i.e. "Edit me for this reason") notices, so decided not to use. And then forgot about it. So let me get on to putting that back in... superlative attention to detail thank you.

Re Skills in Doctoring becoming redundant - indeed I did recognise that this seems to be increasingly the case the more other appropriate places are fleshed out. You pointing it gives a lot more confidence in it making it a overall goal. I can totally have a look at doing that. I've already started bulking out Medical Surgery Success Chance and it could be the natural place for some of this to be anyway. I might have to think about XP gain and suchlike and where that should live, but totally doable I think. So glad we're on the same page.

† Completely irrelevant note regarding nomenclature of surgery "things" and forming hypernyms. I've coincidentally spent hours in meetings with hospital directors across the UK, working with the NHS (UK National Health Service) on software UI design and nomenclature (I know, exciting career choices there). The most superordinate hypernym is "procedure". This captures any kind of work performed by surgeons, including diagnostic procedures which aren't strictly classified as an "operation". In fact if you require health insurance pre-clearance in a Western country, you might know already that you're likely to be asked for the ICD-10 "procedure code". But that said it of course makes no sense to use nomenclature which the game itself doesn't use, however correct it may be in real life.

Harakoni (talkcontribs)

3a. Haha, I didn't choose the color, but red on white for doctoring always made sense to me - its the classic medkit colors!

3b. Equations, processes, and other info around the wiki have been taken from a variety of places. Some are experimental (which isn't always accurate and tend to be couched in language or noted as such - most get replaced), some are from the in-game documentation (which isn't accurate either), and others are from looking through the .xmls and the code. Rimworld has a large part of itself in .xml form where its pretty easy to read - most of the time I fill in the infobox for something, its by taking the relevant info from the .xml for it.

Something like dnspy or ilspy is necessary to read the C# that makes up the majority of the rest of the game, though. That is also done (for example Rest, Tolerance, and Raid points) but because its somewhat technical and can be very involved finding the relevant part, tracking down every branching part, and resolving it into real effect, its not always done. Its not that it shouldn't be done, its just that its a lot of work, and other things tend to get priority over it because more can be done elsewhere for less editor time and a lot of editors don't have the expertise required.

Anyway, I'll leave you to it. If this topic is closed, then you can close it with the ... in the top right hand corner. You're also welcome to leave it open or reopen if you want the option to chat later. I'm also on the Discord fairly often, if you post in #wiki-suggestions I'll see it.

Reply to "Surgical operations/success rate"