Zainstaluj Steam
zaloguj się
|
język
简体中文 (chiński uproszczony)
繁體中文 (chiński tradycyjny)
日本語 (japoński)
한국어 (koreański)
ไทย (tajski)
български (bułgarski)
Čeština (czeski)
Dansk (duński)
Deutsch (niemiecki)
English (angielski)
Español – España (hiszpański)
Español – Latinoamérica (hiszpański latynoamerykański)
Ελληνικά (grecki)
Français (francuski)
Italiano (włoski)
Bahasa Indonesia (indonezyjski)
Magyar (węgierski)
Nederlands (niderlandzki)
Norsk (norweski)
Português (portugalski – Portugalia)
Português – Brasil (portugalski brazylijski)
Română (rumuński)
Русский (rosyjski)
Suomi (fiński)
Svenska (szwedzki)
Türkçe (turecki)
Tiếng Việt (wietnamski)
Українська (ukraiński)
Zgłoś problem z tłumaczeniem
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:
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.
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.
"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.
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:
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.
Once again, thank you for the feedback!