Weirdly? ... Anyway, the backend is Electron through Chromium (src base for Chrome), so they'll most likely be in
AppData/Local or LocalLow or Roaming/tits/ (probably blob_storage) if the author didn't decide to overwrite default behavior. Not hard to find.. As for editing the files, just export from the game and save to desktop, edit with an actual editor (saveeditonline.com for example) and then load the file.
Weirdly as in I looked in appdata/roaming/tits-html-electron and appdata/roaming/tits (the only tits folders I could find, so I guess I could be missing something) a month or two back, and didn't find a single file that I could concretely correspond to save data. Maybe the format they use makes perfect sense to you, but not to me. And that's okay, because I'm dumb
Not dumb, just unaware. Electron “powered apps” store saves there by default, though this behavior can be overwritten. In this case, I recall it being in blob_storage, but that is also still Chromium-formatted storage. Export from the game, edit, import back. The only reliable way to do it and no need to bother about locations as well.
Yeah, blob_storage was empty. I'd be curious to know where the data is actually stored. I thought they might be in Local Storage or Session Storage, but nothing is clearly marked as a save file. Just idle curiosity though, exporting a save from in game is the way to go as you said and I have my own folder for storing those.
It used to be in blob for some devices (I use Wine on Linux, for example). It won't be “clearly marked” because the backend is Electron on top of Chromium (WEB BROWSER)... Eg it is stored as if it were “stored” inside Firefox or Chromium or Chrome's “data storage for localhost” kind of crap. This is one of the reasons I despise this “call it an app” shit-phase and “web-based apps” garbage. It might also have been in LOG format in Local Storage, I can't recall. (What looks like a .log file is the actual save file or some shit, been a long while.)
Fair enough! I'm not a programmer or developer or anything, so none of this kind of stuff makes much sense to me. The most I do is use Notepad++ to edit the content of twine/sugarcube based games. Those are in plain text at least, and the coding is pretty straightforward.
I set up a PFX (ignore) and managed to see the only file with the name used for a character I created in
AppData/Roaming/tits/IndexedDB/file__0.indexeddb.leveldb/000003.log, so I did indeed forget that it was in the browser LOG formats. Don't bother trying to extract them, pain in the ass. Just export/edit/import, far cleaner that way. You can also enable cheats by creating a new game OR loading a game and *THEN* clicking on the “i”'s top part after opening the Escape menu. You'll see “Cheats have been enabled.” to the top-right. Somewhat limited options, it appears, but it is something of an in-game.Why not just play the game in your browser then?
I don't play games, I remove DRM or debug issues for people. When testing, I'll use Wine (I don't use Windows) if I need to know something specific to Windows implementations, such as save file locations and all.
Honestly go onto the bug report forums and report it. I've seen a couple of reports, including my own, so the more people report it the less they can ignore it. In theory. In practice they probably will ignore it anyway, but I'm allowed to hope.
If I recall, you should be able to go into the options and change text size. Use Accessibility from within Android to magnify the screen after installing, set your size?
To clarify, I believe the issue they're talking about is with tooltip pop-ups that provide some context as to what different choices can lead to. They've never worked right for the js Android builds, either popping up for a literal instant or not popping up at all. The game probably expects a mouseover event that a touchscreen can't really provide. The issue is also present when opening the HTML file directly in an android browser, as I've tested it on Chromium
The CSS/JavaScript can be extended too by simply binding to touch events...should easily be fixable. Provide an example (exact scenario and instructions, and aim around the beginning of the game or a save file), maybe I can make a universal patch tonight.
I'm not 100% sure what you're looking for but hopefully this works. I've included two separate scenarios just to be sure. Apologies for the probably dumb question but are you looking to patch the actual .apk build? Or is this a "you have to use the HTML file from the windows build in your mobile browser for it to work" kind of thing?
I figured, but didn't want to assume.
Excellent. If you want, I can help you test that when it's ready (the android fix, not the linux script.) Thank you so much for looking into this, it's been the bane of android users for so long.
I found the issue, they're using onMouseOver, specifically:
return u.createElement("div",
{id:n,
className:e,
title:t,
style:{fill:o},
"data-header":this.props.statusEffect.storageName,
"data-body":this.props.statusEffect.tooltip,
"data-iconclass":this.props.statusEffect.iconName,
"data-remaining":this.props.statusEffect.minutesLeft,
onMouseOver:function(){return window.setTooltipElement(n,
Wu.SU.STATUS_EFFECT)},
onMouseOut:function(){return window.setTooltipElement(null,
Wu.SU.NONE)}},
a,
u.createElement("span",
{className:"focusBorder",
tabIndex:"-1"}))}}]),
o}(u.Component);I think hold+drag off is how it used to work in the old flash apk builds. That'd be my personal preference rather than having to tap twice, but beggars can't be choosers.
Almost exclusively depends on WebView, browser-backend stuff. Google just does whatever the fuck it wants and expects the world to twist. Working out different methods to test. Currently, I've got it to work, except now it doesn't go away unless you click a button. So you can check each button, and they'll just keep showing up multiple. xD It's a slow bitch patching, signing, deploying, installing, launching, testing.