Store Page
RimWorld
All Discussions Screenshots Artwork Broadcasts Videos Workshop News Guides Reviews

RimWorld

Store Page
RimWorld >  Workshop > Adventurer's Workshop > Expanded Woodworking > Discussions
Expanded Woodworking
Description Discussions3 Comments557 Change Notes
This topic has been locked
Triss 5 Dec, 2019 @ 8:48pm
Overwriting vanilla bases, please fix
Greetings sir or ma'am or however you prefer to be addressed, it seems your mod is currently overwriting {BuildingBase, Benchbase}, and it's causing issues for other mods and the people who use both those and yours. I'd like to request that this be changed so that things don't break quuuite as often as they tend to. An explanation of what overwriting bases is and a different way to do inheritance is below. I hope you have a good rest of your day/night/eternal twilight on a stationary planetoid.

Explanation courtesy of Jamaican Castle on the main Rimworld Discord-

"Well, when you set ParentName="whatever" in the XML for a def, it goes for a def with Name="whatever" and puts all of the parent's tags in the child, unless the child overwrites them by having the same tags.
In the distant past, Rimworld wouldn't look outside of your own mod package for Name="whatever", so if there was a standard parent for a type of def - usually called a "base" because most of the vanilla ones have Base somewhere in their names - you'd have to define your own. For instance, vanilla pawns all inherit (directly or through an intermediary) from BasePawn. You couldn't do the same because it wouldn't find it, so many modders defined their own BasePawn.

Nowadays (since, I think, about A17) it correctly finds the named parent wherever it is, so you can inherit directly from vanilla bases. That's good. But it also means that if your mod defines a base with the same name as vanilla, it overwrites the vanilla one, and whatever changes you made propagate to many other things and generally cause problems.
Compounding the problem is that a lot of mods that do overwrite vanilla bases do so because they haven't been updated (or that part of them hasn't been updated) in a long time, so they tend to overwrite with outdated versions of the base.

If you're going to inherit from a vanilla base, just do so. Don't add a definition for that base. For example if I have one pawn, I can just put ParentName="BasePawn" and have done with it. I don't need to (and shouldn't) write my own BasePawn.
If you want to have your own base, name it something different from vanilla, like MyModBasePawn or somesuch."
< >
Showing 1-8 of 8 comments
Adventurer  [developer] 16 Dec, 2019 @ 9:18pm 
The vanilla bases that I include (BuildingBase and BenchBase) are exact copies of the most recent vanilla def. The only reason I include them and have included them is because some mods do overwrite them with changes or are outdated, which can occasionally cause problems. Essentially, I do it to make my life easier in preventing bug reports related to these bases, but I will consider removing such next update. I do agree it is better to inherit from a vanilla base than overwrite it.
#1
Triss 19 Dec, 2019 @ 1:50am 
Doesn't that make it so that other mods that aren't patching aggressively, but still doing something different than vanilla, end up being overwritten? Like I see you not wanting to have to deal with other peoples silly coding, fair enough, but I feel like it's not the best answer? Unno.
#2
Adventurer  [developer] 19 Dec, 2019 @ 9:33pm 
I agree, it is not. If other mods add onto the base definition through overwriting, my mod would overwrite them if they are loaded before, but not if loaded after. It was a fix to a problem that occurred much more often in A16 through B19. Expanded Woodworking used to in A16/A17 overwrite more base defs, but I have removed some as I transitioned over to predominately using patching when not introducing explicitly new defs. These two base defs are last remaining holdouts because I had occasionally ran into outdated versions of them in A17 through B19 while creating compatibility for other mods. If you think (and you're probably right) that mod makers are overwriting the base definitions less or using up-to-date versions of them, I see little reason for me to continue including them.

It isn't so much about me wanting to include them, but that others keep these base definitions up-to-date if they need to include them, so that we can have better compatibility between mods. I agree it is better to inherit or patch them and I think it should be done more in place of overwriting. If it is potentially causing more issues with me including the vanilla base definitions then I will remove them.

Let me know what you think.
#3
Triss 19 Dec, 2019 @ 11:22pm 
I'm one of the troubleshooters over at the main RW discord, we've been kinda campaigning for mods to not do this anymore, it tends to cause other mods to break horribly or for them to kill each other. Your mod has had this happen a few times there.
So tbh I'd say yes, please swap over completely. If we see overwriting mods as noticed by Mehni's AllYourBase, we tend to tell people to drop them or swap to something that doesn't do that. It makes their modlists more stable as a general rule at this point.
Thanks for listening; and swapping as much as you have so far though. There are a few mods that only overwrite one or two things that people have kept in their lists just because of what they offer, pretty sure your mod has been one of those a few times as well. :)
#4
Adventurer  [developer] 19 Dec, 2019 @ 11:56pm 
Okay then. I'll remove it with the next update as long as I don't run into any problems with doing such.
#5
Triss 31 Dec, 2019 @ 11:35pm 
Ye, thankee much for that. Happy Rimming. ;)
#6
BlueTressym 1 Feb, 2020 @ 12:05pm 
Hiya. I'm of those those people who've kept this mod despite the overwriting thing because I love it! Just so you know... :)

Also, Trisscar has helped me a lot in dealing with bugs and mod issues on Discord.
#7
Triss 12 Feb, 2020 @ 10:34am 
*waves*
#8
< >
Showing 1-8 of 8 comments
Per page: 1530 50