User talk:Cheldra

Wow, you have done a ton. A few things:

Not everything needs to be in the infobox. The infoboxes are already getting too big as is and some of it isn't necessary. If its not a something that will need to be quickly referenced or something that needs automatic stuff done to it, then it likely doesn't need to be in there. For example, the slabs do show unique behavior (with properties of floors and buildings at the same time), but the edifice line and property is completely obscure for the reader, isn't used anywhere else, and could be replaced with information in the summary and maybe a general page about how similar things work.

leavesresourceswhendestroyed = false is redundant when you can override destroy yield with "none" or some equivalent which maintains clarity for editors that don't rely on the xmls. deconstructyieldfraction is arguably similar, but it is convenient. Manual settings are necessary as while technically things like the Infinite Chemreactor have cost lists that are used to generate the their yields, having that cost list defined would just be confusing to editors and readers.

On the opposite note, flammability is one of those oft-referenced stats, and shouldn't be removed from building pages where its 0. A reader can't tell the difference between it not being present because its meant to be 0 flammability and the wiki just being incomplete.

Light radius - lights have a defined color as well as the radius, the color of the light affects the brightness - standing lamps and red standing lamps both have a light radius of 12, but 9 tiles over the plain lamp is still considered "lit", while its only 7 for the red. Light radius itself is not a particularly useful value both because of this, and because its not super clear to the reader how that translates into "lit" area. If we could calculate the "lit radius" automatically from the glowRadius and glowColor then that would be a useful inclusion, but not really otherwise.

If you're creating a new page from current data, feel free to tag it as verified for the current version. Everything on the page has to be current after all.

Facilities and research requirements can't be set the way you have set them, but I think maybe they should be. I'll set it up tomorrow.

Lastly, placeable, rotateable, blocks wind, minifiable etc perhaps they should be standardized to be boolean properties rather than text as they are now? Pages with them already defined will have to be changed over to the right format before the property pages themselves are updated, but it might make things clearer and easier.

1) That's a good point, I probably was a bit overzealous in adding properties. BTW, the slabs aren't the only non-edifices, that's a property also shared by conduits, burnout shields, and steam geysers. But regardless, you're right in that it's not worth adding to the infobox. A page on non-edifices makes sense, I'll get around to it at some point.

2) You raise a good point in editability for those not using the xmls. I'll switch to manual deconstruct and destroy lists where it's abormal or not buildable.

3) 100% agree on flammability - I hadn't realised initially that the default was 0, but switched to using default of 0 part way through. I think only a few lost it, and I'll re-do them soon.

4) I've done a little investigating of the source code just now, and I think I have a formula that accurately predicts glow from glowRadius, glowColor and distance (it matches the exact %s I'm seeing in-game). I'll work on getting it in a usable format for the wiki.

r = glowRadius
d = distance + 1
c = sum(glowColors)

a = 1 - d/r
b = 1/(d*d)
f = a + (b-a)*0.4

glow = min(0.5, f*c/3/255*3.6)

5) Sure thing

6) Please do, you seem much more adept than me at handling strings in the wiki

7) Agreed, that makes sense

Thank you for adding the images btw :)

1) I meant its not called anywhere. but no matter, we'll take ti out of the infobox once we have the replacement/s we discussed set up, just so we don't lose track of any in the meantime.

3) Oh awesome. can we implement Template:Lit Radius in the info box/elsewhere? Is it ready for roll out?

6) Done. Might change over stuff tags to work like that too (it makes calling it much easier) but it'll have to wait until I can hunt down everything that uses stuff tags and update them all at once so nothing breaks.

Wrt the Images. you're very welcome. Lemme know if theres anything specific you need. Also thanks for taking constructive criticism so well/how it was intended. You're doing so much that these "issues" are pretty small in comparison to your contributions but I appreciate you being magnanimous about it all the same.

Template:Lit Radius is indeed ready for rollout. I'm working on implementing it now :)

I've been kind of assuming placeable meant that the player could build it, but some things like Mech node have it as true. Is that not what it's meant to be?

BTW thank you for all the feedback

My understanding is placeable is anything that can be either constructed or moved by the player - basically if there a way for a player to place the blueprint. So the mech node is placeable because you can minify it and move it, a nutrient paste dispenser is placeable because its constructable, but an ancient car isn't because it does neither. But I could be wrong.

Also, wrt lit radius, great work!

I just finished updating them all. Each verb needs to be defined separately.

See alpaca for comparison.

Also |page verified for version requires the whole page to be verified, not just the infobox

Sorry about that, I hadn't realised.

I think I see how the attack types are meant to be set out now, with each of them that have multiple verbs getting their own attack. How does that work with the chance factors? If an attack is split up its verbs, do we halve the chance factor?

Also, sorry about the |page verified, I'll revert them now.

Its ok I just spent a while going through each animal and panicked at having to ether revert your edits or do it all over again. Wrt the chance factor, it'd be applied to both verbs, though I don't think any pawn actually has a chance factor applied to a body part with two capacities. At least not afai remember.

Thanks for understanding, it just needs to define each verb so it can link to damage type correctly and so that templates can work with the data properly inc. Template: True Melee DPS Calculator and some others that are coming.

Huh, so when there are two capacities/verbs for a pawn's attack, is it actually two separate attacks, each of which getting an equal weight to an attack that only has one capacity/verb? It's not that after that attack is selected, one of the two capacities/verbs are chosen at random? This isn't an area I've investigated much, so I'm a bit lost.

edit: I did some poking around, and that is indeed how it works. I'll change my infobox updater script to account for it. Good job on the Melee DPS Calculator btw, it's looking really good :)

I have a question on the topic: for the attack[n]part fields of the infoboxes. Should they take from the xml's "label" tag (e.g. claws, right hoof, left fist), or the "linkedBodyPartsGroup" tag (e.g. Feet, FrontRightLeg, LeftHand)? It seems to be a mixture at the moment - Alpaca has linkedBodyPartsGroup, Monkey has label.

Another thing I inherited. Atm theres a soft standard of body part made human readable and so where I've been adding to it, I've been mostly following that. But tbh it probably makes more sense to be the label and would be easier to read. I don't think we're ever going to need to make the body parts automatically reference and humans can work out that "claws" are on the feet. If you want to update it, or follow one standard over another, please feel free.

Bothering you again. My math implies that cows > horses because of the milk production, your edits says otherwise. Might be a mistake (by either of us) or different assumptions. Unsure. Care to take a look?

Also, nutritional efficiency is important when you're feeding them/have limited pen space but when they can graze to their hearts content then straight nutritional output (in milk/eggs/male offspring meat [if only new females are kept]/total offspring meat [if herd size = constant]) is the more important stat. Likely should be added to analyses. I can get around to that myself if you prefer to leave it though.

I've had a look at your maths - our numbers agree for horses (and chickens which I checked using your formulas), but disagree on cows. There are two differences between the way we've calculated it:

• You've done meat/(cons - milk), whereas I did (meat + milk)/cons.
• You've done everything in per offspring, whereas I've done everything in per day. I don't think this should matter, as it cancels out in the division.

I'm still trying to wrap my head around which formula is correct - both make sense intuitively.

I think nutritional efficiency still matters most when choosing what animal to use, since you can always expand the herd size until you reach the limit of the pen, but you're right in that the analyses should include something like the number of colonists that each animal can sustain.

I've had more of a think over the problem, and meat/(cons - milk) and (meat + milk)/cons are fundamentally different formulas. I would say that if you define nutritional efficiency as nutrition_out/nutrition_in, then the (meat + milk)/cons that I did is correct. It's also a more useful number, as it can tell you exactly how much nutrition your getting out in ingredients for the meat component of meals for each nutrition in. If the cows could drink their own milk, then meat/(cons - milk) might be more useful.

Wrt to herd size, thats not necessarily correct because 1) herd growing takes a non-negligible amount of time 2) not everyone has PCs capable of arbitrary herd sizes 3) there are different strategies that don't really care about nutritional efficiency. I'm not saying nut eff isn't useful, because it clearly is, I'm just saying that both values are.

I'll have another look at the math when I get more time. I think you're right though.

Khitrir, one of the users on the Unofficial Rimworld Discord, asked if I could ask you to take a look at the wiki suggestions channel there. Something about user Bork discovering the gestation period was wrong. Both have helped out with the wiki in the past, so I thought it fair to pass it along.

Invite here: https://discord.com/invite/UTaMDWc

Thank you for passing it on to me! From the screenshot shared, it looks like the ages listed in the def files (and in the info boxes here) is actually age from the start of gestation. Since the age given in the ingame info windows is age from birth, should we just subtract gestation from ages everywhere in the wiki via infobox_main?

Oh. Thats weird. Why count from gestation? Thats unnecessarily confusing.

Keep the input value the same so it can be copied straight from the XMLs but either the title in the infobox should clarify that its from gestation with hover text (like manhunter chance does for example), or it should be displayed as since birth, or maybe best still displayed like real grow time with both values presented and explanation on the difference

I can implement it later, or you can if you'd like to.

I'll do it tonight I guess. I also need to check if egg-layers are affected the same way.

So I did some investigating, and the weirdness with the ages doesn't actually have anything to do with gestation times. The real adult age is actually (1-1/e)×adult_age, and (1-1/e^(juvenile_age/adult_age))×adult_age for real juvenile age. Check the discord channel if you want to see why.

I've also included an explanation in Template:Actual Age

I love the animal efficiency stuff you've been doing!

Does your animal efficiency analysis factor in the 50% bonus meat from slaughtering tame animals? It seems like that would weight things more heavily towards meat animals rather than milk or egg ones. Apologies if that's already included, I haven't actually double-checked in-game :)

Yep, that's included. The way it's coded in the game is actually a 66% penalty to Meat Amount for hunted animals.

Not sure why you felt the need to change it from roam interval, but if you are, please delete the unnecessary definitions in the infoboxes you're updating. Most of them had |roam interval defined. I'm unsure if the property was used anywhere but thats also worth checking.

Yeah, sorry, that was a mistake. I checked a few of them and didn't see roam interval set, so thought it wasn't used at all and that I might as well change it to be the same style as nuzzle.

The best way to check is to look at the property page, and if it's not already created, just create it blank if necessary.

It won't work now because the infobox template no longer sets the property and the pages will already have started updating, but for the future.

Got it, thanks.

Also is it hours or days. Infobox says days, stat name says hours.

It's in days.

edit: fixed it

Can you do me a favor and chuck a legend on the graphs on Property:Leather Yield and Property:Meat Yield. Sorry to keep bothering you - you're just doing so much so there's a lot to discuss.

Done it :)

Thank you, you're doing amazing work

Just wanted to say that all the work you've been doing on updating the animal stats has been noticed and is appreciated

If need any help with anything, I'm a mod around here so don't hesitate to ask!

Thank you! If possible, I'd like to add a few new animal stats such as juvenile age and expected litter size, so I might ask for your help when it comes to that.

Sure! Atm there is Property:Offspring Per Birth which is set using "|offspring =" in the infobox which shows the range of litter sizes (e.g. 1-3), but if you're keen to add/update it to include a specific average then that can absolutely be arranged. I do know that there is a size curve for each litter, so implemenation can be done a few ways. Flat inputting a number for the average (e.g. |avg offspring = 1.5) is easy and will take like 30 seconds, but having the infobox calculate the average itself from the curve's points is much more involved and will take a bit of work when I'm free to do it properly.

Just lemme know what needs to be changed/how you want it and I can see about implementing it.

Same goes for juvenile age if that wasn't clear - lemme know how you want it implemented and I'll see about it when I can

I've written a script to calculate the expected litter size from the size curve, so a flat input would be great. In total, all of the fields that I would ideally like added would be:

- expected_litter_size (flat)
- juvenile_age (flat)
- juvenile_hunger = 0.75*real_hunger_rate
- juvenile_size = 0.5*body_size
- juvenile_meat = 140*juvenile_size (flat input for values under 40)
- juvenile_leather = 40*juvenile_size (flat input for values under 40)
- baby_hunger = 0.4*real_hunger_rate
- baby_size = 0.2*body_size, other than birds in which case 0.1*body_size
- baby_meat = 140*baby_size (flat input for values under 40)
- baby_leather = 40*baby_size (flat input for values under 40)

I'm not sure if all of these should be displayed in the infobox, but they would be useful for a ranching efficiency table that I would like to do.

We can set properties even if they're not displayed, but in cases like juvenile hunger you could also just use do the calculation at the point of use, e.g. having the ranching efficiency table do the calculation using the existing property. Also do you have specific examples of when the under 40 values are used?

Unfortuantely I have to head off for now, but feel free to keep posting any specifics and anything else you think of. In the meantime, avg litter size implemented as "|avg offspring =" and Property:Average Offspring Per Birth for consistency reasons. Will display in brackets next to the litter size range currently in the infobox e.g. = 1-2 (1.5 avg).

Thank you for implementing the average offspring! I'll get to work filling it right away.

Meat and leather yield all go through a post processing curve with points (0,0), (5,14), (40,40), (100000,100000) defined in Data/Core/Defs/Stats/Stats_Pawns_General.xml, which effectively increases values below 40. For example, baby ducks would have a meat yield of 0.03*140 = 4, but the post-process curve increases it to 12.

I don't know how possible it would be to implement the curve within the wiki, but if it is straightforward, here's my python function in case it's helpful:

def post_process_curve(pre, x=[0, 5, 40, 10000], y=[0, 14, 40, 10000]):
	for i in range(len(x)):
		if pre < x[i]:
			gradient =  (y[i] - y[i - 1])/(x[i] - x[i - 1])
			progress = pre - x[i - 1]
			return y[i - 1] + gradient*progress

Instead of {{#show:{{PAGENAME}}|?Daily Milk Average#}} you can also just use {{P|Daily Milk Average#}} - its basically the same method and either is perfectly fine, you just might find it more convenient when editing.

Thank you, that's good to know :)

Changes to template were acceptable.

I hope you don't mind that I made some edits to your template, essentially to add some functionality to replicate some what the old manual table had but the template didn't (not that that table wasn't in need of updating/automating). Specifically, it now supports eggs and I split nutrition/day off from product/day. While information dense, having the production and nutrition as the same number isn't the most clear. Splitting it makes it easier to read, easier to sort food-producing animals from non, prevents confusion between edible and non-edible production numbers, and stops readers having to go through another step to work out actual production quantity.

I tried to match the style you used as best as possible, so hopefully it'll be clear for any future changes you want to make/maintenance etc.

If you disagree with the changes, I'm happy to discuss them, or you can even revert them if you like.

Thank you, that's a good change and does indeed make things clearer.