Thank you for the feedback and for providing the mods with which the current one has some compatibility issues. I'll investigate the issue and report back as soon as possible.

Thank you for waiting while I was investigating this issue.

In the next v0.19.0 release, I will try to improve the compatibility of the current mod regarding this issue.

However, even though I still do consider that this mod has a potential issue, I believe the core reason why the crashes keep happening has nothing to do with this one.

The main issue behind crashes in both mods are many missing nil checks. This especially important when dealing with threads due to their nature as you should never trust the returned values from external functions. Therefore, to fix most crashes the authors of the mentioned mods should add these checks, particularly when dealing with the PlayerActionPicker:DoGetMouseActions() function. The same logic applies to the Inventory:GetEquippedItem() function regarding the backpack-related crashes. I didn't investigate the Fishing Rod ones but I'm pretty sure that the root cause is also related to the same logic.

For example, considering your mod v1.23:

1. To fix the crash during cooking you should wrap at least the lines 175-178 and 222-225 with the E ~= nil if statement in the modmain.lua
   
   
2. To fix the crash during seasoning as Warly you should wrap at least the lines 330-333 with the E ~= nil if statement in the modmain.lua
   
   
3. To fix the backpack-related crashes during cooking you should wrap at least the lines 98-102, 111-118, 250-254 and 263-270 with the B ~= nil if statement in the modmain.lua

I do recommend applying the mentioned changes. However, even if the authors of the mentioned mods decide not to apply any fixes on their side, the next v0.19.0 from mine should improve the compatibility regarding this issue.

Moreover, I also do strongly recommend to avoid using global input handlers at any cost and instead hook into an existing input-related class to achieve the same. This will not only allow you to respect the loading priority but give you the flexibility to resolve any potential compatibility issue in the future as a last resort.

Regarding your notice about local/global functions in the KeepFollowing component.

Some functions are global intentionally to allow other developers to mess around with the current mod externally in case they would like to reuse some of the functionality, control the behaviour in some edge cases or hook into some of the functions.

Nevertheless, I do recommend making most functions local to avoid polluting the global environment unless you follow the same logic and decide to expose them on purpose.

I agree that the autocooking mods are not carefully put together. Almost all of it was not written by me (not that I would know how to do it myself). I've just been slowly teaching myself and making little fixes as I go.

"Moreover, I also do strongly recommend to avoid using global input handlers at any cost and instead hook into an existing input-related class to achieve the same. This will not only allow you to respect the loading priority but give you the flexibility to resolve any potential compatibility issue in the future as a last resort."

Is this the same as the idea of copying the global version of a function and rewriting your changes to it locally without effecting the global version? I read about that briefly but if you had a link that could point me down the right path I would definitely try to implement those kind of changes to make the fork more robust.

Nguyên văn bởi Fuzzy Waffle:

Is this the same as the idea of copying the global version of a function and rewriting your changes to it locally without effecting the global version? I read about that briefly but if you had a link that could point me down the right path I would definitely try to implement those kind of changes to make the fork more robust.

If I have understood you correctly then yes, that's pretty much it. Unfortunately, I didn't investigate the code of both mods much so I can't say anything for sure that moving from global input handlers to the hooking solution will be painless in this situation. In my experience, such an important change always follows with some headache.

As I don't use any references on how to write Don't Starve Together mods and simply apply my overall engineering experience, I can't provide any link(s) in the right directions. Since you are trying to make your mod more robust I would start from something simpler instead of jumping straight into hooking to avoid any issues that will come along.

For example, in general, always a good idea to:

1. Add separate debug mode to improve maintenance.
   
   
2. Move the core functionality into separate classes (components/widgets) to increase flexibility and improve maintenance.
   
   
3. Optimize threads and their lifecycle to improve performance.
   
   
4. Split the current solution into smaller functions to avoid duplicated code and improve maintenance.

The suggestions above apply to programming in general and not only to the Don't Starve Together mod development so most likely you already know them. However, it won't hurt anyone if I repeat them.

Moreover, If you happen to have a public repository to your mod somewhere like GitHub[github.com] then you can leave your URL here as this would significantly simplify the process of communicating. Otherwise, I would strongly recommend creating one to host all your code there.

The v0.19.0 has been successfully released from my side which includes the compatibility improvements related to the current issue.

Once again, thank you for the feedback!