I think you have to specify the full path to the folder.
Probably not, but keeping games in one folder is a good idea in my opinion
I think you have to specify the full path to the folder.
Probably not, but keeping games in one folder is a good idea in my opinion
Sorry for not posting so long. This post is just to let you know that I am still working on it.
There are a lot of things that need to be done:
Many things to do. So, I apologize for starting the hype and then not giving anything to play with
Please do stay tuned. I will try to get something out as soon as my other commitments (day job, family, etc.) allow.
Limited access to folders is the worst thing about Android. Itâs like the mobile computing powers that be want to make each file accessible to only one app, undoing the 40-year-old file-centric computing paradigm. I have a half-dozen IF interpreters on my phone. Why would I want to have that many copies of each story file?
While I do somewhat agree, I also see the reason why they went into this direction. For example, Fabularium as an app, could access all sorts of data from other apps. If those other apps would implement some sort of tamper or encryption protection by default there would not be a problem. But many donât.
There is an important warning in Fabularium that you should not point it to a system directory⌠It might inadvertently destroy important data on your system. That warning is not needed any more: it is already prevented by the system.
To us, this is a nuisance. However, lotâs of users just click âI agreeâ and âOKâ to give a shady app access to everything on their phone. Fabularium and Fictionarium are open source, anybody can see what the app is doing and shady actions are at least somewhat discoverable (hopefully not at the mercy of the same exploit as xz fiasco).
All of the apps in Play store go through a review process but itâs not whitebox: they only test what happens in certain scenarios. If an app asks for readwrite access to all the data on the phone they might review most scenarios where itâs ok, but a shady app could hide its nefarious intent from them. So, their review process would require whitebox review, which is about 10x more difficult than blackbox with just a few permissions and removing the ones that are really problematic to review.
Long story short: I understand and mostly agree with what they did. Even if it does make my efforts a bit harder.
I would like to know, though, why do you have so many interpreters installed? What is missing in Fabularium that you want to use a different app? It wonât be soon, but I do take feature requests for Fictionarium and maybe we can address your use cases in future releases.
Keep all your story files in an app subdirectory. Attempts to access any files outside is a world of pain.
Theyâre not very big anyway, and can be regarded as an offline cache. Perhaps allow a cache size option. The app will just delete the oldest as required and download on demand.
Only if there is a way to turn this off, or maintain persistent files separately. The ability to load and retain custom story files (that may or may not be on IFDB) is very important to anyone using the app for beta testing, etc.
Good idea. or allow the âsizeâ to also be âunlimitedâ.
I second this. Apps should never assume Iâm going to be able to get stuff online, and certainly should never delete stuff without my consent.
Does anyone know what Scott Adams game format is supported in Fabularium? The wiki says that the interpreter supports the scottfree format, but it doesnât open the corresponding dat files.
Looking into it now, but I have a guess what the problem is.
As discussed above, Fabularium depends on IFID to create each gameâs /GameData
directory.[1] When I use the âAdd to Game List (manual)â option and fill in the IFID field, the game is successfully added. When I use âAdd to Game List (auto)â, however, Fabularium adds the .dat file to its /Games
directory but doesnât create the corresponding /GameData
directory, so the game never appears in my library.
I havenât double-checked this, but itâs the most likely explanation I can think of.
This already causes problems when testing multiple versions of a game, or if an author mistakenly reuses an IFID: Fabularium canât add a game with any IFID that already has a /GameData
directory. âŠď¸
I checked, this method works. Thanks!
Glad to hear!
If you ever figure out how to use Fabulariumâs alleged support of HTML games, let me knowâthat one Iâm still stumped on.
Well, I think your way works great for html games as well. Unzip some twine game, specify the format âhtmlâ and youâre done! I havenât figured out how to save yet, though. Perhaps it depends on whether the game itself has such an option.
Huh, really? I can add the games to my library, but every time Iâve tried to open one, the app has immediately crashed.
Sounds like that might be an issue on my end rather than a general Fabularium issue, then.
Yeah, I was surprised, too. It all comes out so easy. Are you using the latest version? Check the error log file. Maybe itâs the file itself?
Hm. Just tried downloading a different twine game, and oddly enough, this time it worked! Maybe I did something to mangle the ones I was testing with before? Ah well, at least it works now.
How is this project coming along? Iâm certainly excited by the idea. Fabularium is okay but itâs got a lot to work on, and that isnât going to happen anytime soon but Iâm glad this is happening.
(Also, my next game is written in z-machine and no Android 'terp can support it without changes.)
I was using the BEBEK terp for Adrift 5 games a lot. (Scare is only for Adrift 3 and 4 games which BEBEK is not good for) It is quite good for most games but a few games do not run properly. I understand that it was not based on the open source code of ADRIFT 5 which can probably explain the deviations. Would be great if Fictionarium could improve on this.
Indeed my progress is slow. In the past two weeks itâs been superseded by my day job (I work at a startup and itâs really hectic at times).
That said, itâs been a month since I started the thread. In the mean time I have been cleaning up some of my work, that was made just to make it run on my phone and was not releaseable.
I hope to have an experimental version out in the next few days. And, by experimental, I really mean experimental. It would help me if you try things out, but there might be some severe regressions that I failed to notice. So, once itâs out, please donât yet rely on it. I will be working towards stabilizing it, but getting a 5+ year old project off the ground is always challenging.
One more question: I ported the code to use the same version of garglk as is in use in F-droid with the addition of @Keltena 's fix. That base is 1,500+ commits behind official garglk. My long term plans are to bring the garglk base up to date, but since modification were made on to the base, I will need to figure out how to ease that integration in the future (that will take time but being a backend engineer with 20+ years of experience, many of those in C, that will feel like home ). So, finally, my question: what modifications are needed? Would the latest garglk run your code?
Yes, terp updates are in my plans. As mentioned in my previous comment, I do intend to bring the latest garglk into the base, but even that will take time. The bebek code base and changes there are still an enigma to me but will keep it in mind.
As soon as I organize the base of Fictionarium at least somewhat I will open an issue to address this. Will probably not be soon so please be patient with me