Activity for Hex-a-hop
-
Rolf Sander posted a comment on ticket #6
Thanks for your feedback, Paul! My approach is basically the same as what you had planned: First, decompile levels.dat back to some readable ASCII files. Then, write a level editor that works with these ASCII files. So far, I've been able to locate the individual levels in levels.dat. Inside each level, I can see the hexagonal map (more details below). I can even change individual bytes in levels.dat and get different tiles when restarting hex-a-hop. What I'm still struggling with are the bytes before...
-
Paul Wise committed [9ac17e] on Website
Add title attributes to the screenshot links
-
Modernise the AppStream file
-
Replace YouTube video with links to the auto-generated channel and search
-
I inherited the project from the original author @amuzen, unfortunately they didn't document the format apart from the source code in packfile.h and they didn't release the source level files. I have been meaning to decompile levels.dat back to some sort of source level files and then delete the levels.dat file from git, but I never got around to it. Looking at the code, I see there might already be some form of level editor that is enabled when you define an EDIT macro, and I got it to compile and...
-
Level editor for Hex-a-hop
-
Guillem Jover committed [67a744] on Website
Update programmers and current maintainers
-
Move comma outside the link href
-
Remove trailing whitespace
-
Update URLs to https or archive.org links
-
Update source code URL
-
Stephan Sokolow modified a comment on ticket #5
Is there a command-line validator tool for the format I should use? Yes, but the upstream maintainership situation is... less than satisfactory and it's no longer in sync with the published spec. (eg. It'll reject valid <description> markup with confusing error messages and reject valid <url> types, among other things.) The fork you're supposed to use is available as: flatpak install flathub org.freedesktop.appstream-glib flatpak run org.freedesktop.appstream-glib validate <FILENAME> EDIT: They also...
-
Is there a command-line validator tool for the format I should use? Yes, but the upstream maintainership situation is... less than satisfactory and it's no longer in sync with the published spec. (eg. It'll reject valid <description> markup with confusing error messages and reject valid <url> types, among other things.) The fork you're supposed to use is available as: flatpak install flathub org.freedesktop.appstream-glib flatpak run org.freedesktop.appstream-glib validate <FILENAME> They also want...
-
Is there a command-line validator tool for the format I should use? Yes, but the upstream maintainership situation is... less than satisfactory and it's no longer in sync with the published spec. (eg. It'll reject valid <description> markup with confusing error messages and reject valid <url> types, among other things.) The fork you're supposed to use is available as: flatpak install flathub org.freedesktop.appstream-glib flatpak run org.freedesktop.appstream-glib validate <FILENAME>
-
Is there a command-line validator tool for the format I should use? Yes, but the upstream maintainership situation is... less than satisfactory and it's no longer in sync with the published spec. The fork you're supposed to use is available as: flatpak install flathub org.freedesktop.appstream-glib flatpak run org.freedesktop.appstream-glib validate <FILENAME>
-
Is there a command-line validator tool for the format I should use? Yes, but the upstream maintainership situation is... less than satisfactory and it's not longer in sync with the published spec. The fork you're supposed to use is available as: flatpak install flathub org.freedesktop.appstream-glib flatpak run org.freedesktop.appstream-glib validate <FILENAME>
-
Is there a command-line validator tool for the format I should use? Yes, but the upstream maintainership situation is... less than satisfactory. The fork you're supposed to use is available as: flatpak install flathub org.freedesktop.appstream-glib flatpak run org.freedesktop.appstream-glib validate <FILENAME>
-
On Tue, 2022-09-20 at 00:43 +0000, Stephan Sokolow wrote: It's a bit incomplete. Aside from me being a completionist and a perfectionist, I'm not sure it'll pass validation, Is there a command-line validator tool for the format I should use? You'll probably see me offering up a patch to expand your Appstream XML out to something like [this] Great, thanks. Speaking of which, would you like me to add a [bugtracker] element to the Appstream XML for Tomatoes when I add the x-checker-data definitions...
-
Please do. There is an Appstream XML file in the upstream git repo already, hopefully it is suitable for Flathub too. It's a bit incomplete. Aside from me being a completionist and a perfectionist, I'm not sure it'll pass validation, since I think the validator wants at least one <release> element so it can surface them in the upcoming UI redesign being demo'd at beta.flatpak.org. (I've fired off a request to relicense the release text from Tomatoes to improve its entry on that front.) You'll probably...
-
On Mon, 2022-09-19 at 06:58 +0000, Stephan Sokolow wrote: No problem. As long as you're OK with it, I'd be willing to put together a build manifest and Appstream XML for it. Please do. There is an Appstream XML file in the upstream git repo already, hopefully it is suitable for Flathub too. Would you prefer I put something up on my personal GitHub account for you to review before I do the "fork new-pr on flathub, put your submission in it, open a PR, and let them review it" dance and involve a submission...
-
Thanks for the suggestion and sorry for the delay in responding. No problem. Since Flatpak is a packaging system I think that the packaging files should be maintained separately to the upstream project. The appropriate location would be where separate Flatpak packaging is often stored. For Flathub that seems to be in a git repository in the @flathub organisation on GitHub. Yeah. They have a couple of bots tied into it for automatic "bump dependencies" PRs if you define how to check for updates, test...
-
Thanks for the suggestion and sorry for the delay in responding. No problem. Since Flatpak is a packaging system I think that the packaging files should be maintained separately to the upstream project. The appropriate location would be where separate Flatpak packaging is often stored. For Flathub that seems to be in a git repository in the @flathub organisation on GitHub. Yeah. They have a couple of bots tied into it for automatic "bump dependencies" PRs if you define how to check for updates, test...
-
Thanks for the suggestion and sorry for the delay in responding. I agree that it would be useful for Hex-a-Hop to be available on Flathub for folks who use immutable systems like Fedora Silverblue or SteamOS. Since Flatpak is a packaging system I think that the packaging files should be maintained separately to the upstream project. The appropriate location would be where separate Flatpak packaging is often stored. For Flathub that seems to be in a git repository in the @flathub organisation on GitHub....
-
Also, I forgot to mention, but it's likely the reason such games have been showing up on Flathub lately is that, by default, the Steam Deck comes with a read-only OS partition and Flathub support, so uploading to Flathub is sort of like submitting to F-Droid, but for the Steam Deck.
-
Consider uploading to Flathub
-
Assorted cleanups in preparation for SDL2 port
-
Merged the new branch, thanks!
-
Lets defer the cmake removal for now.
-
Re the SDL_endian.h changes, yes, every change here compiles on its own. Notice how the SDL.h inclusion does not use SDL/, as the include path is passed to the compiler. Re FATAL, I'll add the spacing. And as mentioned on IRC, I did the refactoring later as to make it easier to have a minimally backportable fix for Debian, but I can create the proper changes for upstream. Re cmake, right I wondered that too, but given that at least for APPLE this will simply not build there, I'm not sure this has...
-
Looks good, a couple of thoughts/questions: Is the SDL_endian.h change compatible with SDL 1.2? The FATAL merge should probably have some whitespace before the #endif. I would move the FATAL commits before the SDL_Init commit so that the commit checking the SDL_Init return can be eliminated in favour of the one making it use FATAL. I'm not sure about the cmake removal, since cmake is a lot easier to use on non-Linux platforms than autotools.
-
Assorted cleanups in preparation for SDL2 port
-
If you know how to compile from source, then you can manually build and install it...
-
real name complete created ticket #4
please need a appdata install
-
Fixed in git, thanks.
-
Please create an AppData file for Hex-A-Hop
-
Add AppData file
-
Richard Hughes posted a comment on ticket #3
Please consider improving and installing this AppData file we wrote: https://raw...
-
Please create an AppData file for Hex-A-Hop
-
Wrong FSF address in source file headers
-
status: open --> closed
-
Fixed in git, thanks for the report.
-
Fix the FSF address in various files.
-
Mario Blättermann created ticket #2
Wrong FSF address in source file headers
-
Also ignore the compile script from autotools
-
I would suggest you should strip them from the release tarballs. For the next release...
-
OK, thanks for the info. I'll remove the *nonfree files after installation so that...
-
The provided XML files list which license the data files are under. The files with...
-
License of "nonfree" files
