Mod compatibility check fix

[Atrik]

This mod allow ignoring the file structure in determining if a mod is compatible or not. 

I'm making this after desperately not understanding what is going wrong with @Emacz mod classical-warefare-aea-main.
With this mod I'm finely able to join his hosts easily.

Anyone making a incompatible mod could use this to make players joining each other easier without having to skip compatibility check.

compatibilitycheckfix.zip

Edited 17 hours ago by Atrik

[guerringuerrin]

Isn't it unusual to allow the same mod to have a different file structure for two different users? Couldn't that generate false positives?

Aside from my question, this seems like a rather forced solution aimed at solving a problem that doesn't really exist. Modders should provide a simple way for users to obtain their mods. Besides, it doesn’t seem like a serious issue. It’s just a matter of learning how to properly create a .zip/.pyromod and providing clear instructions to the end user.

[Atrik]

44 minutes ago, guerringuerrin said:

Isn't it unusual to allow the same mod to have a different file structure for two different users?

I've done a mod that change 0AD icon and I'm trying to distribute it.

1. On my machine
   
   ModImWorkingOn/
   ├─ mod.json
   ├─ fileIgnoredByGitIgnore.@#$%
   └─ art/
      └─ 0ADIcon
   

2. A user cloning my git
   
   New0ADIcon/
   ├─ mod.json
   └─ art/
      └─ 0ADIcon
    
3. A user downloading from my git
   
   New0ADIcon-master/
   ├─ mod.json
   └─ art/
      └─ 0ADIcon
    
4. A user downloading from mod.io
   
   New0ADIcon/
   ├─ mod.json
   └─ New0ADIcon.zip
    

1 hour ago, guerringuerrin said:

Couldn't that generate false positives?

Yes, 1000x harder for the modder to fck up and generate false positive then generating false negative thoughts. Being on the responsibility of the modder rather then the user is also obviously desirable.

I think that also invalidate your remarks about this being a solution for a problem that doesn't exist. Which you would have a high chance of being wrong about since I don't think you ever use incompatible mods (yes you use and distribute compatible ones but they don't have this problem. For now, anyways).
I don't know the original cause of the problem I faced with @Emacz, and others using his mod. But this isn't the first time I'm facing troubles with mods trying to use compatibility check, and this fix would have probably solved past cases.

[guerringuerrin]

Ok, I understand your point. I have a few questions though:

1. From what I understand, in your first example the issue would only exist on the modder’s machine, since end users would all receive the same file structure. Is that correct? If so, this seems like the most justifiable case for not checking file integrity, since it only affects a development environment and not distributed copies of the mod.
2. Seems very similar to the previous one. A user cloning the repository would obtain what is essentially the “final” structure of the mod that would later be distributed, right?
3. I see your point about downloading the repository as a zip from git, which adds the -branch suffix to the directory name. But couldn’t that be avoided by creating a release? That would appear on the right side of the repository page and users could download the packaged version directly.
4. This case also seems similar to the first one to me. Users downloading the mod from mod.io would all receive the same package, and therefore the same file structure. Am I right?

 

33 minutes ago, Atrik said:

Yes, 1000x harder for the modder to fck up and generate false positive then generating false negative thoughts. Being on the responsibility of the modder rather then the user is also obviously desirable.

I think that also invalidate your remarks about this being a solution for a problem that doesn't exist. Which you would have a high chance of being wrong about since I don't think you ever use incompatible mods (yes you use and distribute compatible ones but they don't have this problem. For now, anyways).
I don't know the original cause of the problem I faced with @Emacz, and others using his mod. But this isn't the first time I'm facing troubles with mods trying to use compatibility check, and this fix would have probably solved past cases.

It’s true that I haven’t worked on incompatible mods (I only contributed something very small to the community-mod, the changelog). However, we’ve been using Feldmap for years and this has never been a problem in practice, largely for the reasons above: users end up downloading the same file structure.

The only exception I can think of is when someone downloads the source code directly from the repository (using the “Code → Download ZIP” button). But I always assumed that option exists mainly for people who want to develop or inspect the code, not for end users who just want to install the mod. For that purpose, isn’t the release mechanism intended?

In my humble opinion, an end user shouldn’t have to deal with technical issues that are inherent to development workflows. It seems more reasonable for the modder to be responsible for distributing a consistent packaged version of the mod.

[Atrik]

7 minutes ago, guerringuerrin said:

• From what I understand, in your first example the issue would only exist on the modder’s machine, since end users would all receive the same file structure. Is that correct? If so, this seems like the most justifiable case for not checking file integrity, since it only affects a development environment and not distributed copies of the mod.
• Seems very similar to the previous one. A user cloning the repository would obtain what is essentially the “final” structure of the mod that would later be distributed, right?
• I see your point about downloading the repository as a zip from git, which adds the -branch suffix to the directory name. But couldn’t that be avoided by creating a release? That would appear on the right side of the repository page and users could download the packaged version directly.
• This case also seems similar to the first one to me. Users downloading the mod from mod.io would all receive the same package, and therefore the same file structure. Am I right?

There is always a solution to still make it work, despite the path checking. But good UX is generally about making things simple, resilient (can adapt to a variety of users with a variety of technical level), and not add unnecessary complexity.

Why do you think we should keep the path checking? What is it useful for?
Note that in the examples I give, I pretend like files after the folder where is the mod.json matters but actually it doesn't, yet anyways..

 

16 minutes ago, guerringuerrin said:

However, we’ve been using Feldmap for years and this has never been a problem in practice, largely for the reasons above: users end up downloading the same file structure.

Community mod was downloaded probably exclusively on mod.io I think.
As for Feldmap, it is marked "compatible" for convenience although it's obviously technically incompatible.

 

20 minutes ago, guerringuerrin said:

In my humble opinion, an end user shouldn’t have to deal with technical issues that are inherent to development workflows. It seems more reasonable for the modder to be responsible for distributing a consistent packaged version of the mod.

Can't agree more.