Design Philosophy Question

[dulux-oz]

Hi Guys,

Got an interesting Design Philosophy Question which I'd like the SW Devs, the Community Devs and anyone else with an opinion to chime in on.

Let's say, as a hypothetical example, that you could use one of the Building Records from my Locations Database as a true Shop - that is, drag and drop Items to and from the Inventory page to Character Sheets, etc, and have the total price deducted from the Character's treasury and added to the Building's, have the total number of that Item deducted from the Building's Inventory, etc, etc, etc.

Now suppose that you have a number of "Generic Shops" (say, a Weaponsmith's, Armourer's, General Store, etc). As I understand things (& please, correct me if I'm wrong), the only way to have these Buildings' Records being able to be changed (ie the Treasure updated when something is "sold") is to have the Record in the Campaign DB, as opposed to a Module's DB. So if you wanted to have these Generic Shops in a Module you'd have to copy them over to the Campaign DB, because in the Module DB they are Locked, and therefore unable to be modified.

So, assuming the above is correct (and everybody knows and expects that's how Module Data works) - would we be flying in the face of the current "design standard" to actually have things set up (ie coded) to allow the level of "interactivity" that a "working" Shop implies IN A MODULE and directly usable FROM THAT MODULE?

You see, at the moment all of the things we put in Modules are STATIC - they don't change - they are READ ONLY. What I'm asking for input on implies that the Module Data will be INTERACTIVE - READ/WRITE (or, at least, some of it R/W). What are the full implications of this?

Something to consider:

At the moment when we change Module Data the change actually exists in the Campaign DB and the Module Data in the Module remains the same. If we do things the way I'm outlining then the Module Data IN THE MODULE will change - this will effect other campaigns that also use the same Module. Should we be allowing this?

Food for thought - no? :p

I now eagerly await the opinions of my peers, my fellow GMs, and my fellow Players.

Cheers

[Trenloe]

IMHO modules should remain read-only. For the simple reason that you highlight - modules are plug ins that can be used in many different campaigns, you don't want a single campaign messing with the base module data (in the module itself) as this would have knock-on effects to every campaign that uses that module, be it currently or in the future.

Modules are robust - people can't accidentally change the base data in the module itself, so mistakes (oops, I didn't mean to delete that shop) aren't complete disasters.

The current model of overlaying changes made to a module in a campaign works as the base module doesn't change, but the campaign uses the updated data (in the individual moduledb file: https://www.fantasygrounds.com/forums/showthread.php?22253-Local-Module-Data).

I'm trying to think of a reason why I'd, personally, want the interactivity you mention taking place directly in a module. Other than wanting those changes to be seen in other campaigns using that module, i.e. editing a module for all round use (updating/expanding, fixing errors, etc.), I really can't think of much use for this, and can see many potential issues.

[dulux-oz]

I raised it because somebody asked me about it - they said that didn't want to copy the record over to the Campaign DB. I thought it was an interesting idea so I thought I'd raise it to see other peoples reactions.

To clarify further, the only "changes" to the Module Data that I'm proposing is performed on individual record components, not entire records ie on (in this example) the Inventory Counts and the Treasure Total - deleting (or adding for that matter) the entire Building Record from/to the Module would still be impossible.

Anyone else care to chime in?

[Trenloe]

To clarify further, the only "changes" to the Module Data that I'm proposing is performed on individual record components, not entire records ie on (in this example) the Inventory Counts and the Treasure Total - deleting (or adding for that matter) the entire Building Record from/to the Module would still be impossible.
You could modify the extension to track this data in the campaign - just the inventory portion, not the complete records?

Or, probably better, see if you can utilize the moduledb functionality.

[Trenloe]

Or, probably better, see if you can utilize the moduledb functionality.
In fact, your extension already does this - well done for designing that into it! ;)


Create a building in the campaign.
Add some items to the inventory.
Export the Buildings to a module.
Delete the original building from the campaign, or load up a new campaign.
Load up the module in the campaign, go to the inventory tab and you can make changes.
Type /save in the chat window to push the changes to the moduledb file.
Look in the campaign moduledb directory and you will see an XML file with the same name as your module (.xml extension)- this will contain changes/differences to the base module that are only used in this campaign.

[dulux-oz]

In fact, your extension already does this - well done for designing that into it! ;)


Create a building in the campaign.
Add some items to the inventory.
Export the Buildings to a module.
Delete the original building from the campaign, or load up a new campaign.
Load up the module in the campaign, go to the inventory tab and you can make changes.
Type /save in the chat window to push the changes to the moduledb file.
Look in the campaign moduledb directory and you will see an XML file with the same name as your module (.xml extension)- this will contain changes/differences to the base module that are only used in this campaign.


Yes, I know it already does this (I did design the thing, after all) :p

As I said, earlier, am investigating the Philosophy of the FG design.

Cheers

[Nickademus]

In fact, your extension already does this - well done for designing that into it! ;)


Create a building in the campaign.
Add some items to the inventory.
Export the Buildings to a module.
Delete the original building from the campaign, or load up a new campaign.
Load up the module in the campaign, go to the inventory tab and you can make changes.
Type /save in the chat window to push the changes to the moduledb file.
Look in the campaign moduledb directory and you will see an XML file with the same name as your module (.xml extension)- this will contain changes/differences to the base module that are only used in this campaign.


This is what I was desiring, but it did not work this way for me. I will try it again to see if I botched something in the process. My earlier attempt ended at 'Load up the module in the campaign, go to the inventory tab and you can make changes' as I could not get cursor focus in any of the building's inventory fields.

EDIT: The error seems to be with the sheet locking mechanism, not the module access.

[Trenloe]

As I said, earlier, am investigating the Philosophy of the FG design.
I'm now completely confused about what you're asking for? Re-reading your original post (and your recent replies in your Locations database extension) I think you may not fully grasp the moduledb functionality that allows you to make changes to the module data just for that campaign. For example, this post (https://www.fantasygrounds.com/forums/showthread.php?20794-Locations-%28inc-Shops-amp-Towns%29-Databse-Extension&p=197356&viewfull=1#post197356) from yesterday suggests that you're not aware of the moduledb files that track changes to a module just within the campaign.

The base FG design philosophy with modules is that the module files themselves cannot be changed - this is very good as 99% of the time you won't want your base module changing when you make changes within a campaign - be the changes either deliberate or accidental. The moduledb functionality allows you to make changes to the module data used within a campaign without changing the underlying module. This is great functionality and is what I thought you were originally asking for.

If your desire in this thread was not to discuss how things work, but have a philosophical discussion around should modules be made read/write, then my vote would be a resounding no - for the reasons I stated above - accidental changes to base modules would fill up these forums with users asking how to get the base data back because they've made a change that they didn't want outside of their campaign. Then, if the module was bought through the FG store, the FG update functionality would overwrite any changes users might have made to a module - either with a future module update or with the current functionality pushing an update because the base module file didn't match the one on record in the update functionality.

[Nickademus]

I agree. Modules should not be changed. The moduledb xml functionality is the better option.

[ddavison]

I agree about the concept of not changing the module. It can contain blueprints for shops of certain sizes if you want, or even sample stores complete with items.

An extension that randomly builds a default stock for a store and has another option to restock the store (with a frequency of weekly, monthly, etc.) would be a nice addition. I added a function to the advanced bestiary module that rolls on a random table and assigns the result to a field. You could do something similar with restocks and initial builds. Which table is used for the initial stock? How many times do I roll against it? Same for restocks. You'd have to change it some to pick up the linked record reference.

[Nylanfs]

If I think I understand the original design question correctly I would say NO modules NEED to be read-only.

[Ardem]

If I understand the question as well, I would say NO modules needs to be read only.

Having said that you could, write an option to allow write backs from the campaign temp module back to the original, but I doubt I would ever use it.

What you may need however is a way to export that temp module, that would allow you to readd it to another campaign, if you already do not have that function.

Hope I understood your question correctly.

[dulux-oz]

Thanks to everyone who's chimed in so far.

Yes, I was after a philosophical discussion, not a technical one.

Yes, you've all seem to grasp the intent of the original question (a "why", not a "how")

Yes, I understand and fully grasp how the technical side works - I've just got a habit of "compartmentalising" my brain functions so that I don't get side-tracked by things that are "cool" but not relevant to a particular discussion - think "Chinese Wall".

As far as what I've said (or haven't said) in other posts in other threads - that's somewhat irrelevant to what I post in this thread as its a different discussion - has a different focus, has a different purpose, is (again) "compartmentalised" - especially as I may (or may not) have misspoken/got my terms mixed-up/otherwise made a mess of things (that tends to happen when I write things late at night/on the fly/when I'm in a hurry :) ).

So, the general consensus seems to be "stick with the current design philosophy" - that's cool, that's what I wanted to talk about, and that's what we've now done (and will continue to do).

You see guys, just because we CAN do something doesn't mean we should. And I know I'm talking with people who understand the difference. We, as a group of Devs, can get caught up in "how" way too easily, and not think of the "why" nearly often enough. For example, why do we record the cost of items as strings and not as numerics? That's a "why" question, a design decision made by (I'm assuming) JPG, and incidentally, rhetorical. Instead of asking that question we jump straight in and focus on the "how": how do we manipulate the strings to do what we want; how do we access the string in the DB or the window or the Module?

One reason we do this is because we're Geeks, and that's what Geeks do: focus on the "How". Another reason is, as community devs, those design decisions are not made by us but by the SW devs, but one thing I love about SW and the SW devs is that they're open to suggestion (including design suggestions) from the community. But if we don't have the philosophical discussions - if we don't ask the "Why" - then we miss the opportunity to not only potentially make FG a better product but we also miss out on the knowledge that asking the "Why" brings, which allows us to be better devs across the board - and so we simply slip back into "How"-mode and things stay the same.

Now I'm not advocating a revolution by the community against Doug and the others at SW - that would be folly - I'm simply trying to raise in everyone's conscious the collective brilliance of us all that maybe, just maybe, there's a different/better way of doing something. But unless we ask the "Why" we'll never know!

OK, enough soap-box from me. I now turn the soap-box over to my peers :)