Advice for sandbox GM

[A Social Yeti]

As best as i can tell FG seems to assume i got a planned Story campaign/offical module to run.

The scheme is everything flows out from Story elements, no encounter can be 100% self contained to include any and all needed text to go along with it. You can link a Story text to an encounter, but an encounter cannot link to any text or include any in it directly.

As a sandbox GM that flow don't work so well. There is no planed story the players have agreed to follow. I need to have points of interest and encounters as stand alone, including any text descriptions they may need, because no known in advance Story elements will get us there to provide any text to read to go along with it.

Sandboxing is like on the fly DJ mixing, you just pull out the create what you feel the room will vibe on most next. And you can't know what that is until it's time to queue it up.

So any sandbox GMs here using FG? If so what's your trick/workaround to deal with the seemingly storycentric system?

Or is FG just not in the sandbox market maybe? I'd understand if they didn't want to deal in that too and stuck to just running planned modules as the function basically. that's on me for not doing my homework better, but if so is there a known sandbox oriented VTT i should be using as a sandbox GM?

Thanks for any time and attention,
FFY

[Trenloe]

Just because the sidebar entry is called "Story" doesn't mean that FG is story centric. A story entry is just a bunch of formatted text - which can include some links to other FG records. Use it as you want to - an entry can contain links to encounter, random encounter tables, generic maps, etc., etc. - making a story entry a very handy placeholder/reference to quickly get to the data you might need. It's essentially a collection of FG data, don't get hung up on the name "story".


The scheme is everything flows out from Story elements, no encounter can be 100% self contained to include any and all needed text to go along with it. You can link a Story text to an encounter, but an encounter cannot link to any text or include any in it directly.
Make a story entry and call it "Encounter in the hills #1" (for example) and put everything you want in that entry - text, links to the FG encounter, map/s to use, etc., etc..


I need to have points of interest and encounters as stand alone, including any text descriptions they may need, because no known in advance Story elements will get us there to provide any text to read to go along with it.
Put all of this in a story entry - as it's not a "story", it's a collection of data.

[Zacchaeus]

I think I'd need more information on how you play. Let's say for example that your players are currently in Village A and they could go in any cardinal direction. What is their incentive to go in any one of those directions? Do you as DM know what is out there or do you just pick something that you have prepared? What, if anything, do you prepare? I assume you must have some structure to your world map? I mean is city A always going to be in a certain place or how is that determined? Do you just use random encounters? Or do you have set encounters that the players will face?

The sandbox adventures that I've played all have a set world map; points of interest are mainly in certain places, specific creatures are in certain places. Certain quests happen in specific locations. But there will be many areas where there's nothing happening as far as the overarching adventure goes; it's left to the DM to fill all that in, with people, quests, encounters etc.

So, in other words a story entry is ideal for that since you have one for each PoI and you can link encounters, people, quests or whatever to that story.

[LordEntrails]

Don't think of an FG story object as a campaign story plot point. Create a FG story object for your point of interest, for your encounters. For your factions.

I love FG for sandboxing, it's a great tool. Here's some of the tools I do to do this;

I start with a development campaign (see module creation link in my sig). In there I will create a story group for a given faction, town, or complex point of interest. Then in that group I will make stories, one for each building in the village, or for the various groups of NPCs that the party may encounter. Then inside of those then I make links to encounters, random encounters, and sometimes tables.

Which brings up the point of random encounters and tables.

For instance, in my sandbox I might have an orc tribe in some region. So on the map I create a pin to the center of the region they inhabit. That story entry has a little background info, and links maybe to the chief and shaman. Then I also link to some tables, like "Wandering Orc Groups". Then the table has five entries such as: Orc Hunting Party, Orc Raiding Party, Orc Trading Caravan, Orc Hermit, Orc Ally.

Then the Hunting party is a link to a random encounter that has 2d4 orcs and 1 leader. The raiding party has 3d6 orcs, 1 leader, 1 shaman. The trading caravan has a link to a story entry, and maybe that has links to tables to generate info on the caravan. The hermit is a story entry with ideas. The Orc Ally is a table that has different things like; a barbarian emissary, a necromancer, a giant ambassador, etc.

You can do the same thing using a story object to add a link to an overland map that has a village. Or city. Or Ogre Cave.

Remember, stories don't require a plot line, they are just text based collectors that can link and be linked to and can be organized by name and group.

[Trenloe]

Here are two examples:

1) I used a story entry to keep track of all of the images that I might need in the current session. I added this to a hotkey slot at the bottom of the FG desktop so I could pull it up quickly whenever I needed it. You can have different story entries to hold different things - conversation snippets you might want to post to chat, links to maps you may use, links to random encounters, etc., etc.. You can even use a story entry as your top level table of contents, linking to other story entries - so you can setup your data in a hierarchy and easily get to it with a couple of clicks.

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=57633

2) Here's an example from a hex crawl - a story entry is attached to the map and when the pin is clicked it opens an entry that gives details of the location, with links to other FG records.

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=57634

[A Social Yeti]

Just because the sidebar entry is called "Story" doesn't mean that FG is story centric. A story entry is just a bunch of formatted text - which can include some links to other FG records. Use it as you want to - an entry can contain links to encounter, random encounter tables, generic maps, etc., etc. - making a story entry a very handy placeholder/reference to quickly get to the data you might need. It's essentially a collection of FG data, don't get hung up on the name "story".


In my own mind I'm not, i know it is a data container for text entries, that's how i been treating it.

As a systematic tool, the work flow is only from container X to container Y, there is no way to get from Y to X here. Thus it is an Xcentric system. I use the term story just because that is what the system's container has been labeled.

But this is why it sure seems a centric or work flow specific system. It is a one way flow from the text container (we happen to label story) to the container for the mechanical objects of the encounter. But there is no path to get from the objects of the encounter container, to the text that goes with them.
A systematic one way flow as it were.

I also see the example you show later, and that is what i had worked out to do on my own before i came and asked. I do want to thank you for the time and effort you put in for me. Thank you.
(in a verry polite voice) But look at what you had to do with your "file names" in order to deal with the one way work flow imposed here.
I basically got to a story entry name of 001.000.231.a and thought, this is looking stupid, i must be doing it wrong if i am the manual organization system here rather than the app is doing the heavy lifting on that for me. I'm best go ask.


Thanks yall who also chimed in. Yes the map pins are a great tool for sandboxing. I see the way yall are doing it and i just imagined it would be more data linking flexible for a X to Y or Y to X flow. And full manual crazy file organization names is just how it has to be done in FG if you want to be able to go from an encounter to the text about it.
Glad to know i am on the right path in my treatment, just wrong path in my expectations.



And so i wish i could get my brain around the design reason to not allow that all things can have a link to all things that do relate to them, regardless of what container they may be in?
Why have it that the encounter container can link to the parcels container for the loot of the encounter, and the NPCs container for the monsters to fight in the encounter, but not the container that has the text description to go with the encounter?
And that kind of looks nonsensical or maybe arbitrary to me, to block a key aspect of running any encounter (text descriptions) from being in the encounter container with the rest of the stuff of the encounter.

thanks again for yall's time and effort,
FFY

[HywelPhillips]

I absolutely love FGU for Sandbox campaigns!

Currently running one where the players got shipwrecked on a jungle island, which they've subsequently been exploring.

I use a story entry for each "thing" of interest - if it is location the story has a brief overview of what it is, a link to an encounter or encounters or table of encounters for who can be found there, parcels if there's anything useful for the party (which at the beginning everything was as they were shipwrecked with nothing). An image if there's an illustration, or a battlemap.

Some of these locations were "fixed points" I knew about on the island. Many more were floating locations like "this is a beach with a genie's cave" that can "float" to fit in with where they go and what they are doing. Some are wandering NPCs. I use stories as my primary container and organising tool.

I also make big random tables of encounters for the various terrain types which includes events, wandering creatures, lairs, roaming NPCs, strange ruins, and then a list of useful battlemaps for each terrain type so I can quickly pull up something suitable when I roll for the encounter. I generally also use stories for these so I can link together encounter, parcel of loot, battlemap if need be, Syrinscape sound links, etc.. but some of the simpler ones can just be a raw encounter.

Once an encounter has been rolled, I pin its story to the island map - now we know that these woods are the woods of the giant wasps, or that there's a shipwreck in this bay.

As Trenloe does I have a story pinned to a hotkey slot with a story containing stuff I except to come up for the next session- they're going to the Burning Lands to try to get into the Efreeti's palace? Battlemaps, encounters etc. can all be put into that story. I might pre-roll a couple of encounters to get a feel for what they might meet if they go the way I expect, but generally they're likely to go off on a complete tangent and end up finding a ruined bath-house in the jungle still tended by the genie pool attendent instead. I've got a vague idea of the major areas and factions of the island, but the rest has been guided by where they've gone and what they've found interesting to chase up.

I cannot imagine doing this in Roll20 - I just don't see how you'd even organise the 30+ battlemaps I have for each terrain type as my random encounter maps, let alone the once for placed and semi-floating encounter zones.

I was involved in prepping a West Marches style multi-GM hexcrawl sandbox with a few other GM's on Foundry (because we wanted to use Forbidden Lands, not yet released on FGU). It was workable, and had a few nice features - different symbols for map pins in particular. (Now possible with extension on FGU).

We definitely missed the ability to organise encounters the FGU way- as planned as you like but not active until you click to push everything to the map and combat tracker. Ditto loot parcels which are just a lot smoother and quicker to organise and pin in FGU. That campaign folded after a few sessions at least in part because we found the GM prep a lot heavier to do for the sandbox style in Foundry than in FGU- although it might get better with practice, the most active GMs were also FGU fans and I think in the end we just couldn't face doing such a large-scale sandbox operation without FGU's GM organisational tools.

Cheers, Hywel

57638

[HywelPhillips]

In my own mind I'm not, i know it is a data container for text entries, that's how i been treating it.
<snip>
And so i wish i could get my brain around the design reason to not allow that all things can have a link to all things that do relate to them, regardless of what container they may be in?
Why have it that the encounter container can link to the parcels container for the loot of the encounter, and the NPCs container for the monsters to fight in the encounter, but not the container that has the text description to go with the encounter?
And that kind of looks nonsensical or maybe arbitrary to me, to block a key aspect of running any encounter (text descriptions) from being in the encounter container with the rest of the stuff of the encounter.

thanks again for yall's time and effort,
FFY

Our replies crossed...

Yes, it is a limitation that FGU only has two sorts of hyper-linking. Text hyperlinks and Image Map Pins.

If a certain type of object doesn't have a free-form text box, you can't use text hyperlinks. And only images have map pins.

The workflow we've all evolved is to use story entries as the container to link all related stuff - actual text, images, battlemaps, parcels, encounters, NPC links, etc. in a single place. ANd most of us probably then pin that story entry to an appropriate map pin too.

It's fine if you think of it as a page in the GM's notes IMO.

However, if you'd rather use encounters as your primary building block, there is an extension which does exactly that:
https://forge.fantasygrounds.com/shop/items/141/view

What FGU doesn't do at all, by design, is two-directional links. That's because a lot of the time the links can be many-to-one - the skeleton NPC stat block can be placed in many different encounters, so it doesn't make much sense to be able to navigate from "skeleton" to "Skeleton door guard encounter" and "2d4 random skeletons" and "The Skeleton of Boriz Vangt" and however many more encounters it might be linked to. Likewise with items and parcels (and player inventories). Encounters can only have tokens pre-placed on one battlemap image, but might be in principle be pinned to many different maps or stories - you might expect to meet Ravenger's Ravens on the street outside the Dog and Duck, and have pre-placed for that, but the NPCs can show up elsewhere and the encounter is still a useful collection to refer to. ("If they come by the docks at midnight, Ravenger's Ravens will likely be hanging around here" - hyperlink to encounter, hyperlink to docks map).

It's fairly well thought-out in terms of when it refers back to a master copy (eg the skeleton stat block from the Monster Manual) vs when it makes local copy eg when it pushes "The Skeleton of Boriz Vangt" encounter to the combat tracker - allowing the new temp NPC have a different name and token from the default ones by changing them in the encounter, whilst leaving the stat block the same and without messing around upstream with the master copy. How valid or useful two way link traversal is in such situations isn't obvious to me, whereas the utility of dragging in a stock stat block, giving it a new name and a new token and the players none the wiser is something I do all the time. SOOO many NPCs are guard or noble or scout statblocks, but it's a lot more fun to face four brothers who fight close together with stats as goblins for pack tactics or whatever without doing anything more than a quick re-skin on the fly.

Likewise, the items in a parcel can be customised versions of the master item, reskinned with a new name without affecting the original master. And the version that gets added to a player inventory is a copy again, which can be modified without affecting the one in the parcel.

I don't think it is nonsensical or arbitrary, myself, but it might not mesh well with your own mental model of what you want to be first class citizens and which you'd like to have as the container. Which is absolutely allowed, of course! We all favour software whose default model matches our own preference pretty well (it's why I still loathe Photoshop every time I am forced to fire it up).

Cheers, Hywel

[Griogre]

I also like FG for sandbox. As Zacchaeus mentioned part of how you can use FG depends on how you normally do your sandbox. I usually use a map with a few key locations like the starting area and maybe a dungeon. In FG you need the things you are going to want to run your game. Just like your freeform DJing that means you need a selection of tracks to pull from to match the mood and the crowd.

For you sandboxing what are your tracks? Its it encounters? Maps? Backstory? Those are the things you want to put some effort into so you can pull out the ones you need as your PCs choose the direction the campaign takes. Prebuilding will help you flesh out things but it's not worth doing more than a skeleton since your PCs might not follow up on any particular story hook.

The minimum to do things in FG are maps (can be done on the fly), encounters (can be done on the fly). Generally I think of story entries as containers you can put text, maps encounters or parcels in them as you wish. You can also just put a location name in the title use them to mark places on a map.

For me for a sandbox campaign - unless it's a megadungeon - I just start with an outdoor map. I'll either make one up or generate one. Then I would put a story entry for the starting village with a few notes about the major NPCs and stuff like the village power structure and I'd put a pin there on the map.

If I'm doing a pure sandbox I would then come up with 2-3 adventure hooks, rumors ect. Here's where how you would do it might be different from me. I would probably think about the basics of each story hook/adventure. Having a selection of maps, outdoor and a few small dungeons plus some good random encounters tables is all I really need to get going.

[Trenloe]

But look at what you had to do with your "file names" in order to deal with the one way work flow imposed here.
I basically got to a story entry name of 001.000.231.a and thought, this is looking stupid, i must be doing it wrong if i am the manual organization system here rather than the app is doing the heavy lifting on that for me.
The decimal naming is purely to show entries in a specific order, and to tell FG which entry to open when you click the next/back buttons at the bottom of the entry. It's nothing more than that - it's up to you what you call an entry if you don't want to use the forward/back buttons. It's not anything to do with a one way flow, it's just ordering.

You can always use the search field to search for names - so if you have an encounter called "Raging waterfall" and you have a story entry called something similar, then you search for "waterfall" in the story window to find possible story entries that may be related.


And so i wish i could get my brain around the design reason to not allow that all things can have a link to all things that do relate to them, regardless of what container they may be in?
You can put a link to a record (a story, an encounter, a treasure parcel, etc.) in any formatted text field within FG - this means that it's possible that there could be hundreds (or more) of links scattered around within an FG campaign and DLC that point to one record - to be able to go from that one record and open all of the records that have a link within it would be impossible to code (especially with the extensibility of FG through extensions), and if it was possible to code, you could suddenly end up with many windows opening. So having a mechanism to that allows you to automatically access all records that "something" is linked to would be unwieldy at best and impossible at worst.

FG's links are basically the same as a web hyperlink. Anyone can add a link to a web page in their website, and so it's impossible to go from a page on a website to all pages that have links to that page. FG links are the same - whereas they're in a enclosed environment (FG), with the extensibility of FG via extensions, formatted text fields can be anywhere in the campaign and so it would be virtually impossible for FG to be able to trawl through all formatted text fields within the campaign and DLC data to look for a link to a base record.

So, let me ask you a question - if the Encounter record had a formatted text field within the window that allowed you to manually add links to other FG records within that encounter, would that address your issue? Like I've just said, you're never going to be able to click a button and automatically open all windows that link to an encounter, but you could manually put the links you'd like in the encounter.

[Nylanfs]

For those that do more sandbox and random elements in your campaign you might want to checkout Squareware. https://www.fantasygrounds.com/store/product.php?id=IPFGANYGTWSW

[HywelPhillips]

I second the Squareware recommendation for fantasy games. Likewise there are a bunch of useful modules full of tables or self-contained content on the store.

The AAW mini-dungeons are useful for when you just want a generic one-session place of interest:
https://www.fantasygrounds.com/store/product.php?id=AAWFG5EMDT

The rumours, notes and book collections are good for planting sandbox seeds:
https://www.fantasygrounds.com/store/product.php?id=IPFG5EAGRNABC

Most of the Raging Swan Press modules are designed to slot in and inspire sandbox stuff. I particularly like Urban Dressing and Wilderness Dressing but the lairs and villages are useful drop-ins too.
https://www.fantasygrounds.com/store/product.php?id=IPFG5EAGRNABC

And I'm sure there are many more good products besides, those are just the ones I'm using in my current games.

Cheers, Hywel

[WinterSoldier7]

I have a world map filled with pins. These pins lead to Story entries which might details, for example, the details of a city, something encountered on the road etc. Some of these encounters are pre-written adventures.

I'm sure there are many ways to approach it, but this has worked for me for years.

[A Social Yeti]

Our replies crossed...

~
However, if you'd rather use encounters as your primary building block, there is an extension which does exactly that:
https://forge.fantasygrounds.com/shop/items/141/view
~
I don't think it is nonsensical or arbitrary, myself, but it might not mesh well with your own mental model of what you want to be first class citizens and which you'd like to have as the container. Which is absolutely allowed, of course! We all favour software whose default model matches our own preference pretty well (it's why I still loathe Photoshop every time I am forced to fire it up).

Cheers, Hywel


Thank you thank you thank you. that is exactly what i am talking about and what i am baffled FG is not doing on its own out of the box already.

uuhh wit a min. something went weird on me... i clicked your link but i swear i wound up here
https://forge.fantasygrounds.com/shop/items/1233/view

not "Mad Nomad's Enhanced Encounter Window" as the link now sends me. I was at the store page with this at the very top "Encounter Descriptions"
which is where this image is from that shows an encounter offering exactly what i am surprised it did not already offer.
https://forge.fantasygrounds.com/images/e69fb798fee957aa24d1e7f5b52d36b4.jpeg


And i don't really care about the free form text box, it's the links the main text container (story) that matters, and the image container link is also great to get. With those things inside the one encounter window, a GM can have everything any encounter needs in it when they open IT up.


It's the systematic nature of what the designers connected to what and the labels they gave them, that seems to suggest their design POV to me.

If the designer POV was, we plan that an encounter may be opened up arbitrarily and run without a story item leading to it...well clearly the FG system don't deal in that situation, it explcitly blocks it, thogh it is technologically possible to do. That's part of what says design intent to me. They can link to it, but their work flow design POV seems to simply have had no rational need or reason to do so.

sure looks like the design POV is:
We expect to get to the encounter objects from the text over here in the story container.

now imagine a source book like this
https://upload.wikimedia.org/wikipedia/en/5/53/REF5_TSR9240_Lords_Of_Darkness.jpg
only has printed in it what FG's "encounters" container holds as is.
I'd be betting that's missing expectations for most GMs.





~
So, let me ask you a question - if the Encounter record had a formatted text field within the window that allowed you to manually add links to other FG records within that encounter, would that address your issue? Like I've just said, you're never going to be able to click a button and automatically open all windows that link to an encounter, but you could manually put the links you'd like in the encounter.


I was not meaning to suggest a single button to open all related things at once, but to say, why are not all things the designers know are needed for an encounter, accessible from within that encounter's container?

The above image of the 3rd party add on is what i am speaking about, they have a link to the story container right there in the encounter item itself, just like a link to the story container anywhere else it can be made.
And so relative to keeping encounters and their descriptions together, no manual efforts on names needed, it just is all together now by flowing(linking) back and forth between all required elements freely. Not opened all at once automatically, but just all things a GM will need for running the encounter, are accessible/reachable from within the one "encounter" window.



And just to say on it. I find a design POV that was taking sandboxing into account as a feature to cover, would probably not have labeled the mechanically main text container for that as "story."
And a design POV that was explcitly considering running modules/premeditated stories, but not sandboxes so much, seems totally rational to use the label story on the main text container for informing users of how the system functions.

You can probably get why we'd believe this idea that FG is a story based system. As we are giving the designers the benefit of the doubt to see it that way.

FG team gets all the best possible to give benefit of the doubt when we treat a given label, as a carefully chosen and meaningfully informing of the functions label.
If it is not functioning as labeled, then it would seem the label is categorically a design flaw waiting to be corrected.
Maybe "Main text" or All text" or maybe best, "GM's text" would be more a appropriate label to inform end user how the designers know that container functions.


In design POV alone we wind up directed to very different headspaces by the label itself.
When we say "story" goes in there, we likely imagine where we need to provide access to that is a different flow in the design.
Than if we called it "GM's text."

As a design when you consider , "where all will the GM need access to the "story"" i bet we have a different systematic POV on that. That's going to be a real different pattern than if what we were considering was, "when and where will we need to proved the "GM's text.""

See? The labels themselves are also are design directors.
A "story" container within a RP campaign would have X in it, and be needed by the GM in Y places. I mean if we assume the label is not arbitrary of course.
A "GM's text" container would clearly include all that story stuff, but also more. As well as be something we know the GM needs in other places besides when "story" alone is what's going off.








It was asked earlier so here's how my table sandbox works:

much like Hywel said, i make/start a campaign mostly out of encounters.

I really let the players direct it all, the sandbox is truly open and mostly being crafted uniquely just for them as we go. If they wind up on some world calamity averting epic story, that's because they were busy expressing interest in such, not because i had that planned already.
I'm carefully paying attention to what the players are talking about with each other. And craft the illusion that what they been telling each other they think would be cool, wow that's what was going on here in the world all along already. Yall are freaking smart you totally figured out that saboteur plot going, what was it that gave me away (i had no such plot going on i just rolled with them really)?


I got a map and it's got Points of Interest on it that are detailed out with some story hooks to discover. The map pins work great for this yes.
But unlike more typical map/hex crawls mine are fewer and farther between. What i really got is a big create of categorically organized encounters i can draw on, kind a just like my crate of vinyl really.


What's getting used? No clue i read the room and pull up what i thinks going to be hot next. I am sandboxing more like a PG system than a premeditated map crawl.
Or to say as i try to make it be:

In my sandbox the players do not discover my sandcastles to be in awe of my creativity, they build their own and awe me with theirs.

As a camping unfolds and the players begin to drive themselves down some specific path, then actually we do reach a stage when a lot more of what's going on will flow out of story more than laying it down as they are walking onto it. Because now the story has taken over more for the on the fly mixing. But guess what? I'm not remaking encounters i already got in the crate. The on the fly encounter grab never stops being useful even with a strong story line going.


Thanks again everyone for yalls help. The link to the add on is exactly covering what i was feeling the gap of in FG for me.
And hopefully what i feel is basic sandbox functionally needs, will one day be out of the box functionality for FG.

[A Social Yeti]

For those that do more sandbox and random elements in your campaign you might want to checkout Squareware. https://www.fantasygrounds.com/store/product.php?id=IPFGANYGTWSW

Ok this is looking like it could be real useful, thanks i'll take a look at that.

[Trenloe]

I didn't read all of your post, sorry I don't have time today.

But I did want to reply to one aspect:

And just to say on it. I find a design POV that was taking sandboxing into account as a feature to cover, would probably not have labeled the mechanically main text container for that as "story."
And a design POV that was explcitly considering running modules/premeditated stories, but not sandboxes so much, seems totally rational to use the label story on the main text container for informing users of how the system functions.
So, going back 20 years when FG was first created - the main database record was called "Encounter". It's not like the encounters we have now (a list of NPCs with map token placement) but it was a formatted text field that allowed a GM to build his encounter - adding links, etc. to the "encounter" entry. Fast forward 12 or so years (I can't remember exactly when the current "encounter" functionality came in) and the "encounter" format we have now was introduced - i.e. a list of NPCs and map token placement. As the database already had data stored under encounter, the database location was called "battle". So, we now had "story" entries that were originally called "encounter" in the database and remain so now, and new "encounter" entries that were called "battle" in the database - as that's all they were, a list of creatures and their map token location.

That might sound confusing, but what I'm trying to highlight is that the original design POV was to have encounters as formatted text fields, allowing the GM to add text, links, etc.. Over time these were renamed to "Story", but their functionality remained the same, it's just how you use them and how you perceive how they are used.

I don't think there's a 100% accurate/intuitive label for it - as different GMs will use it different ways. Which takes me back to what I said in my first reply in this thread:


Just because the sidebar entry is called "Story" doesn't mean that FG is story centric. A story entry is just a bunch of formatted text - which can include some links to other FG records. Use it as you want to - an entry can contain links to encounter, random encounter tables, generic maps, etc., etc. - making a story entry a very handy placeholder/reference to quickly get to the data you might need. It's essentially a collection of FG data, don't get hung up on the name "story".

[A Social Yeti]

I didn't read all of your post, sorry I don't have time today.

But I did want to reply to one aspect:

So, going back 20 years when FG was first created - the main database record was called "Encounter". It's not like the encounters we have now (a list of NPCs with map token placement) but it was a formatted text field that allowed a GM to build his encounter - adding links, etc. to the "encounter" entry. Fast forward 12 or so years (I can't remember exactly when the current "encounter" functionality came in) and the "encounter" format we have now was introduced - i.e. a list of NPCs and map token placement. As the database already had data stored under encounter, the database location was called "battle". So, we now had "story" entries that were originally called "encounter" in the database and remain so now, and new "encounter" entries that were called "battle" in the database - as that's all they were, a list of creatures and their map token location.

That might sound confusing, but what I'm trying to highlight is that the original design POV was to have encounters as formatted text fields, allowing the GM to add text, links, etc.. Over time these were renamed to "Story", but their functionality remained the same, it's just how you use them and how you perceive how they are used.

I don't think there's a 100% accurate/intuitive label for it - as different GMs will use it different ways. Which takes me back to what I said in my first reply in this thread:




Thanks for the insight there. that's a great show of developing a better system. The first take was: an encounter IS its own thing more self contained. But then no the real function of encounters is they are simply containers of links that point to all various individual building blocks that encounters are made up of. NPCs, loots, maps, images and descriptions, would be the basic category building blocks of encounters. It would make for a much more flexible and less data redundant system. great.

So yes a much better system to have an "encounter" be nothing but a collection of links that point to all the parts that the encounter is made up of.
Question remains, what's design reason for only linking to some parts of what the encounter is built from, but not all? As if we never imagined a GM might "run" an encounter but would for sure only ever read from the main text flow out to the encounters?



And I am having my mind blown here right now to find out, you made the extension that is exactly the functionality I expected FG to do out of the box already. dam you like some kind of super dev or something.

I clearly failed to find the wording to describe for you what I was talking about fully, but yes exactly what you did there.
https://forge.fantasygrounds.com/shop/items/1233/view

the free form text part is cool too, but it it is the linking to the main text container that is the real functionality i was talking about and the image container is really making it a fully featured encounter that could be run by opening it up directly.

that is exactly what i went in assuming i'd be able to do already.


again deluxe thanks, hope that finds it's way to the out of box functionality one day.
I did install and run it, exactly what i was trying to describe the function.