Syndaryl / DFRPGRandomDungeonGenerator

A HTML/CSS/JavaScript based random dungeon generator for GURPS. Eventual goals are to not only produce a map, but also populate the rooms with descriptions and challenges. Game statistics will be for the DFRPG / GURPS 4e.
Other
35 stars 13 forks source link

How to handle modifiying data files on the fly? #64

Open Celti opened 6 years ago

Celti commented 6 years ago

So recent discussion of this app on the GURPS forum thread suggests people:

  1. Want an easy way to tweak the data the generator uses, and...
  2. Want this to work on a remote/non-self-hosted copy of the generator...
  3. May or may not be comfortable directly editing Javascript to do it.

The first point is obviously already served by simply replacing the files in data/.

For the second, my initial thought was to simply tweak things to allow injecting replacement data files via an "upload" form into localStorage, but that doesn't satisfy the third point.

For all three, I see a potential path in the following:

Does anyone see any huge flaws in this idea? Anyone have a counter-proposal? Is this a subject that is better left to lie?

Syndaryl commented 6 years ago

I was setting them up as actual JSON in the beginning but JS is not my home language, and I could't figure out how to load the files from within the browser sandbox without uploading them every time, which is frustrating. Changing the data files used for your session on the server via a gui sounds good but either you re-enter your settings every session, or we have to work out something to retain them (and there's way too much data for the limited set of in-browser storage tools in my skillset, like cookies). Options here that I can see are: provide a file package (zip) to the user to re-upload next session, save in browser via stuff I don't understand, save on server. I kinda hate all the options equally.

Syndaryl commented 6 years ago

(to make it clear, I'm not against them, I just hate them on a personal level)

Celti commented 6 years ago

I was setting them up as actual JSON in the beginning but JS is not my home language, and I could't figure out how to load the files from within the browser sandbox without uploading them every time, which is frustrating.

The simple/modern solution there is to use the Fetch API and dump the resulting JSON into your desired Javascript object. Simply using a page-relative path to the various JSON data files should work equally well remotely or locally.

Changing the data files used for your session on the server via a gui sounds good but either you re-enter your settings every session, or we have to work out something to retain them (and there's way too much data for the limited set of in-browser storage tools in my skillset, like cookies).

When cookies are too small, you turn to the localStorage API. I'll see if I can't soonish turn out a few simple commits that will use/load from JSON, and then save/load overrides from localStorage as a start. See about interface after that works.

Syndaryl commented 6 years ago

We're using localStorage to save settings between sessions, but it doesn't work for me on any of the the machines I've tested. Which is not reassuring. Edit: as in my Firefox and chrome persistently insist they don't support it.

Celti commented 6 years ago

That's remarkably strange...

...okay, I'm now digging into a chain of issues.

  1. supports_local_storage() in dungeon_types.js will never return true. Fix queued.
  2. save_dungeon_configuration() is not called with the correct storage key to actually save the settings. Nowhere in the code actually calls it with any specific key, so wiping that out restores the proper behaviour. Fix queued.
  3. FetchStorage() is trying to return the first member of an array from localStorage, but the other localStorage wrappers all deal with objects. Fix queued.

...and it works now! See #65.