Special Announcement - Kickstarter

One thing that was talked about on a Friday FG video is the work needed to implement a co GM mode/build/addition and how to handle multiple people opening/editing the same files or sections withing FGU. This seems like a simple thing as far as permissions go. The person running the campaign (client considered running the game or gm-ing the game) always has priority and overwrite in every aspect. This would imply general game permissions are coded into FGU for access to certain area's of the game I.E. Map, specific modules, chat etc.

Now I am not talking about how much work it would take to code that in, but just the "True" GM always admin over the session like an Operating system.

Quote:

---

Originally Posted by ssj4megaman

One thing that was talked about on a Friday FG video is the work needed to implement a co GM mode/build/addition and how to handle multiple people opening/editing the same files or sections withing FGU. This seems like a simple thing as far as permissions go. The person running the campaign (client considered running the game or gm-ing the game) always has priority and overwrite in every aspect. This would imply general game permissions are coded into FGU for access to certain area's of the game I.E. Map, specific modules, chat etc.

Now I am not talking about how much work it would take to code that in, but just the "True" GM always admin over the session like an Operating system.

---

Unfortunately, That not how operating systems handles file permissions. In an SQL or relational data base, it would be easy to do what you suggest, in FG which is effectively using a couple of text files as it's database, you have to deal with operating system file handling. So what FG would have to do is to create a set of function for the host (GM) to handle all file transactions (caches, staging areas, transaction logs, garbage collection, etc). Not impossible, just labor intensive and you would have to do extensive testing to make sure you never allow the file to become corrupted or commands lost.

Quote:

---

Originally Posted by LordEntrails

Unfortunately, That not how operating systems handles file permissions. In an SQL or relational data base, it would be easy to do what you suggest, in FG which is effectively using a couple of text files as it's database, you have to deal with operating system file handling. So what FG would have to do is to create a set of function for the host (GM) to handle all file transactions (caches, staging areas, transaction logs, garbage collection, etc). Not impossible, just labor intensive and you would have to do extensive testing to make sure you never allow the file to become corrupted or commands lost.

---

And, of course, Smite Works is not a Google. They aren't big enough, nor do they dodge enough taxes to afford to do all that. ;)

They're already rebuilding the engine anyways, there's no better time than now to implement that functionality. And it is vital functionality, given that their competition already supports that feature, and it's a common need for many gaming groups. Better to bite the bullet and get it in when the program's being overhauled than wait until it's done, then try to go back and stick it in in the future.

Quote:

---

Originally Posted by Valatar

They're already rebuilding the engine anyways, there's no better time than now to implement that functionality. And it is vital functionality, given that their competition already supports that feature, and it's a common need for many gaming groups. Better to bite the bullet and get it in when the program's being overhauled than wait until it's done, then try to go back and stick it in in the future.

---

Except it's 90–95% done at this point. A lot of effort has been spent making sure that the new engine loads all the DLC that the last one could handle. It may have been better to add this as they worked, but as far as I know, that boat has sailed.

The ability to share a campaign between GM's is already supported - you just zip up the campaign directory at the end of a session and send it to the next guy - who unzips it - runs the session - and repeats.

That does require the GM's and players to have the right licenses - as you can't move the 'ultimate' license between seats. The licensing is fundamental to how the program runs - and honestly I can't see that changing at all.

I don't see the necessity of a shared GM workspace **inside** the Fantasy Grounds client.
Doug mentioned potential companion apps in the FGUnity FAQ video--maybe a shared GM Drawing Board app, where a group could open and edit Story, etc. files could garner enough interest to merit development.

Quote:

---

Originally Posted by Ckorik

The ability to share a campaign between GM's is already supported - you just zip up the campaign directory at the end of a session and send it to the next guy - who unzips it - runs the session - and repeats.

That does require the GM's and players to have the right licenses - as you can't move the 'ultimate' license between seats. The licensing is fundamental to how the program runs - and honestly I can't see that changing at all.

---

I don't think the problem is sharing the campaign. What groups with rotating DM want is to just have one person buy a license and the DLC and everyone is able to share that license and DLC no matter who is hosting the game. Therefore 6 people buy one Ultimate License and one PHB instead of 6 Standard Licenses and 6 PHB's.

There's no incentive for Smite Works to entertain that at all, is there?

Other than the architectural changes under the hood, there's also significant licensing issues for official products.