search

sonic2kk / steamtinkerlaunch

Linux wrapper tool for use with the Steam client for custom launch options and 3rd party programs
GNU General Public License v3.0
2.1k stars 70 forks source link

Add Discord Update channel to SpecialK #975

Closed zany130 closed 9 months ago

zany130 commented 9 months ago

Been awhile been very busy :sweat_smile:

System Information

Feature Description

SpecialK has 3 release channels.

Stable: this is what you get from https://sk-data.special-k.info/SpecialK.exe and https://github.com/SpecialKO/SpecialK/releases; they are the same. For our purposes, I guess GitHub is better.

Discord beta: https://sk-data.special-k.info/repository/SpecialK_xx.xx.xx.xx.exe (the format is 2 digit year . 2 digit month date.exe ex:23.11.13.2.exe These are curated from the discord nightly by one of the devs, Aemony who is also the main dev behind SKIF (SpecialK windows installer/manager)

Discord nightly: I don't think there is any way to download these as they are hosted directly on Discord (as the .dll, so there is no need to extract them)

The SpecialK dll can be extracted from the exe with inoextract.

I believe this used to be an option, but it wouldn't download the file; instead, the user had to provide their own.

Also, the default and latest are the same version, which is the stable channel.

sonic2kk commented 9 months ago

This is a good suggestion, but I have no good idea how to implement this. Is there any way to get the Discord beta release naame directly? We could perhaps try to guess, by trying to "calculate" the name from the current date and working backwards if we can't find it. But, I don't like this approach. I would prefer to be able to fetch it more directly.

It looks like SpecialK has GitHub Actions integration, we could fetch the release from here using nightly.link. The naming scheme seems similar, except the actions have a commit hash i.e., the current latest is SpecialK_23.11.13.2_83bed401, where 83bed401 is the hash that the workflow built from. These workflows don't even come with SKIF, they are the raw 32bbit/64bit DLLs, which is perfect for our case, we don't even need innoextract.

Though the builds on Discord are "curated", I don't think we need to care about that. These builds are probably more in line with the "Discord Nightly" release, and I would be fine with simply naming this channel "Nightly".

If we can get the file and the DLL into a folder matching the dropdown selection name (i.e. discord), the rest of the logic should just work, since we just pick it from the folder. However, picking the release is the tricky part.

I don't think there is a way that we can get the Discord Beta builds, and I would rather not download files directly from Discord for the Discord Nightly builds. I think unless we can get the latest beta URL reliably, we can just download from nightly.link. We do this for HMM so it should be proofed out a little :-)

Looking at the code, we should be able to do it like this:

A lot of the logic should already be in place for this, we just need to build a separate URL to download SpecialK from, and modify the extraction logic, and ofc add the nightly option on the GUI.

sonic2kk commented 9 months ago

Ok, it's not as simple as re-using fetchLatestGitHubActionsBuild I don't think, as this will return CodeQL workflows for SpecialK. This function was written with HMM in mind and so we didn't run into this.

We will have to build in an optional parameter to choose to filter the workflow name.

sonic2kk commented 9 months ago

Well, even with that modification, the URL still isn't quite right. For HMM we know the archive name ahead-of-time, but we don't for SpecialK, so we'll need to download the nightly.link page and parse out the URL. We'll need to just hardcode the nightly.link (https://nightly.link/SpecialKO/SpecialK/workflows/build-windows/main), download the page, parse the URL out of the page, and then download that.

We can still use fetchLatestGitHubActionsBuild to get the latest hash, and then use some regex like this on the nightly.link page to parse out the build we want:

# This will probably be turned into a generic method, but this rough draft should work initially or something close to it will be used
SPEKAPIURLPATH="${SPEKPROJURL//$GHURL}"
SPEKNIGHTLYHASH="${SPEKPROJURL}/$( fetchLatestGitHubActionsBuild "${AGHURL}/repos${SPEKAPIURLPATH}" 1 "Builds" ) | cut -d ';' -f2"  # gives us the commit hash of the latest workflow run from workflow name "Build" 
SPEKNIGHTLYURL="https://nightly.link${SPEKAPIURLPATH}/workflows/build-windows/main/"  # URL of nightly.link page with latest workflow artifact links
SPEKNIGHTLYURLPATTERN="${SPEKNIGHTLYURL}.*?${SPEKNIGHTLYHASH}.zip(?=\")"  # Pattern for the URL we want
SPEKDLURL="$( "$WGET" -q "${SPEKNIGHTLYURL}" -O - 2> >(grep -v "SSL_INIT") | grep -oP "${SPEKNIGHTLYURLPATTERN}" | head -n1  )"  # Grep all links matching this pattern and pick the first one (should only be one anyway)
sonic2kk commented 9 months ago

Had to tweak the above a little, as fetchLatestGitHubActionsBuild returns a 7 character hash, but the SpecialK artifact name has 8 characters. It works now though, tested with some debug code.

The next steps are:

sonic2kk commented 9 months ago

Got something whipped up locally to download the latest nightly from GitHub, will push soon.

No idea how to get the nightly version initially mentioned but hopefully this update channel will suffice :-)

Of course, if there is a way to get the latest for the version you mentioned, we can still add that. We could call that one "Beta". I don't think there is any harm per-se in having the nightly as well, though.

sonic2kk commented 9 months ago

There is now a branch up at spek-nightly that implements this. I did add the nightly option to the dropdown on the GUI, but I did not test this. I also did not test if SpecialK installs, I only touched the downloading functions though. Because of how we search for the SpecialK source directory (by the version name), this should work though.

I tested this with steamtinkerlaunch specialk download nightly and it correctly downloaded the latest nightly. It doesn't clear the previous zip yet but maybe I'll add that to extSpek where it removes the previous archive. Should be easy enough.

That's all for tonight though, let me know how this goes and tomorrow I'll see about cleaning up the code to be more generic, and then getting a PR up :-)

sonic2kk commented 9 months ago

Oh, one more thing:

Also, the default and latest are the same version, which is the stable channel.

If this is the case, maybe we can just rename this to "stable".

This is probably still fine for backwards compatibility, SpecialK will probably just redownload again. Old versions won't get removed but for the sake of a few megabytes I think it's fine, and a user can manually remove them. The paths are on the wiki, and I'm considering a command to help clear downloads quickly.

zany130 commented 9 months ago

Awesome work !

Just to clarify the nightly you are grabbing from github actually seems to be the same release published on discord as "discord nightly"

apparently it is the same zip just uploaded onto discord.

as for the "discord beta" channel; Honestly I don't see it lagging that far behind from the "discord nightly"

I was thinking for this one we would ask the user to specify the version and then add that to https://sk-data.special-k.info/repository/SpecialK_xx.xx.xx.xx.exe (that is where the beta are hosted and it seems old versions are kept).

though thinking on it maybe this adds to much complexity as we would then need another text box for the version

on the other hand it maybe nice to have a text box version selector if for example someone wants to use a specific version, like for example I know the latest nightly has issues with reshade on trails into reverie

zany130 commented 9 months ago

Also change is working correctly it downloads and installs the latest nightly version so the "discord nightly" branch

on an unrelated note, the reshade issues I was having with the latest SpecialK seems to be fixed!

sonic2kk commented 9 months ago

Well it seems this change is good all around, thank you for testing :-) And for confirming what the GitHub Actions version corresponds to. I was a bit concerned it may end up being some third, perhaps even more bleeding edge version than the other two, and that we'd end up with another variable. It being the same as the Discord Nightly simplifies things.

Just out of interest, since ReShade+SpecialK cak be tricky, are you using any specific ReShade version with SpecialK? If ReShade is loaded with SpecialK I believe we have an override version that is further behind specifically because of tricky situations like this, so I'm basically wondering if a newer SpecialK fixed an older ReShade or the other way around. And that's just me being nosy :smile:

on the other hand it maybe nice to have a text box version selector if for example someone wants to use a specific version, like for example I know the latest nightly has issues with reshade on trails into reverie

Yeah, this is always the challenge. Either you end up too far ahead or too far behind. Adding the version selector in this way is a bit unintuitive because it's based on the Discord beta name, which is an arbitrary nightly date. It makes implementation easier though I suppose.

I'll have a think about what the best way to handle this is, if we can handle it at all. At this point I'm somewhat inclined to have a way to load custom SpecialK DLLs. Perhaps we could have a "custom" folder in the SpecialK download directory, where a user can either:

This should allow a straightforward way for custom SpecialK installs. We could even extend this so that when we're searching for SpecialK folder names, we can list any folder that has either an EXE in it (maybe we can use strings and some regex to check if the EXE is a SKIF installer) or SpecialK32.dll and SpecialK64.dll. This would allow for N number of custom versions. Though that might be overkill :-)

sonic2kk commented 9 months ago

PR is up for this, I will probably merge it soon since it worked in our testing, just going to do some light review.

Depending on how above goes, if we just want a "simple" solution where we have one custom directory and we just expect SpecialK DLLs to be there and we don't extract them ourselves, that change would be a very straightforward way to close this issue. Otherwise if we want to be able to extract them, or want N number of custom directories, that would also take additional time. Neither of those will be resolved in #977 though, they will be separate pieces of work :-)

zany130 commented 9 months ago

Just out of interest, since ReShade+SpecialK cak be tricky, are you using any specific ReShade version with SpecialK? If ReShade is loaded with SpecialK I believe we have an override version that is further behind specifically because of tricky situations like this, so I'm basically wondering if a newer SpecialK fixed an older ReShade or the other way around. And that's just me being nosy 😄

It was a SpecialK issue as using the latest fixed it ( I was having issues with a release from last week I think it was. It seems they are currently trying to integrate Reshade and specialK more closely

I like the idea of extracting from an exe or installing a .dll if I remember correctly, that's what frostworx did originally for the discord releases.

A user could also copy their desired reshade .dll into the game directory and name it appropriately (that's how I was testing the discord versions)

sonic2kk commented 9 months ago

I like the idea of extracting from an exe or installing a .dll if I remember correctly, that's what frostworx did originally for the discord releases.

Okay, I think then the solution we'll go with after #977 is merged is to have a "custom" folder where we either:

Just my rough idea of how implementation will look at the minute. It may change as it gets developed, mainly a note-to-self but also if you spot anything that should be done better do shout!

sonic2kk commented 9 months ago

977 has been merged, so SpecialK Nightly release support is now available in master.

By the way, should we replace the default and latest version names with stable if they are both the same and point to the stable channel? It might be good to clean that up now, and would be nice to have a clean list with stable, nightly, custom.

Also, this custom option I outlined above, combined with #977, will probably replace the "Discord Beta" option you requested. Sorry that it's not really what you asked for, I just don't see a feasible way without having a dedicated version box on the Game Menu (which would be prone to user error). Letting a user download this version manually and having STL extract it is probably a good compromise, plus anyone who might build SpecialK themselves or any future forks would be able to drop custom DLLs in as they please. Plus, the Discord Beta can still be manually downloaded and dropped into the custom folder, and it can be installed by STL for any game that custom is selected for, so it'll be managed by STL still.

So hopefully not too much of a loss but let me know if you feel differently :-)

zany130 commented 9 months ago

Sounds good. Like I said before nightly and beta are almost in sync. And it would be to comber some to to have a version text box

Having stable, nightly, and custom sounds good to me.

Thanks for implementing this 👍

sonic2kk commented 9 months ago

I just realised, adding "custom" as a directory may work, since we already have the logic to look for SpecialK DLLs. So with that in mind we should be able to just skip the download check if we're using version custom, and it will automatically be picked up as the directory name to search.

Extracting the EXE may be slightly more work but since we'll have a conditional for custom anyway, we can replace the download logic that would normally go here with the EXE innoextract logic.

Do you know how to use innoextract to get the DLLs out of the EXE? I haven't used innoextract before :sweat_smile:

sonic2kk commented 9 months ago

Hmm, might've figured something out locally. Will push to a branch soon and do some testing once I confirm it won't blow everything up. What I should have so far:

sonic2kk commented 9 months ago

There is a branch up that is, for now, entirely untested apart from a shellcheck overat spek-custom.

I'll do some testing when I have some time. Feel free to try it if you'd like but it's pretty early stages so I wouldn't expect much just yet :-) The initial implementation is in place but I dunno if it works yet :wink:

sonic2kk commented 9 months ago

Did some quick testing, custom appears to work. Now I have to regression test stable.

EDIT: nightly works, stable doesn't.

sonic2kk commented 9 months ago

Oh, we will also have to migrate default and latest to stable in migrateCfgOption.

sonic2kk commented 9 months ago

Okay, made some more tweaks. Now, stable should work again. This branch should be ready for testing!

Now, the branch does the following:

If you can, it would be great if you could verify that stable is really downloading the same as the previous default and latest :-) It would also be great if you could verify that auto update SpecialK still works, as I had to tweak the version name it checks on. It should only auto-update for stable and nightly, as it doesn't make sense to auto-update on custom (the user manually updates this, and if DLLs are missing, we re-check the EXE as a fallback).

Any other tests you can think of doing would also be great. Anything you can think of that might be grounds for a regression, please test :-) I don't really use SpecialK, so anything you can do to help make sure this works and also migrates smoothly to using the new versions would be appreciated!

Assuming everything here works as expected, the remaining work is:

zany130 commented 9 months ago

I did some light testing, and everything seems to work fine. Stable downloads the latest stable nightly get the latest nightly and custom extracts. Any exe or zip I put in the custom folder

It seems that my original assumption that GitHub releases and the website are the same is wrong.

GitHub releases are older there still on 23.8.26. the latest stable from the website is from 23.9.10

Its probably better to stick to the website instead of the GitHub for the stable channel like you already did in spek-custom

EDIT one thing I noticed is that its downloading the nightly version on every startup even if its already up to date steamtinkerlaunch.log

sonic2kk commented 9 months ago

So there are the following SpecialK versions, in order of oldest to newest?

Its probably better to stick to the website instead of the GitHub for the stable channel like you already did in spek-custom

Yeah, probably no reason to have both :-) The difference doesn't seem that dramatic anyway. If there is a request it should be possible to fetch the GitHub Release though. If it's tagged properly, we have functions to get the latest release's expanded_assets, we use this for MO2 and Vortex. If it's not tagged properly, we have some hacked in logic for x64dbg to download the releases anyway, we can probably do something like this / make it generic.

But until it's requested, I think it's fine to go with the website release as well.

EDIT one thing I noticed is that its downloading the nightly version on every startup even if its already up to date

I have an idea of what might be causing this, and it may not be exclusive to the nightly. In the check to re-download SpecialK, we only do this if SpecialK32/64 is missing. However, I was not checking on the full path, just on the basenames, so I assume the check was always failing (i.e. it was checking SpecialK32.dll and not $HOME/.config/steamtinkerlaunch/downloads/specialk/nightly/SpecialK32.dll). I'll push up a fix now :-)

Thanks for testing! I appreciate it a lot.

sonic2kk commented 9 months ago

2284a561e3ea734aa8cffd7f3afc3f0e8bc28e56 should fix the issue, appears fixed in my tests :-)

If things continue looking good I'll open a PR tomorrow, then do some more review, add notifier, and update the wiki.

zany130 commented 9 months ago

still seems to redownload the archive even when there was no update

this seems relevant 

Fri Nov 17 07:22:17 PM EST 2023 INFO - installRSdll - Destfile '/home/zany130/.local/share/Steam/steamapps/common/The Legend of Heroes Trails into Reverie/bin/Win64/ReShade64.dll' already exists, but has a different version or is not a ReShade DLL - updating
Fri Nov 17 07:22:17 PM EST 2023 INFO - installRSdll - Destfile '/home/zany130/.local/share/Steam/steamapps/common/The Legend of Heroes Trails into Reverie/bin/Win64/ReShade64.json' already exists, but has a different version or is not a ReShade DLL - updating

steamtinkerlaunch.log

sonic2kk commented 9 months ago

I misunderstood where the problem was coming from. 2284a561e3ea734aa8cffd7f3afc3f0e8bc28e56 fixed an issue with steamtinkerlaunch specialk download nightly.

Those logs lines are strange, but it refers to ReShade DLLs. This means the ReShade version check is failing, and this error comes from checking ReShade update.

I'll investigate the log and see if I can find why it's re-downloading. Are you sure this isn't happening on master?

sonic2kk commented 9 months ago

Actually, this looks intended, because you have AUTOSPEK=1 (Auto-update SpecialK I believe is the checkbox). Since auto-update (like for ReShade) will re-download the files. That's how it checks for updates, since it can't compare a local version with an online version (for SpecialK, we'd have to download and maybe compare some kind of checksum).

The logic also reflects this:

# ...
elif [ "$AUTOSPEK" -eq 1 ] && { [ "$SPEKVERS" == "stable" ] || [ "$SPEKVERS" == "nightly" ] ;}; then
    # Download SpecialK code here
# ...

So, I guess if you turn off auto-update SpecialK, this should work? :-)

Fwiw, the logic on master is very similar, just with different version names:

# ...
elif [ "$AUTOSPEK" -eq 1 ] && { [ "$SPEKVERS" == "default" ] || [ "$SPEKVERS" == "latest" ] || [ "$SPEKVERS" == "nightly" ] ;}; then
    # Master downloads SpecialK here too
# ...
zany130 commented 9 months ago

Opps my bad yes those are reshade lines while its still strange the its reinstalling. that wasn't what I was talking about I was talking about specialK

Ah I misunderstood then I thought there was logic to prevent a redownload if that version was already installed

sonic2kk commented 9 months ago

SpecialK will not be re-downloaded if Auto-Update SpecialK is disabled (it should not be on by default or anything afaik, so hopefully no issues on that front). If you turn that setting off, it should detect that both SpecialK DLLs exist and not update anything :-)

It should log this as well:

dlSpecialK - Already have the archive 'name.ext'

Although this log is inaccurate now I suppose, I should change it :sweat_smile:

sonic2kk commented 9 months ago

Fixed it in 35da3af2fb019fa50513260774b7ee2d46a34822 :-)

Thanks for testing auto update SpecialK as well though, as well I misunderstood until I looked at the code, but I guess it makes sense. We can't really find the SpecialK version to compare with (since they're just stable, nightly, and custom).

I just didn't drink enough coffee today to catch that one heh.

zany130 commented 9 months ago

Hmm the only way I can think of is to extract the .dll version from the already installed .dll (there a tool to do this forgot which one I think its already in steamtinkerlaunch deps)

then we could compare the version number of the archive against this .dll version?

though this sounds kinda hacky and prone to issues...

yup can be done with peres -v and convientaly this is already a dep of steamtinkerlaunch https://github.com/sonic2kk/steamtinkerlaunch/wiki/PEV-PE32-file-analysis

peres -v dxgi.dll
DEBUG: Length=17, String=AFX_DIALOG_LAYOUT
DEBUG: Length=4, String=TEXT
DEBUG: Length=4, String=WAVE
File Version:                    65263.1213.1.0
Product Version:                 23.11.13.2

there may also be a way to get the filename from github without downloading the whole file.

Just some thoughts and seems kinda a lot just to save a few MB

sonic2kk commented 9 months ago

Yeah it would be prone, it also means we'd have to download SpecialK anyway, which may defeat the whole purpose. At that point, just extract again, right? :smile:

sonic2kk commented 9 months ago

there may also be a way to get the filename from github without downloading the whole file.

From GitHub Actions, I guess we could inspect the name. Though there's no guarantee it would match, we'd be relying on the filename and also the structure of the filename to Parse the version out.

We also can't get the version from the stable channel, since it just downloads SpecialK.7z. There might be a way to Parse it out of the website though.

It seems like a lot, maybe out of scope here. If someone makes a PR directly for checking the SpecialK version though I'd review it, but I don't think it's a very high priority. Any solution here would involve checking or downloading something from the web anyway. As you said, it's a few megabytes saved and then as well, disabling auto-update resolves it just fine.

I'll get a PR up for that branch soon, will probably be merged in later. Further improvements can be discussed separate to this issue I think, they're not totally invalid concerns or anything though. Just maybe not a big enough problem for now :-) If you feel strongly the other way I guess you could open a new issue / work on a PR if you have time, but I think this is negligible and someone who wants different behaviour could implement it themselves. Auto-update is "intended" to work this way for now and while a change would be welcomed I'm not sure if I want to spend time juggling version strings for such a small part of SpecialK.

Thanks for looking into ways to get the local version though including within SteamTinkerLaunch's existing dependencies. That should help serve as an implementation hint if anyone looks at this in future :-)

sonic2kk commented 9 months ago

I believe the above was resolved, so I opened a PR #979. I have a couple of things left to do on it, then I'll update the wiki to better reflect the new usage of SpecialK (removing mention of the older versions, detailing how to use custom, etc).

The wiki update is the bulk of the remaining work and once that's done I'll be pretty close to merging this PR. Hoping to get it merged sometime today though!

sonic2kk commented 9 months ago

Now that #979 is merged, this issue should be resolved :-) I will close for now.

Please re-open if something doesn't work or if I caused some horrible fires, I have tested lightly and this appears to work, and you have also tested (I also believe another user will be testing this as they use SpecialK regularly, so we should catch any regressions quickly).

Thanks for the feature request, hope these two features are useful to you :smile:

zany130 commented 9 months ago

It seems like its failing to download the lates nightly update a 1668540.log

EDIT: deleting the dlls from the nightly folder doesn't help it seems like its failing to download

Sun Nov 19 01:51:58 PM EST 2023 INFO - useSpecialK - Updating SpecialK in the gamedir because AUTOSPEK is enabled
Sun Nov 19 01:51:58 PM EST 2023 INFO - useSpecialK - SpecialK is enabled - Installing dlls if required
Sun Nov 19 01:51:58 PM EST 2023 INFO - dlSpecialK - Using SpecialK Nightly release, fetching from nightly.link
Sun Nov 19 01:52:00 PM EST 2023 INFO - dlSpecialK - SpecialK GitHub Actions hash is 'be9b35e'
Sun Nov 19 01:52:00 PM EST 2023 INFO - dlSpecialK - SpecialK nightly.link URL is 'https://nightly.link/SpecialKO/SpecialK/workflows/build-windows/main'
Sun Nov 19 01:52:00 PM EST 2023 INFO - dlSpecialK - SpecialK DL URL is ''
Sun Nov 19 01:52:00 PM EST 2023 INFO - dlSpecialK - SpecialK Archive name from DL URL is ''
Sun Nov 19 01:52:01 PM EST 2023 INFO - dlCheck - Downloading '' to '/home/zany130/.config/steamtinkerlaunch/downloads/specialk'
Sun Nov 19 01:52:01 PM EST 2023 INFO - notiShow - Message 'Downloading '/home/zany130/.config/steamtinkerlaunch/downloads/specialk/nightly/'' should go to StatusWindow
Sun Nov 19 01:52:01 PM EST 2023 INFO - dlCheck - 'wget -q --show-progress  -O /home/zany130/.config/steamtinkerlaunch/downloads/specialk/nightly/'
Sun Nov 19 01:52:01 PM EST 2023 INFO - dlSpecialK - Cleaning up SpecialK version folder '/home/zany130/.config/steamtinkerlaunch/downloads/specialk/nightly'
Sun Nov 19 01:52:01 PM EST 2023 SKIP - dlSpecialK - '/home/zany130/.config/steamtinkerlaunch/downloads/specialk/nightly/SpecialK32.dll' is missing!
Sun Nov 19 01:52:01 PM EST 2023 SKIP - dlSpecialK - '/home/zany130/.config/steamtinkerlaunch/downloads/specialk/nightly/SpecialK64.dll' is missing!
sonic2kk commented 9 months ago

Looks like it's because the latest build that nightly.link shows has a different hash (and thus is a different build artifact) than the latest GitHub Actions build.

The latest SpecialK GitHub Actions build failed, though there are still artifacts available. I suspect this is because nightly.link only shows the artifact links for the last successful build.

I guess the "fix" on the STL side is to filter GitHub Actions builds by successful, though it would be nice if nightly.link also showed failing builds if they still had artifacts...

sonic2kk commented 9 months ago

Oops, GitHub automatically closed it.

Please check if d6db2d7 fixed it, though :-) In my tests it works again.

zany130 commented 9 months ago

Yes downloads succsefully now though it is not the latest, but that's because failed github actions?

sonic2kk commented 9 months ago

Yes, nightly.link doesn't provide links for failed builds. The latest build STL can fetch, or any program relying on nightly.link, is the one linked here: https://nightly.link/SpecialKO/SpecialK/workflows/build-windows/main

To use the very latest (though it may have issues, since the build failed) you could download the archive and put the DLLs in the custom directory. But apart from that, there's nothing we can do. STL was able to fetch the hash for the latest build before https://github.com/sonic2kk/steamtinkerlaunch/commit/d6db2d7a443c14f9d678953b8a6e58c9e3834d64, but because that didn't match the latest that nightly.link could provide, there was a mismatch.

Basically, nightly.link won't give us the link for failed builds, so we can only use the builds from the last successful run. If you'd like, you can keep an eye on the latest success/failure workflows here: https://github.com/SpecialKO/SpecialK/actions/workflows/build-windows.yml

Also, while we can get the actual artifact URL from GitHub Actions, it redirects, and even trying to use that redirect URL won't work with wget or curl. That's why nightly.link was created :-)

sonic2kk commented 9 months ago

I think this can be closed again. Good catch as always, and once there's a successful SpecialK workflow, STL should be able to pick it up.

Thanks! :smile:

zany130 commented 9 months ago

Currently if the is a SpecialK64.dll and/or SpecialK32.dll already in the nightly folder it skips extracting the zip file even if the zip is newer.

This means the special K auto-update function will only work once and then it will no longer work.

The solution would be always to extract the files even if the .dlls are currently there.

sonic2kk commented 9 months ago

The archive should be removed after downloading and extracting though? It is in my tests, I can't re-create a scenario where the archive stays, for stable or nightly.

The solution would be always to extract the files even if the .dlls are currently there.

This was deliberately changed in favour of removing the archive. Commit with relevant code blocks highlighted.

zany130 commented 9 months ago

hmm it seems that its not overwriting the already existing .dlls when it goes to extract the zip

sonic2kk commented 9 months ago

Ah, I can reproduce that. Seems unzip needs the -o flag to overwrite. The 7z extract uses the -o flag already. I'll push a fix and close this again :-)

zany130 commented 9 months ago

my bad should of tested this before just realized a super easy way ... just create empty dummy SpecialK32.dll and SpecialK64.dll 😅

sonic2kk commented 9 months ago

No problem, I don't use or like SpecialK (or other similar tools) so I rely on reports and PRs to keep these features maintained.

Issue should be fixed with a698f728290aae11b4fcaf6ea3450d2aacf11cb7 :-)