|Anonymous | Login | Signup for a new account||2018-11-12 20:04 UTC|
|My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003369||Doomseeker||[All Projects] Suggestion||public||2018-02-10 03:28||2018-10-20 03:12|
|Assigned To||Pol M|
|Target Version||1.3||Fixed in Version|
|Summary||0003369: Wadseeker desperately needs a way to compare downloaded wads to wads being requested by server|
|Description||On multiple occasions Wadseeker has downloaded incorrect files which are modified but have the same name across multiple websites. It makes little sense that the game should launch with incorrect files.|
edited on: 2018-02-10 13:05
How would it do that if Zandronum servers don't publish wad hashes until you've tried to connect?
How about making Zandronum servers publish a list of wad hashes along with wad names? According tohttps://wiki.zandronum.com/Launcher_protocol [^] , introducing SQF_PWADHASHES won't break backwards compatibility.
EDIT: the comma breaks the URL.
EDIT2: publishing wad hashes would also allow directly querying for wads by hash, instead of downloading by name and verifying using the hash.http://wad-archive.com/ [^] has that functionality and can provide many download links for any wad hash, but I haven't seen any other places that allow querying by wad hash.
|For some reason I thought we already added hashes to the protocol, but don't see it in the source (probably was thinking of SQF_DATA_MD5SUM which is no longer used). In any case though Odamex already exposes thing information so it could be made part of our API today.|
If we could recognize hosted WADs by hash and download them by this hash, there still would remain a problem of having duplicate WADs on disk.
In "ye olde" times, especially when it was about WADs designed for multiplayer, the creators were usually aware of the duplicated WADs problem and incorporated WAD's version number in to the WAD's file name. It was simple: you changed something in the WAD, then you also changed its name and, thanks to this, there were no incompatible "duplicates" being hosted over different servers. I can understand keeping the same filename when the WAD is designed for single player, but if the author claims "multiplayer: designed for" then the author should be aware how big of a problem it is to release an incompatible version with the same name.
However, let's assume that the server browser can differentiate WADs by hashes. It also detects that the user, in their "WAD downloads" directory, already has the WAD with the same name. What should it do?
a) Tell the user that there's a duplicate and let them choose to overwrite or cancel the download, optionally allowing to ignore the problem? In the last case the issue or pressing "Ignore" all the time will become annoying.
b) Incorporate the hash into the duplicated WAD's filename when it's downloaded? If we see "mod.wad" but hash mismatches we can always look for "mod_abcdef1234567890hashishash.wad". If that is not found we can always ask to download & rename.
At the very least supporting checking the hash if the plugin supports it and telling the user that there's a mismatch before launching would be useful.
I don't think HTTP provides any standardized way of asking for a content match by hash, so as far as fetching goes outside of something like wad-archive I think the only option is to get a full list of URLs and try them one by one until a match is found. Off hand the only thing we could possibly do to improve that is implement a custom header that hosts could choose to do something with, but I wouldn't expect any sizable number of servers to comply. (Web browser caching relies on the "Etag" header which appears to be an arbitrary server side value so not useful to us.)
I like your idea on auto-renaming files with the hash if there's a duplicate. My initial thought was to just blindly overwrite (assuming the user accepts the usual "would you like to download" dialog), but that sounds like it would be fairly easy to implement and solve the problem nicely.
From the impression I got when Marcaek when he told me of the issue I would assume the bigger problem is Wadseeker picking the wrong version for people without any version of the wad since an older version happens to be hosted on one of our default locations. With that in mind having Wadseeker hash check and reject would be useful even if the duplicate problem isn't solved.
|Is the future of Wadseeker to be a WAD downloader or a WAD (file) manager? In Doomseeker (a server browser)?|
|Not sure where your question comes from. The goal is to get people into servers with the right wads loaded in the case of Doomseeker. For Wadseeker it to find and download the correct wad.|
Quote from Blzut3
Oh sorry, I was thinking a bit naively. I'm inclined to support this, then.
This should do for getting the hashes from the server, right?https://bitbucket.org/csnxs/zandronum-stable2/commits/0041e93150f4c2734ebf4574acf49fb6f768ef2f?at=sb-query-md5s [^]
Just checking before I send a PR upstream...
|Check if there's anything that needs to be done for DEH patches and optional wads, but otherwise that would indeed be what we need.|
|Optional WADs work fine, but I don't think DEH patches have their hashes stored anywhere (they're not even checked when connecting), and they're so infrequently used that I don't think it's worth adding them. I'll submit the PR if nobody has anything else to say.|
edited on: 2018-08-26 19:49
Torr noted that we were running out of space for fields, so a new field for more information was created and it was moved there.
Change in zandronum-stable
Also documented on the wiki (diff)
Pol M (developer)
|This looks like an interesting ticket. I'm gonna do some work on getting the hashes from the server ftm. (I'll extend PWad with a variable, and a constructor)|
Pol M (developer)
|PR (gets the hashes)|
|Only registered users can voice their support. Click here to register, or here to log in.|
|Supporters:||Korshun Zalewa WubTheCaptain Michaelis DevilHunter Marcaek Laggy Blazko AOSP Leonard Vicious Pariah Pol M|
|Opponents:||No one explicitly opposes this issue yet.|
|2018-02-10 03:28||Marcaek||New Issue|
|2018-02-10 12:59||Korshun||Note Added: 0019027|
|2018-02-10 13:00||Korshun||Note Edited: 0019027||View Revisions|
|2018-02-10 13:05||Korshun||Note Edited: 0019027||View Revisions|
|2018-02-10 21:53||Blzut3||Note Added: 0019028|
|2018-02-11 05:08||Blzut3||Project||Zandronum => Doomseeker|
|2018-02-11 09:30||Zalewa||Note Added: 0019029|
|2018-02-11 09:55||Blzut3||Note Added: 0019030|
|2018-02-12 22:12||WubTheCaptain||Severity||major => feature|
|2018-02-12 22:12||WubTheCaptain||Status||new => acknowledged|
|2018-02-12 22:12||WubTheCaptain||Product Version||3.0 =>|
|2018-02-12 22:14||WubTheCaptain||Note Added: 0019032|
|2018-02-13 04:01||Blzut3||Note Added: 0019033|
|2018-02-15 18:15||WubTheCaptain||Note Added: 0019055|
|2018-08-25 22:42||AOSP||Note Added: 0019399|
|2018-08-25 22:48||Blzut3||Note Added: 0019400|
|2018-08-25 22:53||AOSP||Note Added: 0019401|
|2018-08-26 19:46||AOSP||Note Added: 0019415|
|2018-08-26 19:48||AOSP||Note Edited: 0019415||View Revisions|
|2018-08-26 19:49||AOSP||Note Edited: 0019415||View Revisions|
|2018-08-27 02:43||WubTheCaptain||Status||acknowledged => confirmed|
|2018-08-27 07:05||Zalewa||Status||confirmed => acknowledged|
|2018-08-27 07:05||Zalewa||Category||Bug => Suggestion|
|2018-09-13 20:08||Zalewa||Relationship added||related to 0003483|
|2018-09-29 04:51||Blzut3||Target Version||=> 1.3|
|2018-09-29 04:51||Blzut3||Relationship deleted||related to 0003483|
|2018-10-11 21:42||WubTheCaptain||Priority||high => low|
|2018-10-17 17:17||Pol M||Note Added: 0020130|
|2018-10-17 18:35||Pol M||Note Added: 0020131|
|2018-10-18 00:56||WubTheCaptain||Assigned To||=> Pol M|
|2018-10-18 00:56||WubTheCaptain||Status||acknowledged => assigned|
|2018-10-20 03:12||Blzut3||Relationship added||related to 0003552|
Questions or other issues? Contact Us.
|Copyright © 2000 - 2018 MantisBT Team|