Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Upload access denied

A topic by Irog created 22 days ago Views: 224 Replies: 9
Viewing posts 1 to 5
(+1)

When I upload a 10 MB zip file to my game Return From the Tavern (https://irog.itch.io/return-from-the-tavern) via the button "Upload files", the progress bar reaches 100% but then shows the red message "There was a problem completing your upload. Access denied.". Over the past weeks, I've updated the download many times with improvements, bug fixes and new languages (the game has 15 languages now). Did I exceed the number of times a creator can upload a file per month?

Support Ticket = 383316

Moderator(+2)

I’ve let our admins know about your ticket.

Thanks !

Worth trying butler while you wait on the ticket. It's itch's own command line uploader and it takes a completely different path from the browser upload, so a failure that happens right at the end of the progress bar is often just absent there.

butler push yourbuildfolder irog/return-from-the-tavern:windows

The reason it suits your case specifically is that butler uploads incrementally. It diffs against your last build and sends only the changed bytes, so a small fix in one of fifteen languages costs seconds rather than a full 10 MB round trip every time. We push every build this way and haven't used the browser uploader in months.

On your own theory, for what it's worth: there's no published monthly upload limit, and a quota would almost certainly reject you before the transfer rather than after it reached 100 percent.

Deleted 18 days ago
(+1)

Adding new languages proved to be more work than expected. Almost all languages added required new characters that were not in the pixel font and adapt the game code to use the new characters and add the ReadMe in the new language and update all the ReadMe with credits to the new translator... both for Windows and Linux.

The web upload is ideal for small files like 10MB. It worked before so it feels like a software regression.

(+1)
That's fair on the regression, and the ticket is the right route for it. If it used to work at that size, something changed on their side. On the font work, one thing that bit us hard when we added accented glyphs to a pixel font. The font was generated from one shared table, but each build also carried its own hand typed copy of the alphabet and searched it using the generated character count. Adding nine glyphs moved that count everywhere, so the lookup ran past the end of the older arrays. It didn't crash. It printed a wrong glyph, most often for the space, and only on some screens. Worth checking that everything indexing your character set reads its length from the same source the font is built from, rather than from a constant that was correct before the new languages went in. If Windows and Linux embed the font separately, compare the built bytes. Ours both compiled fine while one was wrong.

Yes, character index was one of the issue for me too. It was also my first project were I used multiple languages. At first it read text from UTF-8 and read characters that had up to 2 bytes per characters. Guess what happened when came a new language using some 3 bytes characters...

(2 edits)

I'm having the same issue, mine is a web build, butler also gives a 403 error. Specifically:
"

∙ For channel `web`: pushing first build

creating remote patch and signature files: while creating resumable upload session, got HTTP 403
"

I was able to upload update builds couple of times today earlier. But now I can't.
Edit: I was able to upload through dropbox.

That one has a nasty edge, because it isn't only the languages you'd expect that push you past 2 bytes.

Accented Latin sits in the 2 byte range, so French and Spanish look safe. But everything from U+0800 up takes 3 bytes, and that includes the punctuation a word processor inserts on its own. A curly apostrophe is U+2019, an em dash is U+2014, an ellipsis is U+2026. So a translator who wrote their file in Word can hand you 3 byte characters in a language that has none of its own, which is a horrible thing to debug because the language looks like it should be fine.

Cheap check before you touch the decoder: scan every translation file for any lead byte from 0xE0 up and print the character with the file it came from. If the only hits are punctuation nobody asked for, normalising those back to ASCII is far less work than widening the reader.

The decoder is now able to deal with 3+ bytes characters. It won't display the characters absent from the font. But I've not yet made it resistant to ill formed UTF-8 or missing bytes.