The dark popup window is what I am talking about currently. Especially with the dice icons being so small...
For reference, here is a ammo exploded mech...
Oh woooow, your screen
is monster! Thanks for posting!
Good news! I just checked and you can scale up the text size in that console (and in obligation strip) by just using your browser's built in size-adjust. On Chrome it should be 'view > zoom in'. There should also be a shortcut including '+' and alt/cntrl/windows key or similar.
I tried out the site on my tablet and have some similar scaling issues, though the lower resolution on my tablet helps. My tablet is running Chrome on Android 6.0.1 for what that's worth. One thing that would help both cases is to allow screen zoom to zoom in past full on the record sheet itself (and scroll across the sheet beyond X% zoom, or a check box to unlock the zoom). The current behavior of locking to the most restrictive dimension is understandable, but it can make it hard to show people without passing the tablet. Unless I'm missing something.
Gotcha. Sorry to pester, but more questions:
- What's the screen size and resolution on the tablet?
- Were you using FS in a browser window or after having added it to the home-screen and launched from there?
- What information were you trying to share specifically? [
Assuming attack results but don't want to make sure.]
Looking into re-enabling browsers' default pinch-to zoom behavior is on my mind for sure — there's just some other technical issues blocking this at the moment that I need to resolve.
Out of curiosity what are you using for a backend on this and what language/IDE are you programming in/with? I have a few web/app/program ideas and I'm working out which ideas will go which route.
The backend is extremely minimal (relative to the client).
There's a server for inter-client messaging is Node.js (running on Heroku). It uses Express and Socket.io. All it does though is dumbly route JSON messages to the right user and so is not complex, in contrast to an actual game where the game-state (or even game-logic) would be centralized on the server. I wrote it in straight JS using VSCode. The client can run without it.
The client also access a unit data catalog hosted completely separately in an AWS S3 bucket. The catalog is really just a limited fork of MegaMek files plus JSON translations (
https://github.com/IanBellomy/helm-core-fragment). Because I'm only doing name searches (using a pre-generated XML doc no less) there's no database to build and query. (The sheets' SVG representations are generated client side.) The client can also run without this catalog.
I do rely on PHP for performing a poor-man's 'import component html-template + style' but I do this as a build step, so the client is static and can run offline straight from a device.
Aside: Printing sheets / creating PDFs is handled
straight from the browser with some careful CSS and a trick or two 🤘, so there's no need to hit a server on that front either. Though Safari's @page support is bad©, so printing works way better in Chrome and FireFox.