CapsAdmin
New Dropbox link format incompatible with PAC.
Dropbox has recently forced an update on some of their users, myself included. This appears to be mandatory, as I can find no way of reverting this change, nor any method of working around it.
An example of the new Link is: https://www.dropbox.com/scl/fi/11rb8qc9ubo1mat5dn3u2/Confus_500x500.png?dl=0&rlkey=h7bt5evfhdj8fo3k3qa4kj3k0 The obvious fix of changing dl=0 to 1 has no effect in PAC, and even editing the link to conform to the old link standards, like https://www.dropbox.com/s/11rb8qc9ubo1mat5dn3u2/Confus_500x500.png?dl=1 outright does not work.
This currently only affects some people, but for those people, it functionally bricks Dropbox's compatibility with PAC, as PAC does not recognize nor support this new linking structure.
These are the file settings from the file linked above https://i.imgur.com/dD0Zj9q.png https://i.imgur.com/7l4K5qE.png which I have not changed from their defaults.
These are my account settings which I equally haven't changed in years. https://i.imgur.com/qJB1cwj.png
I should note that this issue is only affecting new content hosted on Dropbox. All old links still follow the same old format and work just fine in PAC.
This is an example of an old file that still works just fine. https://www.dropbox.com/s/mmcurw8aiwbh272/ClownF.png?dl=0
This is its settings pages https://i.imgur.com/36wuixC.png https://i.imgur.com/EMg65Bt.png
From what I can tell, only the new addition of allowing for a password on the file has changed, and it does not appear as though this setting can be disabled.
https://www.dropbox.com/scl/fi/11rb8qc9ubo1mat5dn3u2/Confus_500x500.png?dl=1&rlkey=h7bt5evfhdj8fo3k3qa4kj3k0 seems to work fine for me in the browser, it'll instantly download the png rather than previewing it (which should mean that it works in pac).
pac might be rewriting the link to make sure it works
https://github.com/CapsAdmin/pac3/blob/e00e16c30452b37f7a0146ce4cb6ff0ab4777043/lua/pac3/core/shared/http.lua#L68-L74
However passing the first link doesn't seem to modify it when testing the code locally with Lua. So in theory passing the full link with dl=1 should work.
We could add another entry there that rewrites it to dl=1, but it sounds like the problem is something else.
Investigating a little bit further, it looks like when going to the first link with dl=1, it gives you a 302 response with the real URL in the location header along with a cookie. I forget if http.Get follows redirections.
However, the DHTML panel that loads the images for textures should follow them I think. I'm a bit rusty on how that all works.
I'm not 100% certain with what the link format was breaking, as the old links also had a redirect, however with some testing on a server adding a code snippet that just replaces the previous /s/ to the user content version also works for /scl/
having a sub replacement that grabs
https://www.dropbox.com/scl/
with the previous format but with /scl/ at the end like
https://dl.dropboxusercontent.com/scl/
does apparently fix the model downloads, I made a code snippet that seems to work, you just need to add it underneath the rest of the urls in the http.lua file. It should be left in note I did leave the =key after the initial dl=1 so I'm not sure if it it'll work if you cut the rest of the stem off.
url = url:gsub([[^https?://www.dropbox.com/scl/(.+)$]], [[https://dl.dropboxusercontent.com/scl/%1]])
After a brief test involving sounds and materials in Singleplayer, this update appears to work. However, I have not tested more complex things like Models yet, and I have yet to test it on Multiplayer, but thus far this appears to be functioning.
Hey guys, just thought to let you know it seems Dropbox has seemingly changed their link format again and so MDL model ports from Dropbox appear to be non-functional. My analysis of the change suggest that the parts in between the double aestricks are now missing in their new format: https://www.dropbox.com/scl/fi/w8r11u08387pe07i3w1wl/quadra.zip?dl=0&file_subpath=%2Fquadra%2Fmodels%2F2.mdl&rlkey=wrqaurt2iw9skrz3tefgr3q9k When replacing those sections back in the new version of the link of the same model, the model loads again. Any suggestions on what to do to rectify this? Regardless thanks and have a nice day.
The rlkey is required or dropbox doesn't let you download the file. If you give pac the correct link, you won't run into the issue.
https://dl.dropboxusercontent.com/scl/fi/w8r11u08387pe07i3w1wl/quadra.zip?rlkey=wrqaurt2iw9skrz3tefgr3q9k
That is true. The issue is usually the rlkey appears by itself but assuming a recent Dropbox update is the cause, the rlkey has vanished as well. Is there a way to locate the rlkey maybe? Thanks ^^
Idk, I'm guessing that's something they're enforcing on free accounts? The links I get don't require an rlkey.
Hey, I attempted to replace the line (Line 71) as requested but it does not seem to work at the moment.
On Mon, Sep 18, 2023 at 3:19 PM thegrb93 @.***> wrote:
Try replacing this line
https://github.com/CapsAdmin/pac3/blob/f0df6a366ff2acc616731dda9d69dfdb652cc20b/lua/pac3/core/shared/http.lua#L71
with url = url:gsub([[dl%=[01]&?]], [[]])
— Reply to this email directly, view it on GitHub https://github.com/CapsAdmin/pac3/issues/1290#issuecomment-1722870183, or unsubscribe https://github.com/notifications/unsubscribe-auth/BCUVQPYERPAG7DZDMDOLGPLX27YYVANCNFSM6AAAAAAY2HPTDY . You are receiving this because you commented.Message ID: @.***>
@Techdragon2000 yeah I deleted that suggestion since I realized it wasn't the issue.