Jump to content

Is there a way to detect if mod X is enabled?


mouse

Recommended Posts

yes, exist, search on forum for simplex/squeek posts

but imho its not good idea at all, at least not good idea to search by mod name, its can be changed.

i "detecting" other mods by specific functions/player properties or/and prefab name. Its more reliable.

Cross-mod integration. But Rincevvind makes good point tho, we could use better reflection method.

That's why I set a non-standard entry called "id" in my modinfos. For example, Up and Away's modinfo.lua has

id = "upandaway"
The id is meant as a constant unique identifier, unlike modinfo's name entry, which is a matter of user interface (and so should be regarded as mutable), and unlike the value of the variable "modname" in the mod's environment, which is the name of the mod's folder, which differs from workshop installations and "normal" installations (in the latter case, the folder can be renamed to whatever).

This is why the test in squeek's post checks for modinfo.id preferentially (well, it might have something to do with me being the one who wrote it). But, of course, checking for modinfo.id is only viable for mods who willingly adapt it, which mostly means... my mods. So the logical conclusion is you should check for my mods and ignore the rest :razz:.

But I really wish modinfo.id (or something equivalent) would be made mandatory. It's become an issue in DST, because now the modname variable (the mod folder's name) is being used as the mod's unique identifier for networking, which means your mod will break if it adds new actions* unless everyone on the server has the same mod folder name (so if someone downloaded it from the workshop, everyone must download it from the workshop). This is also why I've been hacking my modinfo.id in place of where the game uses modname.

* The issue isn't restricted to custom actions, this is just what the mod API supports for now. The issue will become larger as the API is extended.

Link to comment
Share on other sites

[read above]

 

It seems reasonable to use a solid ID for a mod in multiplayer, indeed.

 

I'd say the fancyname could work too, though, because a custom id would only be needed instead if the fancynames of two different mods were the same. That is a scenario just as likely as two different mods using the same modid.

Please keep in mind that I specificly acquit any opportunity to participate in DST beta.

 

I added the id to my IR-collection anyways, as it won't hurt more than it helps ;) (both of which are questionable)

Link to comment
Share on other sites

But I really wish modinfo.id (or something equivalent) would be made mandatory. It's become an issue in DST, because now the modname variable (the mod folder's name) is being used as the mod's unique identifier for networking, which means your mod will break if it adds new actions* unless everyone on the server has the same mod folder name (so if someone downloaded it from the workshop, everyone must download it from the workshop). This is also why I've been hacking my modinfo.id in place of where the game uses modname.

 

 

They... they are using directory names?? You're kidding, right, noone in his sane mind would use directory name... I can't even...

 

Oh for the love of the great harlot of Babylon...

 

EDIT: And now I see why I never noticed, the (public) function in componentactions has 4 arguments, the env injected one has 3 and last is dropped for env.modname... How much time would I waste fighting errors potentially caused by dropped last argument (e.g. calling the function from 2 different namespaces and require'ing componentactions in the other etc).

 

I'd say "please stop preemptively shooting us in the head so we don't shoot ourselves in the foot", but it's a lost cause (not aimed at anyone in this thread). 

 

 

It seems reasonable to use a solid ID for a mod in multiplayer, indeed.

 

I'd say the fancyname could work too, though, because a custom id would only be needed instead if the fancynames of two different mods were the same. That is a scenario just as likely as two different mods using the same modid.

 

It isn't, and there have been multiple cases in the past where name was same for different mods. From rpghud variants to different forks that you may want or may not want to distinguish, etc. And then there's the case of simply changing mod name to reflect some localization, which should have same ids for the detection case but don't have neither same dir (in steam case) nor name.

 

(Fancy)name is description string, nothing else, and it shouldn't be considered anything else. Yet sadly it has been the only semi reliable method... until they decided to chose even less reliable method as official one I suppose...

Link to comment
Share on other sites

They... they are using directory names?? You're kidding, right, noone in his sane mind would use directory name... I can't even...

 

Oh for the love of the great harlot of Babylon...

Well, the directory name is the only truly unique identifier at their disposal with the present state of the modding API. In singleplayer it was ideal, since then it does serve as a proper identifier for a mod, the problem was they carried that approach into multiplayer, where it certainly doesn't work as a UUID. The correct approach, as I see it, would be to extend the modinfo spec by requiring a field used as an UUID (and checking on load if no two enabled mods specify the same UUID, raising an error if that's the case); though it could be argued that in a multiplayer context even the fancy name would be a preferable approach...

 

EDIT: And now I see why I never noticed, the (public) function in componentactions has 4 arguments, the env injected one has 3 and last is dropped for env.modname... How much time would I waste fighting errors potentially caused by dropped last argument (e.g. calling the function from 2 different namespaces and require'ing componentactions in the other etc).

 

I'd say "please stop preemptively shooting us in the head so we don't shoot ourselves in the foot", but it's a lost cause (not aimed at anyone in this thread).

I've had multiple issues because of that before. Under wicker, each mod file runs in its own environment, but I had to set the "modname" variable in each of them to prevent the modding API form misbehaving; and that was before DST (that "getfenv(3).modname" in initprint() being nil caused a crash).

Link to comment
Share on other sites

It isn't, and there have been multiple cases in the past where name was same for different mods. From rpghud variants to different forks that you may want or may not want to distinguish, etc. And then there's the case of simply changing mod name to reflect some localization, which should have same ids for the detection case but don't have neither same dir (in steam case) nor name.

 

(Fancy)name is description string, nothing else, and it shouldn't be considered anything else. Yet sadly it has been the only semi reliable method... until they decided to chose even less reliable method as official one I suppose...

 

That's a fair point, different mod branches may use the same fancyname but declare the branch in description/version.

 

But then what happens if I install different versions of the same mod? e.g. dec14 and feb15

The fancyname and id would be the same. If two players connected in this scenario, the game would have to check for the version number after the id. You could use fancyname and version just as well, as both would work unless a modder declares the branch in the description only (which is really a stupid idea in my opinion, nor can I think of any existing case).

 

Who'd change a mod name without changing the mod btw? :p

Link to comment
Share on other sites

Well, the directory name is the only truly unique identifier at their disposal with the present state of the modding API. In singleplayer it was ideal, since then it does serve as a proper identifier for a mod, the problem was they carried that approach into multiplayer, where it certainly doesn't work as a UUID. The correct approach, as I see it, would be to extend the modinfo spec by requiring a field used as an UUID (and checking on load if no two enabled mods specify the same UUID, raising an error if that's the case); though it could be argued that in a multiplayer context even the fancy name would be a preferable approach...

 

Well if the function wasn't written specifically for multiplayer, you could've said it made some sense before. But considering that it doesn't even exist in singleplayer, assuming that x people playing together should have same directory structure as server so they can actually play a mod is mind blowing.

 

But anyway, I'm just nitpicking now, I fully agree with you.

 

 

That's a fair point, different mod branches may use the same fancyname but declare the branch in description/version.

 

But then what happens if I install different versions of the same mod? e.g. dec14 and feb15

The fancyname and id would be the same. If two players connected in this scenario, the game would have to check for the version number after the id. You could use fancyname and version just as well, as both would work unless a modder declares the branch in the description only (which is really a stupid idea in my opinion, nor can I think of any existing case).

 

Who'd change a mod name without changing the mod btw? :razz:

You can change fancyname any time for any variety of reasons. Collisions/legal issues/copyright, name collisions with whatever you weren't aware of, simply changing the product name at will cause you thought of better one. It doesn't necessarily imply that ID has to change. Also, as I said, if someone decides to build localized versions as separate versions (being that strings and modinfo are the only things that need to change, and that there is no way to run functions in modinfo that would present people with different text, it would seem to be logical enough to do it via 3rd party build script and just ship separately), without any functionality differences, there is no reason to use different IDs at all.

 

I'm sure there are more/clearer examples. And anyways, it's a matter of principle, even if they are typically changed at the same time.

Link to comment
Share on other sites

I like the concept of the modinfo.id but sadly I don't think the actual id value should be left in the hands of the public, what with us being the 20 pound mixture of fruit salad and trail mix that we are. It would be extremely easy for a flamboyant modder to decide they don't like the old name of their mod so it's time for a new one. Then suddenly everybody everywhere who needs to make their mod compatible with his/her's will have to go out of their way again to find that mod's new id. And with the way some people are, you just know they would intentionally change their id with each update on the off-chance it would piss someone off.

I think the best way to go about it would be to create a database with all mods and give each one submitted a unique id. When a mod is updated, it will still use the same id. This id would then be stored in an encrypted file and could be downloaded by the submitter and placed in the mod's root directory. When DST needs to see if all parties involved have the required mods, it could simply check for that file in each mod. I realize this is equivalent to building a fifty million dollar nuclear submarine to explore the murky depths of the 4 foot deep koi pond in your backyard but it is the most logical solution.

Link to comment
Share on other sites

That's a fair point, different mod branches may use the same fancyname but declare the branch in description/version.

 

But then what happens if I install different versions of the same mod? e.g. dec14 and feb15

The fancyname and id would be the same. If two players connected in this scenario, the game would have to check for the version number after the id. You could use fancyname and version just as well, as both would work unless a modder declares the branch in the description only (which is really a stupid idea in my opinion, nor can I think of any existing case).

 

Who'd change a mod name without changing the mod btw? :razz:

 

In multiplayer, the game already checks if the mod versions match between server and clients. Of course, there's nothing stopping a modder from changing the mod code without incrementing modinfo's version field, but there's no solution not requiring some level of modder cooperation. The same can be said about modinfo.id. It's meaningless if the modder doesn't understand it should be a stable unique identifier, but there's no much way around expecting modders to understand that; the most that could be done from Klei's side is checking for uniqueness of enabled mod ids on load, as I mentioned before.

 

Well if the function wasn't written specifically for multiplayer, you could've said it made some sense before. But considering that it doesn't even exist in singleplayer, assuming that x people playing together should have same directory structure as server so they can actually play a mod is mind blowing.

Sure, I agree. My point was the modding API had been so far developed under the assumption that the directory name was a proper UUID, and that this premise was simply not revisited under a multiplayer context to see if it still made sense. It doesn't, of course.

Link to comment
Share on other sites

In multiplayer, the game already checks if the mod versions match between server and clients.

Wait I just realized something. The server doesn't make the client download all the mods the client needs into a directory that's not the mods directory? I know I'm late to the party on this whole DST topic but wouldn't that be the best way to go about it? You know, so some mischievous user doesn't decide to alter the code and pass it off as the version the server checks for and is currently using? As soon as it's done downloading it would be executed and, correct me if I'm wrong, editing those files after they've already been executed won't do any good, right? That seems like the cleanest and most griefer-free method of doing it, increased connection times and bandwidth aside.

Link to comment
Share on other sites

Wait I just realized something. The server doesn't make the client download all the mods the client needs into a directory that's not the mods directory? I know I'm late to the party on this whole DST topic but wouldn't that be the best way to go about it? You know, so some mischievous user doesn't decide to alter the code and pass it off as the version the server checks for and is currently using? As soon as it's done downloading it would be executed and, correct me if I'm wrong, editing those files after they've already been executed won't do any good, right? That seems like the cleanest and most griefer-free method of doing it, increased connection times and bandwidth aside.

I really think this is overkill, and it's too much to ask for every client to download the server mods even if they already have it, especially for mods in the hundred megabyte range.

If a validity check were to be implemented, I think it should be by calculating the md5sum of the mod files with a .lua extension (concatenated as a single byte stream, sorted alphabetically by their path relative to the mod folder). My laptop (with its measly dual code i5) takes half a second to do this for Up and Away, including the wicker files. And an md5sum is 16 bytes long, so it's bandwidth-wise cheap to transmit. However, I still think this is overkill. This is a game, not a cryptosystem. Almost all relevant game logic runs on the server, so there's little a mischievous player could do by tampering with the client side copy of a mod.

Link to comment
Share on other sites

Also, client can run client-side mods that are not on server anyway, as well as modify the game code or even binaries on his side. I don't see many things what couldn't be achieved through that, yet could be achieved by changing the client version of the mod running on server itself.

 

The only thing that validity checks would do is give more headaches to modders and server admins, as well as network overhead. There are so many easier ways to destroy one's world or ingame assets anyway, I can't think of much sense to go to those lengths to do it.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...