Suggestion: Enable the web version to read local game resource files or large ZIP archives or tell me what is the 'http://localhost:4200/qspider_files/' path

[velade]

The current web version is unable to load resource files (such as images, audio, etc.) from an unpacked game directory, or at least, I cannot find any instructions on the correct way to do so.

Furthermore, when attempting to load large ZIP archives (e.g., games like ETO FemLife, GirlLife, which can be over 10GB), the upload fails silently. There is no error message or any indication of failure; it's as if no file was selected at all.

I am aware that the Desktop client handles this correctly. However, my primary need is to run these games in a standard web browser for translation purposes. This is a critical feature for me, as QSP is one of the few game engines that is difficult to use with machine translation tools. The main reason I use QSpider over the traditional QSP Player is its web version, which I hoped would allow me to use browser-based translation extensions.

This has created a dilemma: the Desktop version, which can run the games, lacks a built-in full-page translation feature. Meanwhile, the web version, which would allow for browser-based translation, cannot load the games with their assets, rendering it displaying only plain text. I am hoping this problem can be solved.

I've noticed that the player seems to have a solution for external resources, using an @fs to load them. Perhaps a similar approach could be used to load the game's resources directly from the local file system? This would be better than the current behavior of trying to find resources under a path like http://localhost:4200/qspider_files/xxxxxxxx/. There are no instructions explaining where this directory is, so even if I wanted to manually place the resource files there as a temporary workaround, I am unable to do so.

[srg-kostyrko]

On desktop there is direct access to file system
In browser however it is limited due to security reasons. There is a new API that can potentially provide such access (but only recently it got support in all major browsers) but I'll need to experiment to see if it provides enough capabilities to use in web player.
Cannot promise though that I would be able to do it anytime soon.

The problem with big archives is most likely related to memory limits - as it needs first to read the whole file into browser memory and than also unpack it into memory for furher processing.

as for http://localhost:4200/qspider_files
web player uses internal browser storage called IndexDb to store files extracted from archives and then serve it using service worker
there is no direct place on file system where you can just put files for it to be able to read it
and I don't know any easy way to do it somehow else - IndexDb is per site so to interact with it you need to run script from corresponding site, and there you also have the brwoser limitations on file system access

[velade]

Thanks for your reply. In fact, there are several potential solutions to this:

1. The new API you mentioned: This is clearly the best approach. As I recall, it's an API that grants temporary read/write permissions to specific local files upon user approval, which would be perfect for this feature.

Correction: I've researched this API further, and while it can fully meet the requirements, I no longer believe it's the optimal solution.

The reason is that it's somewhat analogous to Node.js's fs module—it operates directly on files and folders. While this solves the problem of file access, it doesn't provide a simple way to map the resource paths that the main QSP file requests. You would still need to implement a file proxy to intercept and handle these resource requests, which undoubtedly increases the implementation complexity.

However, the biggest issue is that Safari considers the API a potential security risk and currently has no plans to support it. Furthermore, Firefox is not fully on board with the feature either, so cross-browser compatibility would be a major headache.

In comparison, solutions #2 and #3 (from the previous discussion) are far more reliable alternatives.

2. Mapping the game path with @fs: I noticed that the application already makes requests like http://localhost:4200/qspider_files/@fsG:\qspider-main\libs\xxxxx. Would it be possible to map the game's root directory using a similar @fs<local_game_path> syntax? Even if this requires the user to manually enter a "Work Path," it's far better than the current inability to load these games.

3. Using a local program directory for game storage: Perhaps the simplest solution is to store games in a dedicated folder within the application's directory. When a user uploads a game, it could be copied to a path under qspider-main for long-term storage, backup, and migration. IndexedDB not only has significant size limitations but is also difficult to back up and move. You could create a local library system, similar to how Steam operates. The official online version you provide could continue using IndexedDB, but with explicit game size limits to conserve your storage resources. Relying solely on IndexedDB will never fully solve the problem for large games. (On a side note, I recall that MEGA also uses IndexedDB, and it seems to handle downloading more than 10GB archives without any issues?)

4. Leveraging the desktop app as a backend service: The desktop version could be extended to run as a local server. All heavy processing and file I/O could be handled by the desktop application, with the rendering component being served to a webpage that the user can access in their browser. (This is actually very similar to the default behavior of npm start. Since QSpider is essentially backed by Node.js, I believe this should be achievable. It would just require inter-process communication (IPC) to exchange data, with all file I/O handled by the Node.js backend, which could easily use the native fs module to resolve any cross-origin issues).

5. Adding a translation plugin to the desktop version: A more direct, but less ideal, solution would be to integrate a translation plugin directly into the desktop version's embedded browser view. I don't recommend this, however, because a standard web version offers much more flexibility. User needs aren't limited to just translation; some might want to use browser extensions for image magnification or other functions. Therefore, this solution isn't comprehensive and feels more like a patch than a proper fix. It's feasible, but not the recommended path.

[srg-kostyrko]

The new API you mentioned

Just to align I was talking about https://developer.mozilla.org/en-US/docs/Web/API/File_System_API
Safari already supports it (to some extent) and I have not seen any articles about its deprecation
But as I said I would need to test if it aligns with what is needed and if everything is supported across major browsers
Additional proxy work should not be needed as I already do kind of proxy in service worker that serves files from IndexDb so just some adjustments needed to use API instead of IndexDb

Mapping the game path with @fs

I don't remember implementing anything like that. Most likely that is something related to bundler that works only while launched on local machine. I don't want to introduce any dependency on launching web player locally

Using a local program directory for game storage

this is how desktop version works, but for web version again same issue - browser restricts access to file system (except for that new API)

Leveraging the desktop app as a backend service

there is no actuall server there that can be accessed outside app itsel, and no direct way to introduce it

Adding a translation plugin to the desktop version

Right now library used for desktop player does not have any translation plugins yet

To sum up - ideally would be to use new File System API as it seem to require less effort and would be easier for end users as it won't require any additional

[srg-kostyrko]

I thought about a workaround that you can try using right now - it just requires a bit of setup on local machine

Web version supports launching game from some external url like this
https://qspfoundation.github.io/qspider/?game=https://aleksversus.github.io/merphy_law/game/merphy_law.qsp

So for any big game that you have you can try running a static http server in its folder
for example if you have nodejs installed run this command in folder with game

npx http-server --cors -p 8080

after that you can try launching game from locally running web version
http://localhost:4200/?game=http://localhost:8080/game.qsp

just replace game.qsp with correct name of file game

[velade]

Thank you again for your patient reply. I haven't tried the temporary solution you proposed yet, but if it works, I really think it should be added to the README. There are so few discussions about Qspider that I wasted 4 hours on Google but found nothing. Finally, I chose to submit a feature request here because I know it will take time to request the addition of a feature.

I'd like to explain my thinking below, as I think your understanding may be somewhat off.

Mapping the game path with @fs

This is the request path I captured through the debugging tool. It is indeed implemented on the local web.

Using a local program directory for game storage

What I mean is that by placing the files in a directory accessible by the web server, such as the root directory of the HTML generated by the QSP (or you can generate the converted HTML directly in the same directory as the QSP). This way, there will be no cross-domain access issues. The QSP should be a relative directory and can be called directly without any additional steps, just like the IndexDB you use now, which essentially places all files in a "website" for access.

Leveraging the desktop app as a backend service

I mean, it's similar to the current npm start (nx serve player) approach, except that more processing is handled on the backend, rather than the web server. Since Node.js has far greater authority than the web server, using the Node.js backend as a file proxy should solve this problem (it's actually the same implementation as the API, except one provides file access through the browser, while the other is provided by the Node.js backend).

I'm not familiar with Qspider's specific implementation, so I'm not sure whether modifying the desktop version or npm start (nx serve player) is more convenient. I'm just thinking that since the desktop version already does all the work, adding a backend server to send the rendered and parsed content to a purely front-end server responsible for display shouldn't be difficult. Of course, I might be misunderstanding this, and modifying the desktop version might be more complicated.

Finally, I fully understand and support that the Web side should not be dependent on local functionality, but can actually think in turn that my own demand is actually the local need for an Web interface, just like my proposal to let Desktop provide a web portal. My core need is actually to use the functions provided by the browser (including full-page translation and extension, etc.), online use is certainly best, but if not, then running a backend locally is also perfectly acceptable. After all, English games can be said to be more general, but Russian ... after all, not so popular, but QSP is the Russian favorite VN / SLG engine, games are also Russian-language more, machine translation is a not a niche demand.