Hey, you can just choose `Executable` as a file type, and `Windows` as a platform, like so:
As for the the page-level options, this will do just fine:
So, permissions are a non-issue, because when you push with butler, it detects Linux & macOS binary files and fixes their permissions transparently :)
Now symlinks, that's another story..
But if your app bundle doesn't have any symlinks, you could just build it as a folder and pass that directly to butler.
Ah, that's an interesting one! I took half an hour to investigate it.
lsar is a command that lets me list the contents of an archive.
$ lsar Editor-Mac.zip | head -5 Editor-Mac.zip: Zip Electron.app/Contents/Resources/app/ Electron.app/Contents/Resources/app/ace/ Electron.app/Contents/Resources/app/ace/cleanup.bat Electron.app/Contents/Resources/app/ace/mode-gml.js
When I count the number of entries in Editor-Mac.zip, I get:
$ lsar Editor-Mac.zip | wc -l 490
But if I sort the filenames and keep only the unique ones, I get:
$ lsar Editor-Mac.zip | sort -n | uniq | wc -l 409
This is consistent with other tests I've made - for example, diffing an empty folder against the zip (replicating what `butler push` does), then applying this patch (without verification, so it doesn't fail), then diffing Editor-Mac.zip against the newly-patched folder, and probing that patch:
$ butler probe zeropatch.pwr ∙ patch: 20 KiB before: 123 MiB in 318 files, 157 dirs, 0 symlinks after: 123 MiB in 248 files, 157 dirs, 0 symlinks [...]
So it seems the `.zip` archive contains multiple entries with the same path name - I didn't realize this was even possible :)
I was able to get a complete list by doing:
$ lsar Editor-Mac.zip | sort -n | uniq -c -d 2 Electron.app/Contents/Resources/app/ 2 Electron.app/Contents/Resources/app/ace/ 2 Electron.app/Contents/Resources/app/ace/cleanup.bat 2 Electron.app/Contents/Resources/app/ace/mode-gml.js [...]
Here's the full list if you're curious. The entries are also shown twice in 7-zip:
I'm happy that wharf caught that, but now there's two possible ways we could handle it:
According to this StackOverflow topic, it's not a huge deal and we should be using the later ones. Hmm.
If you're only seeing the issue on Windows, my best guess is an Anti-virus software throttling the rate at which butler can work, either when reading files from disk, diffing them in-memory, or sending them over the network (the disk/network ones being the more likely).
Are you running any AV software besides the built-in Windows stuff?
If you can, I'd recommend trying to find out what server butler is connecting to when pushing a build - I wouldn't be surprised if it's a server in the USA, which would explain the subpar upload speeds. I don't think there's much we can do about that in the short term, sorry :(
As far as I can see, all you need to do is, in edit game page:
I think that's what the user was trying to say to you in the first place (and with much capital letters usage).
The "Other" upload type is for things that are *not* your game (and are not Soundtracks, Books, Videos, etc. - those all have their own update type).
So you really want the "Executable" type, even though you're uploading a zip - that's ok.
I think I have an idea what's been happening (save games in the game folder + app "upgrading" your game install to the demo version because it's more recent + there's no clear way to track upgrades unless the game is uploaded with butler).
To confirm that, can you send
to the firstname.lastname@example.org e-mail address? (these may contain data that's unique to your account, so it's best not to post them publicly).
If my intuition is right, that bug will no longer exist in the next major version of the app. In the meantime, I'm really sorry this issue affected you and I wish I knew about it earlier!
Hey there, we've gotten other reports of Bevontule being broken with the itch.io app so I reviewed its packaging and posted my findings here: https://github.com/itchio/itch-compatibility-watchlist/issues/1275 - it's really easy to fix!
So the app supports two usecases:
The scenario where different downloads are different games is not supported in the app right now.
There's plans to support it, but there's UI/UX questions we have to resolve first.
Although this screenshot shows that the game has been downloaded with the itch.io app, that seems to be something purely between Avast and the game's setup file.
I'd suggest contacting Avast about this: https://www.avast.com/false-positive-file-form.php - that form only allows uploads up to 50MB, so you may have to find another channel to reach them :(
I do have one actionable piece of advice: instead of distributing an InnoSetup installer, just push the game's folder using butler, as recommended in this guide:
Best of luck solving this particular AV issue! Getting rid of the installer altogether might be enough to fix it. Installers tend to request administrator privileges for no good reason, and antivirus software tends not to like that.
1. Is that on Windows?
2. Please send your app log (Bottom-left menu => Preferences => Advanced => Open app log)
3. What do you mean by stop working / crash exactly?
4. Can you send a screenshot of the crash?
5. Did anything else change on your computer recently, besides updating itch ?
the bleeding-edge version of butler (butler head) now accepts a `--dereference` option to the `push` command:
butler push --dereference somedirectory user/game:channel
You can check what it sees ahead of time by using the (hidden) walk command:
butler --json walk --dereference somedirectory
To get the latest bleeding-edge butler, you can run
butler upgrade --head
Let me know how it works for you!
Talking about symlinks is always confusing so let's take something sane as a reference, like the GNU tar documentation:
tararchives a symbolic link, it writes a block to the archive naming the target of the link. In that way, the
tararchive is a faithful record of the file system contents. When `--dereference' (`-h') is used with `--create' (`-c'),
tararchives the files symbolic links point to, instead of the links themselves.
That's also butler's behavior. It tries to be a faithful record of the file system contents.
Having that behavior by default is really useful because "dereferencing" symlinks makes (for example) macOS builds unnecessarily large - those often have symlinks in `YourApp.app/Contents/MacOS/Frameworks`. Linux builds also tend to have symlinks, although it's less standard (obviously!)
Since butler/wharf are entirely itch.io codebases, we can definitely add a `--dereference` option for your usecase - it won't be the default, but it still might make things better for you?
You can refer to the discussion here:
Basically the idea is:
Hopefully that clears things up a bit! We want to write guides for how to achieve this in the near future, as the API develops.
Looking at the logs, "permission denied" to access the .exe file makes me think the app was actually running - or currently being analyzed by another process.
The app missing its exe sounds a lot like an antivirus detecting it as a false positive, are you using any antivirus software?
It isn't possible at the moment - it's a feature we might add later. That doesn't mean you can't start using butler, though - the first push will just take a while since it'll upload the whole thing!
I definitely agree!
That's precisely why I want the app to support .love bundles directly - everything should "just work".
It's also why the app is signed, btw (so there's no scary warning on install).
I just wanted to point out that even though it's a bit silly that the app extract .love file right now, the situation is pretty much the same as if it didn't extract them - your users (whatever the platform) would have to click "Show local files" and drag the .love bundle somewhere (Linux users probably would have to use the command-line).
The current behavior of the app isn't really worse than either "just not extracting .love files" or "refusing to download them" (folks would still have to know what to do with the .love file they get from the website). It's really more of a planned feature than a bug :)
I'm very much looking forward to ship love support as soon as I can!
The LÖVE situation is a bit hairy, but the plan is for the itch.io app to actually support .love files on all three platforms (Linux, macOS, Windows).
I've already done the first 90% (making our own builds of love automatically for each version that comes out), it's the last 90% that's missing (integrating it into the app, showing the user which versions of the LOVE runtime are installed, cleaning up when they're no longer needed by games, etc.) - you can track our progress here: https://github.com/itchio/itch/issues/135
In the meantime, I believe `love.exe` supports dragging a folder to it (it doesn't have to be a zip-compressed .love file - I'm getting my info from this page), so maybe you can instruct your players to do that in the meantime? Let me know if that works out.
Indeed, `/usr/bin` is owned by root, so you need sudo to place executables there.
That's why the default instructions tell you to put it in a path you own and to add it to your `$PATH` environment variable. I assure you those instructions are correct even for recent macOS versions, it's ok if you did it another way, glad you got it working!
The problem is as follows: https://itch.io/app expects you to upload the contents of your game to itch.io, but instead all it sees is
I don't know what your Launcher does, presumably it's able to update the game
Here's what I recommend instead:
Using butler, you can upload up to 30GB, so size shouldn't be an issue. When uploading a new build, it'll only upload what's changed, so it'll be fast for you. Your players too will also be always up-to-date, since https://itch.io/app will download "patches" instead of redownloading the full game every release.
Finally, test it yourself using https://itch.io/app - it seems many players use it these days :) If you run into any issues, feel free to open a thread on this issue board, or to contact itch.io support directly (make sure to mention the word "butler")