Looking for Best Practices....

[dentaa]

Hello All,
I am running a game using Hero Lab (and Realm Works) and I have a decent amount of custom rules, items, races, etc.
I have 4 players (of 6) who have purchased Hero Lab.
We play weekly and changes to characters are frequent.
What is the best practice for syncing and/or distributing characters between their laptops and my master copy?
DM » Players
Players » DM
Random » Random
By the above I mean my real issue is this... If during the game a player gets a +2 ROP I really have to add it to my version or it isn't calculated into the game. But that means if the want to have real numbers I have to stop and sync their characters...
I was thinking about a group dropbox account...
But that leads to second issue where I have and use resource books they do not have...
So I am looking for best practice suggestions from those of you who have ran across this issue before.
Thanks

 

[Silveras]

You may want to limit the books used in your game to ones that everyone has, or for each player to use only books that you and they both have.

One issue to watch out for is the "random to random" scenario. If you don't keep careful control over the "version" of the files being moved around, it is likely that there will be mistakes .. such as old files being used instead of the correct one... and changes could be lost or backed-out.

You may want to limit updates to between sessions. Trying to manage it during sessions will slow things down. The players' use of HeroLab is for "live" calculations, while the GM's can be a little different. You and they can each modify your own copies independently, and not worry about sharing the POR files except at specified intervals (such as when the adventure is over, or at level up).

Discrepancies like ammunition used, potions used, charges used, and such can become hard to reconcile. If your copy is the master, then don't take updated files from the players.. have them email you any changes that aren't part of "in-play" (such as skill point allocation on level-up) and export your master copy to separate PORs for them. You can work out disagreements on accounting by email between sessions.

If you intend to treat their copies as being the "master" copies, then you should only accept updates from them.. and not send any back. A "master" implies that it is the authoritative version ... in which case, updated files should only flow from the "master" to others after being manually updated.

If you intend to pass updates around between any two people, then there is no "master" really, and the chances of disputes are higher.

 

[Chemlak]

Silveras has the right of it.

When I play, I maintain a single GM "master" portfolio, a copy of which goes into the game's Dropbox folder (which all of my players have access to). I do all of the updates to the master file, on consultation with the players (who will generally do their own updates in their copy of HL, and tell me what changes they made). I've never been particularly bothered about ammunition and rations, so discrepancies there aren't a worry.

 

[dentaa]

Ok appreciate the input. I am going to try the dropbox with me adding the new stuff during the game as needed and they can update. I have not seen it in the notes, but is Lonewolf considering a. server based Hero Lab like realm works. ( and live sync on Realm works???) Love the products!!!

 

[Azhrei]

This is background information and doesn't apply directly to HL, I just thought some of the more technical folks might find it interesting.

We have an issue in MapTool where the tokens (digital representations of figs on a map) are copied from one machine to another in real time. (MapTool is a distributed virtual tabletop application.) Obviously, there's a possible conflict: what if field A is changed on the server while field B is changed at the same instant on one of the clients?

MapTool currently sends the entire token when a single field is changed. So whichever machine "sends" the token last will be the one whose update is preserved (because it will overwrite the other).

In an ideal world (and the one we're working towards), each individual field would have a timestamp and just that field would be transmitted to other machines. That way, when the receiving machine gets an update -- along with a timestamp -- it could check and see that the timestamp is more recent and thus overwrite the field as it should. And if the timestamp coming from the other system is older, the update would be rejected. The machine that rejects the update would provide the timestamp and field value that it has to the other system, which would then need to decide how to handle it. For example, let's say a field value was being incremented. It could choose to use the newer value, increment it, then send that one out to clients. If the value was being overwritten by user input, it could take the new value and display it, letting the user know their input wasn't accepted because it was out of date and letting them enter a new one. But the semantics of the change would need to be considered, not just the functionality of the operation itself.

This gets very complicated. There has to be some kind of expiration time for stale data, but we don't want to be rejecting user input all the time either. And we can't really use timestamps because not all computers connected to the server necessarily have the same idea of what time it is, so a different technique must be used instead. Since there's no timestamp, we have to send the old value and the new value whenever there's an update. Now the machine receiving the update can compare the old value with what it thinks the field has in it, then decide whether to update its copy. Some extra logic might be needed when multiple systems change the same field at once, but change it to the same value, depending on the semantics of the change.

Sorry, I didn't mean to derail the thread. But I wanted to point out that what seems simple at first glance is actually quite a bit more difficult. One obvious and simple solution is to only allow one machine to have the "master copy" of any given data, but then that system becomes a bottleneck for any updates to that data. And what if that machine goes offline at a critical point? That could slow down or even halt the operation of the other nodes.

As Murphy once said, "Nothing's ever easy."

 

[Aaron]

Continuing the derailment.

"Nothing's ever easy" is the unofficial motto of my campaigns. To the point where whenever something seems to go the parties way without a struggle they immediately get suspicious.

 

[dentaa]

This is background information and doesn't apply directly to HL, I just thought some of the more technical folks might find it interesting.
As Murphy once said, "Nothing's ever easy."

Thanks that gave me an idea... using the timestamps.... Might write an app to curate files in dropbox...

 

[Azhrei]

That could work, as long as the data is never saved unless there's a change. Otherwise an unchanged file will have an updated timestamp. So a user that chooses File > Save without actually changing anything could mess you up.

The other thing to consider is that what you really want to do is unpack the XML and only add new elements (or subtract existing elements) without affecting anything else. For example, the original file A might have a piece of data removed, and the new file B might have had a field added. You can't just take the most recent one since it won't have both changes. Instead, you need to merge the XML together, adding and removing pieces appropriately.

This won't be an easy task, although a Unix version of the diff command (without any options to control formatting of the output, so no "-u" or "-c" options) would be a good start. If I were to tackle this, I'd probably use Python since it works across platforms and has pretty good coverage for XML reading and writing. Or maybe I'd use JavaScript or Go.

 

[Farling]

This won't be an easy task, although a Unix version of the diff command (without any options to control formatting of the output, so no "-u" or "-c" options) would be a good start. If I were to tackle this, I'd probably use Python since it works across platforms and has pretty good coverage for XML reading and writing. Or maybe I'd use JavaScript or Go.

Or store the files inside a simple github repository, then github will manage the differences if the file has been changed at both ends

 

[dentaa]

» Farling "Or store the files inside a simple github repository, then github will manage the differences if the file has been changed at both ends "

Have you done this? If so results?

 

[Farling]

» Farling "Or store the files inside a simple github repository, then github will manage the differences if the file has been changed at both ends "

Have you done this? If so results?

I haven't tried this since I haven't needed to do something like this.

But any sort of software configuration management tool would provide merging from two different sources.

 

[Azhrei]

True. But github won't automatically pack/unpack the portfolios into XML for you. I suppose you might be able to setup some git-hooks so that .por files are unpacked when they are checked in... You'd need something similar to git-tar that packages them back up again when you want to extract them.

You know, that might actually be doable. Even if github doesn't support all of the needed hooks, a local git repo could certainly do it. I'll have to play around with this a little; I've never played with git-hooks before...