You are right.

Databases do that very well and RW is somewhere deep down a database.

Making sure that it catches all the abuse we would throw at it would probably be anything but trivial; as you say.

Exactly, you could even store it in a file and just have a table that monitores access. Anyway, technically it is pretty standard fare.
On the other hand, I don't know at all how RW works internally, how graphic objects - or any other media/files - are stored right now. So I can't make a sound assumption of the amount of work needed to change this.

In an Export XML Images are Nodes with the Base64-Encoded Image. Right now they are nested into the Branch where they are embeded in the Article, but it shouldn't be very complex to extract them from there and just add them as a reference like they already do with internal links. Most of the work would be the Gallery Viewer which have to be added to make this useful for the Users.

In databases images are pretty much always stored as some variant of a binary data type. That is they are simply a complete image of the original file. That keeps things simple for everyone involved. Other programs know how to consume the file without any special processing and the DB itself doesn't need to do anything special to the field either on input or output.

Switching it around so that images are stored in one central spot and other topics simply link to that repository would require a reworking internally of how RW handles images but if they wanted to do it, it could be done.

I still question how much gain would be had from the effort it would take. I doubt many people actually reuse images ever in a realm.

Not sure about that, either.

But I am currently contemplating on how to mark the locations (crime scenes, whereabouts of persons of interests etc.) of a police procedural campaign within my realm. In this case reusing the city map (even with some of the pins conserved) would be very handy.

I don't know how many Users use the same Picture in many Articles, either.
But for me I cannot imagine how to make a good, in-Game readable, Adventure in RW without doing this. We are all used in using Adventurebooks where we needed to browse through the Pages to find the corresponding Image for a NSC or a Location. It would be very sad not to take advantage of the possibilities we have by using a Digital Tool.
I want to use RW for both, manage and run Adventures. By now, Fantasy Grounds is better in running RPG, and RW is better in managing RPG. I don't want to use two tools for this cause I have to do everything twice. I like RW for it´s flexibility and would be very happy and glad if RW (after the launch of the Content Market) will focus on running Games and thus can stay competitive against similiar Programs.

Maybe you're using RW in an unusual manner. Could you describe how you use the images that you feel you need to have in multiple places.

Sure. Maybe the best way is to descripe it with something we both know, the Pixies on Parade Adventure.
In B7 "Lost and Found", I would've integrated all the Images from Edwin, the Items (Stuffed Bear, Ring, etc) and added some Images (like one of the Fairy Godmother) which I believe will come handy in-game.

It's just because, in-game it took me too long to open a link in a new Tab, go there and open the Image I need and then share it to the Player-View.

Sure, it is already possible, to show every Picture I want to on demand and it is a whining on a High Level, but I like it if GM-Tools need less fokus from me In-Game as possible.

To compare it with a traditional Situation. When I run a Session with real Paper, I tend to print every Handout which I will possible show to the Players before the Session starts so I don't need to browse through the Adventurebook In-Game.

The other Reason to me to like a feature like this are my plans how to use RW in the Future. I am on my Way to put all the Informations of the Forgotten Realms into RW. So I will have an Article for every City and Place some Time in the Future. So when I create a new Adventure in, say Deepwater, I would create an Entry for Deepwater in this Adventure with only the Information I need for this particular Quest. The Main Article for Deepwater will have many many Images, and some of them I will need in my Adventure and others not.

Maybe I am alone with this, but independent of the Fact someone really uses the same Pic in different Places. For me as a Developer also, it just makes sense to handle imported Ressources this way. It leaves much more flexibility to future Extensions of RW. Just think about the possibility to create a Towndescription with the whole Town and the different districts in seperate Articles and we can just use the same Overall Map linked in all the Articles with different cutouts (Sure this is not as easy as the first step, but the first step opens the possibility to do something like this)


Sorry for my grammar, I will never get the Upper- Lowercase syntax in english :o

Player view is clunky. I'll give you that. I've over come it by planning ahead and getting a better laptop. Those may not be options available to everyone I'll grant.

I wholeheartedly agree with Thalamus. Of course RW works as it is, but it's clunky and takes a lot of time that you don't necessarily have during a game session.

For me it is often the pictures of NPCs and Monsters. I have a scene with several known NPCs or a fight with several enemies. Now I need to open all the corresponding topics for the persons or monsters and push all the images to the player view. Especially with a notebook that's geared toward mobility instead of performance, this can take a while.

I know I could prepare and pre-load all needed images in the player view before the session, but I experience crashes and unresponsivness if I have too many pics in the player view. Also, players not always take the path I intended for them...

Last note: I don't know how the different tiers for cloud storage will be defined, once we have to pay for it, but if it is based on disk space it would be customer-friendly to include ways to minimize the amount of data.