Add Discord Update channel to SpecialK

[zany130]

Been awhile been very busy 😅

System Information

• SteamTinkerLaunch version: steamtinkerlaunch-v14.0.20231114-1
• Distribution: Garuda Linux

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]

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:

• Add "Nightly" option to SpecialK version list dropdown on the GUI
• In dlSpecialK, we have an if/else block for checking whether we're using default or latest, which sets the SPEKDLURL. We can add nightly here and then set it to use the latest GitHub Actions build download link
  • Build the download URL with fetchLatestGitHubActionsBuild and some creative string building for the nightly.link address (same as we do in dlLatestHMMDev)
  • Set this as SPEKDLURL
• In the block where we download and extract SpecialK, we will instead have a third check for "nightly". GitHub Actions builds are always zips, but extSpek expects a 7z archive. So when we're using the nightly release we will assume we have a zip archive, and extract the DLLs contained inside into a subfolder with the name SPEKVERS just like we do for default and latest
  • SPEKVERS is the value in the dropdown, so currently it will extract into either default or latest

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]

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]

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]

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:

• Allow extSpek to handle zips
• Make the code to get a nightly.link artifact URL generic

[sonic2kk]

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]

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]

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]

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]

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]

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 😄

---

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:

• Put their own SpecialK DLLs (we'll only accept it if we have SpecialK32.dll and SpecialK64.dll
• Put a SKIF installer executable, which we can attempt to extract the DLLs out of using innoextract

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]

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]

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]

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:

• Use existing SpecialK32.dll and SpecialK64.dll pairs, if they exist.
  • Log Show notifier that these are the ones being used
• Extract the SpecialK DLLs from an EXE using innoextract (checking first that the EXE is of a valid type if possible, using strings).
  • If we don't have a valid EXE, log and show notifier
  • If we do have a valid EXE, log show notifier that we are using extracted SpecialK DLLs from executable
• If we have neither a valid executable or a SpecialK32/64 pair, skip SpecialK, log, and show notifier
• Consider commandline usage somehow (just specialk download custom? even though it isn't 'downloading' as such, it would be the simplest way from the code perspective)
• Other appropriate logging around all of this of course :-)

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]

#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]

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]

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 😅

[sonic2kk]

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:

• Replace default, latest, nightly with stable, nightly, custom
  • This means SpecialK will have to be re-downloaded, since no known version name directories will be found, but probably not a big deal. I will note this on the changelog if this gets merged
• If stable selected, download from GitHub -- Same as old latest
• If nightly, do as described earlier in this issue :-) No change in this behaviour
• If custom selected:
  • Look for SpecialK32/64.dll in ~/.config/steamtinkerlaunch/downloads/specialk/custom directory. If found, use those.
  • Take first executable in ~/.config/steamtinkerlaunch/downloads/specialk/custom and if it has SpecialK32/64.dll in its top level app, then assume this is a SpecialK EXE and that these are the DLLs we want, use innoextract to extract the EXE, move the DLLs to the downloads/specialk/custom folder out from the app folder, and remove all extracted SpecialK EXE files
  • If neither of these, return failure (will probably show notifier once we get initial implementation, for more polish)

[sonic2kk]

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 😉

[sonic2kk]

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

EDIT: nightly works, stable doesn't.

[sonic2kk]

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

[sonic2kk]

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

Now, the branch does the following:

• Replaces default and latest options with single stable option
• stable will download latest SpecialK release from https://sk-data.special-k.info/SpecialK.7z
• nightly still works as expected
• createSpekYADList has been removed, as before it would've generated a list of versions, but we no longer use this, so I removed it
• Added code to migrate from default and latest to stable
  • master already has logic to migrate from stable to latest, so I guess this version name was used in the past as well 😄
• clean up anything in the SpecialK version download directory that isn't SpecialK32/64.dll, including the previously downloaded
• Add new custom version which will:
  • Use SpecialK32/64.dll if present
  • Fall back to trying to extract these DLLs from the first EXE in the directory, if found
• Outside of auto-update, only re-download SpecialK if SpecialK32/64.dll are missing, not if the archive is missing (this just makes more sense IMO, and also since we remove the archive now, it makes more sense)

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:

• Minor code review before PR
• Use notifier strings

[zany130]

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]

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

• GitHub Releases
• Website Releases ("stable" channel in the branch)
• Discord Beta
• Discord/GitHub Actions Nightly ("nightly" channel in the branch)

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]

2284a56 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]

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]

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?

[zany130]

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]

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 😅

[sonic2kk]

Fixed it in 35da3af :-)

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]

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]

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? 😄

[sonic2kk]

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]

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]

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 😄

[zany130]

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]

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.

• nightly.link shows artifacts with 83bed401
• GitHub Actions shows be9b35e

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]

Oops, GitHub automatically closed it.

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

[zany130]

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

[sonic2kk]

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 d6db2d7, 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]

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! 😄

[zany130]

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]

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]

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

[sonic2kk]

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]

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

[sonic2kk]

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 a698f72 :-)