[1.0] The Many Mods Of Mehni [Updated "daily!"]

Started by Mehni, September 26, 2017, 03:49:12 PM

Previous topic - Next topic

sirgzu

First of all your hauling mod is one the best QoL improvement I've seen in a long time ;)
I noticed that only humans seem affected though. I am playing with a few of Xen's races and they don't use their inventory for hauling. Not sure where the problem lies but I thought I'd report it anyway... Orassans do the improved hauling correctly though so that could be a good indicator of what's wrong.

Kori


Mehni

Quote from: sirgzu on February 11, 2018, 09:16:48 AM
I am playing with a few of Xen's races and they don't use their inventory for hauling. Orassans do the improved hauling correctly though so that could be a good indicator of what's wrong.

Sounds like Xen doesn't inherit from BasePawn but implements his own Abstract. Nothing I can do about that, sorry.

sirgzu

Quote from: Mehni on February 12, 2018, 02:53:11 AM
Quote from: sirgzu on February 11, 2018, 09:16:48 AM
I am playing with a few of Xen's races and they don't use their inventory for hauling. Orassans do the improved hauling correctly though so that could be a good indicator of what's wrong.

Sounds like Xen doesn't inherit from BasePawn but implements his own Abstract. Nothing I can do about that, sorry.

But you just did :) thanks for shedding some light on the issue.
I just noticed a few of the items he added as well are a little too OP so I might give beastmantribe a go instead. Do you know if these ones work?

Mehni

Assuming the A18 dropbox linked in the Steam page is the most up to date one, not without a minor edit.

If you want to play with it, delete Defs\Alien Race\BasePawn.xml and you're good to go. Their inheritance is good, they just made the grave mistake of including an outdated version of the vanilla BasePawn.

That's right, the author of Beast Man Tribes went and included an outdated vanilla BasePawn in their mod. Depending on load order, that'll overwrite the BasePawn for all other animal and race mods - even Core. That mod might disable Inventory-based hauling for all pawns. It'll also break the combat log. I've sent the author a DM on Discord. Let's hope they remove the file from their release.

Harry_Dicks

Quote from: sirgzu on February 12, 2018, 06:40:34 AM
I just noticed a few of the items he added as well are a little too OP so I might give beastmantribe a go instead. Do you know if these ones work?

I haven't checked out anything internally in PU&H, but this made me wonder. Mehni, did you modify something in basePawn to allow them these extra inventory "slots"? And if so, is that what would make it so that races added in from other mods are unable to take advantage of PU&H, because they did not inherit from basePawn, which is where I'm assuming you've injected these new modifications?

Mehni

Yup. That's why I'm such a stickler lately for proper inheritance.

I have a simple xpath targeting BasePawn to add a comp. I store what pawns pick up in this comp. This method came highly recommended by the most experienced modders, and it's a good solution. It's on a per-pawn basis, so there's no slow masterlist to keep track off. It's fast, it's compatible, it works.

Except when it doesn't, because Alien Races makes it almost too easy to make a race mod ;)

Harry_Dicks

Quote from: Mehni on February 12, 2018, 07:47:35 AM
That's right, the author of Beast Man Tribes went and included an outdated vanilla BasePawn in their mod. Depending on load order, that'll overwrite the BasePawn for all other animal and race mods - even Core. That mod might disable Inventory-based hauling for all pawns. It'll also break the combat log. I've sent the author a DM on Discord. Let's hope they remove the file from their release.

So I've been going through some of my mods defs randomly, and I won't call anyone out, but I am a bit surprised at some of the authors that do this, that I would have assumed did not. I was wondering, do you think some authors do this, so that way if there was a situation like this to occur in someone's load order, this can remedy the situation. Let me try to explain.

Here is an example load order:
Core
Mod which redefines basepawn and borks it for everyone else
Mod which requires basepawn to work properly, so they have it redefined in this mod, BUT they have it redefined exactly like the Core does, and they ONLY do this as a precaution, in case another mod loaded before them redefines something it needs.

Would something like this be possible? Could the author of the second mod include something like this in their own mod, to prevent anyone else's mod from messing with something that their mod depends on? I fully understand in an ideal world no mods will overwrite any core defs, but we know that isn't the case.

I guess what it comes down to, is that I was very curious why a handful of the mods that I randomly chose to browse through, would have these core defs in their xml (not sure if they are altered, or just redefined like core). I know that earlier, I think I read it was for A16 and back, that you did not have inheritance from core to mods, so that all mods if they used anything from vanilla, they had to have the entire string of defs going all the way back through all of the parent nodes. This had to be done for every single mod. That sounds like it's a lot of extra work for the computer.

Finally, when mods redefine core defs within their xmls, but nothing is modified, does this add on extra load from the program? I know that a few of these are insignificant, but I was curious if you had for example, every single one of your mods in the old fashion, where they could not inherit any defs from core. Would running the game with a ton of mods like this be noticeably slower than the same game but with all of it's mods xml defs properly made?

PS-I was having an issue maybe 5-6 weeks ago where cuproPanda's mods either Zen Garden or Glowstones kept "looking like" they were giving me errors in the error log on start up. This was because I had those two mods near the bottom of my list. The issue was, there was a mod loaded earlier than them, and it redefined something that cupro's mods required to work properly. Even though this culprit mod did a big no-no, it still worked properly itself, BUT, it will make every single mod loaded AFTER it look like THEY are the ones messing up, but really, it's the one that was loaded first and redefined core defs that others need.

I guess I just wanted to vent a little about this. Because I have spent more hours than I would like to admit trying to hunt down these mystery bugs that have been giving me headaches for WAY longer than they should have. One mod I had like this was buggy for a few weeks! But I would have never found out, because all I've been doing recently is just tinkering with my mod list, and only having little 5 minute test games. It wouldn't be until I was way further down the road, maybe middle or even late game, when I would finally get around to using the items from a broken mod that I would then discover there was an issue.

So what I've had to do sometimes, is play this stupid "divide by half" game with removing half of the mods from my list at once, and seeing if I can keep reproducing the bug. Then you just try to narrow it down from there. But it sucks when you're at almost 200 mods, and my load time is about 3.5 minutes if I had to guess. Going through 15-20 restarts can end up taking awhile, especially if you aren't getting an error for the bug upon start up to the main menu. Maybe I've got to also go set up a specific group of pawns through Prepare Carefully, or I need to start a game and build certain things or progress to a certain point.

Having to do all that crap every single restart just to reproduce a specific bug because you're trying to track down the mystery culprit among a list of 200 can end up being very boring and monotonous work. It makes it so that when you FINALLY find that bug that has been plaguing you forever, you can't help but be a little upset, especially if you've had to spend a considerable amount of time trying to track down just this one issue. And sometimes you don't even know you have an issue until randomly later on, and you don't even know how to reproduce the bug! Uuuuughh. Rambling..

Mehni

Quote from: Harry_Dicks on February 12, 2018, 08:08:04 AM
Here is an example load order:
Core
Mod which redefines basepawn and borks it for everyone else
Mod which requires basepawn to work properly, so they have it redefined in this mod, BUT they have it redefined exactly like the Core does, and they ONLY do this as a precaution, in case another mod loaded before them redefines something it needs.

Would something like this be possible? Could the author of the second mod include something like this in their own mod, to prevent anyone else's mod from messing with something that their mod depends on? I fully understand in an ideal world no mods will overwrite any core defs, but we know that isn't the case.

Nope. Now you've got two mods that overwrite the BasePawn, and anything that depends on it could be pulling from who knows where. If you're going to use your own Abstract, give it its own unique name.


Quote
I guess what it comes down to, is that I was very curious why a handful of the mods that I randomly chose to browse through, would have these core defs in their xml (not sure if they are altered, or just redefined like core).
Inexperience I guess.

Quote[load, performance, optimisation]
Probably, but I couldn't tell you by how much.

You also touched on pretty much exactly why it's so bad when mods needlessly redefine vanilla Bases. It's nearly impossible to diagnose issues.

Mehni

In other news, Combat Extended functionality for Pick Up and Haul is in testing.

Harry_Dicks

Quote from: Mehni on February 12, 2018, 06:08:44 PM
Nope. Now you've got two mods that overwrite the BasePawn, and anything that depends on it could be pulling from who knows where. If you're going to use your own Abstract, give it its own unique name.

Of course, but was curious if this was how it works. I would think the mod loaded last would have the final overwrite, so that it would at least be possible, if not optimal, to just choose to redefine core defs in your mod, to prevent the possibility of your mods ever being messed up from a different mod further up the load order.

Not a question of if you should or shouldn't, I'm just a curious boy who wonders about silly stuff, and I am still learning a lot :)

Kori

Quote from: Mehni on February 12, 2018, 06:09:17 PM
In other news, Combat Extended functionality for Pick Up and Haul is in testing.

Can't wait to try it out! :)

Dingo

For what it's worth, there used to be a bug and consequently a lot of misunderstanding regarding abstract bases in RimWorld's XML. I believe it was fixed for A17/B18 but all of this conundrum might be directly or indirectly related.

Harry_Dicks

Quote from: Dingo on February 13, 2018, 10:17:02 AM
For what it's worth, there used to be a bug and consequently a lot of misunderstanding regarding abstract bases in RimWorld's XML. I believe it was fixed for A17/B18 but all of this conundrum might be directly or indirectly related.

Sounds like it could make sense to me. I've only just started messing around with mods back in December, and played RimWorld for a few weeks before that. So all of my learning and experience has only been with B18 and dealing with the current model. I suppose it makes it a lot easier for me that I didn't have to learn the old way, and then there's changes and I have to learn a new way.

Mehni

Shotgunfrenzy made a cool new mod, and I helped with the C# side of things.



Call traders to your location with the Orbital Trader Transponder!

Steam / Ludeon