Images in Log Entries and Generator Outputs

ELF

Generator Sage
Staff member
CL Add-on Dev
#2
Thunder! :love:

Please note that in generator output you need to escape the double quote characters " around the URL by adding a backslash character \ in front of the quote characters. Like this:
Code:
 "resultPattern": "{\"https://campaign-logger.com/img/icon.png\"| CL Icon |img}"
 

ELF

Generator Sage
Staff member
CL Add-on Dev
#4
Here's a simple image-based inspiration generator:
Code:
{
  "resultPattern": "{\"https://loremflickr.com/320/240/{lib:concept#summary}?{dice:1d100}\"||img}{\"https://loremflickr.com/320/240/{lib:aspect#summary}?{dice:1d100}\"||img}{\"https://loremflickr.com/320/240/{lib:concept#summary}?{dice:1d100}\"||img}"
}
This oneliner randomizes a concept, an aspect and another concept and fetches a random image from LoremFlickr.com based on those keywords.

The d100 roll parameters in the end are just to avoid repetition by browser cache, should the same concept or aspect repeat within a short time frame.

The result is just a silly thing like this:
random image generator.png
Sadly using Pinterest boards or Game-icons.net for this is a bit more complicated.
 
Last edited:

ELF

Generator Sage
Staff member
CL Add-on Dev
#7
This is just a proof of concept, and would require quite a many more tiles, better matched. Still, this could lead into something.
random cave generator.png
 

ELF

Generator Sage
Staff member
CL Add-on Dev
#10
Thanks! Indeed I had something like Dave's Mapper in mind. Those tiles come from the open source Pymapper tool, but unfortunately the tile set did not suit the intended purpose as well as I had originally thought.

Another issue that I encountered was that many image hosting service do not allow hotlinking like that, and even those that do can have strict access quotas. It would be great if the Campaign Logger server could at some point have an HTTP accessible image directory that the public generator library could use.

And even more ambitious dream would of course be if a CL log could contain (or access) also each user's own graphic assets - things like NPC portraits, for example. I experimented with linking images from my Pinterest account and Dropbox, but that was cumbersome.

But until that, Free Image Hosting seemed to work nicely for my small-scale testing purposes.
 

JochenL

CL Byte Sprite
Staff member
CL Add-on Dev
Wizard of Adventure
#11
I can set up an image hosting directory. But we would need to add a license file for each image with:
  • Name of the author
  • Source of the image
  • License under which the image is used
 

ELF

Generator Sage
Staff member
CL Add-on Dev
#12
But we would need to add a license file for each image
That could be done. A separate text file for each image, reflecting the file name.

To make randomization easier, there should be a simple directory structure and file names that match the conventions of the generator library should be used, perhaps ending with a randomizable number.

Maybe something like this:
Code:
https://campaign-logger.com/image/portrait/human/modern/female/middle_class/adult/1.png
https://campaign-logger.com/image/portrait/human/modern/female/middle_class/adult/1.txt
The actual file name can then be formed from variables such as species, genre, gender, social class and age, plus a die roll.

Alternatively, some of that deep directory structure could be replaced with file name components, perhaps it would be more convenient for managing the image bank?
Code:
https://campaign-logger.com/image/portrait/human/modern/female/middle_class-adult-1.png
https://campaign-logger.com/image/portrait/human/modern/female/middle_class-adult-1.txt
I can handle that and curate a small selection of public domain or permissively licensed images.

Let’s start small and see what works best.
 
Last edited:

ELF

Generator Sage
Staff member
CL Add-on Dev
#16
@ELF Could I trouble you to update the Cheat Sheet with the image command?
Done, also the image syntax has been updated to the cheat sheet.

@JochenL, would it be possible to pass through also HTML img parameters, at least for scaling? The vector-based svg format would be a flexible choice, but would really require scaling for most purposes:
(I thought it best to start with generic icons, as they probably have the most use cases. With character portraits it might be possible at some point to use a dynamically customized vector images instead of a vast library of bitmap images.)
 
Last edited:

ELF

Generator Sage
Staff member
CL Add-on Dev
#18
Can you show me an example of what you want to see in the resulting HTML?
Here's a sample of an earlier effort utilizing Unicode symbols:
CL graphic inn stats.png
But the problem with Unicode is (as is apparent in the above example) that it is not uniform, i.e. the end result depends on the user's fonts and other environment factors and all (or any) symbols may not be displayed at all - see the Authority line.

Other use cases could be stats in card-based systems such as Castle Falkenstein and maybe some day even something approaching what this sheet would look like when filled in (not the best of examples, though).

Currently, without scaling, the SVG-based stats look like this:
CL SVG images.png
 

ELF

Generator Sage
Staff member
CL Add-on Dev
#19
Stock image style

One of the problems, especially when using free assets, is achieving a somewhat uniform style. Should the images resemble modern iconology (like traffic signs) or a more historical style, be black and white or colorful, cartoony or realistic, etc, drawings, paintings or photos, etc.

Opinions on this?
 

ELF

Generator Sage
Staff member
CL Add-on Dev
#20
Mapping stock images to variables

I think it could make sense to make the use of these stock graphics easier, as the current syntax is a bit long-winded and there is no handy way to automatically list the current contents of the Campaign Logger image bank.

One way to do that would be add an additional mapping layer between the image URLs and the user. That could be done by initializing a set of global variables that contain the path to the image files stored on the Campaign Logger server. It might also make sense to enable declaring these variables per image library type, as it may not make sense to declare every variable if for example playing card images are used.

My current image collection falls into the following categories:
  • card: card faces (for card-based systems)
  • icon: abstract icons for stat blocks (indicating points of interest, elements to be filled in, high values, etc.)
  • item: symbolic item icons (like coin images for price level indicators)
  • location: generic landscape images (not sure how useful this would be)
  • map: mapping symbols (gazetteer log entries or map generation)
  • meta: off-game symbols related to rules (various dice, pencil, etc)
  • ornament: beautification elements for log or generator content to match a genre (like Victorian swashes and other dividers)
  • portrait: generic character portraits (again of dubious usefulness, as achieving satisfactory coverage is a pipe dream really)
(Anything else coming to mind?)

The image bank initialization generator could set also the default image size per each image bank, so that it would be easier to change the scaling later on. Perhaps it could even set several alternative sizes per image bank (like small, medium, large) and then set one of them as the default, making changes even easier. It would make sense to make this setting image bank specific, as it is probably desirable to set the small size for a die image different than for a portrait image.

In generator use, these image banks could then be initialized by calling for example:
Code:
{lib:init-imagebank#icon}
Or, for the omnivorous, why not:
Code:
{lib:init-imagebank#all}
This would initialize global variables that would, when used in text, be replaced with the related inline image. Like this:
Code:
Price level: {g:img-coin}{g:img-coin}{g:img-coin}
CL graphic price level.png
(image simulated with incroyable Illustrator skillz)

It may be good to use the img- prefix in the variable names, or what do you think? {g:coin} would be easier on the fingers and eyes, but the user could need a text-based variable named like that.

Also: a related feature request pops up: should the logs be able to utilize global variables as well?
 
Last edited:
Top