Assets missing when Remote GMs save campaign.

[Phergus]

Describe the bug If a remote GM, i.e. one that is not on the client running the server, saves a campaign he only gets the assets that have been visible during the session. State images, bar images, table images, and so on that have not been visible to his client do not end up in his assetcache nor in a saved campaign file.

To Reproduce Steps to reproduce the behavior:

1. On PC1, in a new campaign edit Campaign Properties and add several new states that use image files not in the default resource library.
2. Likewise add several images to a new table that are not part of the default library.
3. Save campaign file on PC1.
4. Start server on PC1.
5. On PC2, purge assetcache and then start up MT and connect to server as GM.
6. Save campaign file on PC2.
7. Open saved campaign file in an archival tool and check assets dir. State and table images will not be part of file.
8. Check assetcache on PC2. Note lack of images.
9. Disconnect PC2 from server.
10. Opened saved campaign file. Note missing images for states and table.

Expected behavior Expect remote GM to be able to save a full campaign file with all assets.

MapTool Info

• Version: 1.5.4 but probably all versions prior.
• Install: New

Desktop (please complete the following information):

• OS: Windows
• Version: 10

Additional context Note that in the case where the remote GM had the campaign file on his PC to begin with there won't be an issue. The issue is specific to the situation where the campaign is being modified on the server PC and not on the GM's PC.

[Azhrei]

I want to give a shout out to Jamz for narrowing down where the problem was with this one!

What's the best solution? Do we warn the GM that not all assets are available and they'll be downloaded? Or go ahead and download them? I'm thinking the GM needs to know so that they don't disconnect prematurely...

[rkathey]

Shouldn’t they be transferred as part of the day initial asset transfer?

[Phergus]

Good question. We could trigger a download of all assets known by the campaign file but not already cached but that might actually take longer than the GM wants to deal with at that time.

A warning when logging in as a remote GM that only used/viewed assets will be transferred?

[Phergus]

Keith - only viewed assets are transferred from server to clients including GM clients.

[JamzTheMan]

We could use a background process that downloads all assets to the GM (that are not in use) but only when the server & gm clients are not busy.

We could grey out the Save Campaign menu options unless you load the campaign?

Actually, now I wonder, If I start the server but the GM loads the campaign, and I save the campaign, what happens?

[Phergus]

Actually, now I wonder, If I start the server but the GM loads the campaign, and I save the campaign, what happens?

The Open Campaign option is disabled for remote GMs. Probably because there is no provision for sending the entire file to the server and then having it loaded remotely.

Short term, a warning to the remote GM that not all assets will be saved? Perhaps leave a solution till 2.0?

Wonder if the remote GM goes into the campaign properties and checks the states will they transfer? Same for table images? Will have to check.

[rkathey]

If we aren't going to transfer all the states and such we shouldn't allow the save to the remote machine. Either that or the save retrieves the vital assets upon save with a warning that this is going to take a while. Another option would be to have the GM kick off the save on the server machine.

Seems like the easier option is to grey out the option in this situation and have the GM communicate with the server host to save the file.

[JamzTheMan]

I agree, either it should not be an option or we force a full sync.

[dorpond]

I sit here and ask myself the use case for having another person help me, the GM, and all my scenarios come back around to me asking the question “why would I want them saving my campaign”?

I wouldn’t. The campaign is mine and I am letting them help me for a session or two.

-Am I letting them help me build it, ahead of session? Probably not, but I can see that perhaps, especially if we are teaching another GM how to use MT, but we could leverage screen sharing apps for teaching, I suppose. As cool as coauthoring a campaign may sound, I’d love to know who actually does it, but even then, do we need them saving it afterwards?

-Am I handing the session off to them, to run for me while I am on vacation? Probably not, and if I was, I would send them my campaign via OneDrive, Dropbox or a Thumb-drive.

The only time I ever wanted a Client to connect as a GM, was to help me play NPC’s or Monsters during a session or two - they were a special guest, but I don’t need them to save my campaign.

I suppose in a pinch, a connected GM might be able to save a campaign if my session crashed due to a memory setting being too low or something, but that is the only use case scenario that I could imagine, where I would want someone else downloading and saving my campaign.

Why would I want anyone else having all my asset cache for the whole campaign?

Also, I can recall a time or two, where new users of MT forget to set a password for the GM session, and their players accidentally connected as GM’s - would we want those players saving the whole campaign? Yikes!

So in conclusion, do we even want connected GM’s having a save option at all? I see no reason why we would want that.

Give me your use case to support such a thing.

[Phergus]

@dorpond You're assuming the remote is a second GM. You've forgotten that some folks have others host the server as they are not able to for reasons such as unreliable connections or network restrictions. The GM should be able to save the campaign.

Clearly there are issues with getting all the assets. There is an obvious workaround as the campaign can be saved on the hosting computer and then transferred back to the GM via normal file-sharing.

[dorpond]

So the person with the unreliable connection, sends his campaign file to someone else, to host it, so that the GM can run the session remotely? And then we want that GM to be able to save over that unreliable network after session?

Would the host be the one saving it, because they have the reliable connection? Lol.

Maybe I just don’t understand all these strange ways people are using MT. Sounds like we need a headless server mode instead. Heh.

[rkathey]

I've added and deleted words around the headless option a few times in this discussion. I think for the 1.5 fix we simply disable the option. Longer-term headless is a solid fix but very work-intensive.

[Phergus]

Maybe I just don’t understand all these strange ways people are using MT.

True.

[Azhrei]

Phergus is correct. I have multiple times been on hotel WiFi where UPNP won't work and I don't control the router (without hacking it, that is 😉), so the only solution is for a player to be the server. However, even in those cases, I would typically load the campaign from the hotel so the asset issue isn't a problem (but I believe there are other issues, I just don't remember them off-hand). Because of those other issues, I've had a player I trust load the campaign. And I can definitely see saving it locally so I don't have to deal with transferring some huge campaign file.

I'm with Jamz — either disable the save option, or make it work properly. Disabling the option means only the server can save the campaign and only if they loaded it (whether Player or GM), or only a remote GM can save it if they're the one that loaded it. If a second GM is allowed to save it, the issue occurs.

The above needs to be implemented whether we force he download of assets or not, so we should probably start there (phase 1). And if we do want to download all assets, we can put up the same screen that we use when loading a map to show how many assets need to be transferred (phase 2).

Does that work for everyone?

[JamzTheMan]

@Azhrei I'm good with that.

@dorpond Please remember some of us play Face to Face so there are other reasons to do this. For me, I'm the only one that plugs into the wired network because I have a doc (and most people use laptops that do not have lan adapters without using a dock or doggle so use wireless) We have constant disconnects for some people so I always host the server (usually as a player)

I also am the "IT Guy" which means I maintain the Framework/Macros so I need full access to the campaign files (All GM's have a shared folder with me over Google Drive).

At the end of the night, the GM doesn't want to "wait" for me to save, it to sync to Google Drive and for it to sync back (they can be an impatient bunch) so they will save it on their laptop and close down.

And this is how I've come to know this issue.

Also, @Azhrei the "save campaign" option can remain "disabled" for players even if they loaded the campaign and is the server. Simply because, once I shut the server down, I'm "GM" again and can save that way. (It can also be enabled but I wouldn't worry about it if it's an effort)

[Phergus]

Disabling the Save option on all clients but the server will at the very least keep people from ending up with incomplete campaign files.

Another thought. A campaign repo might be another workaround. If the non-server GM saves the campaign file it should keep the reference to the repo and thus have access to all of the assets.

[psychomantys]

headless

Maybe I just don’t understand all these strange ways people are using MT. Sounds like we need a headless server mode instead. Heh.

A headless mode is a nice think to have and a great addition.

This is my dream to Happily make a docker image and a stack for this.

[Azhrei]

I have a Dockerfile (named with .txt for GitHub) that I have attached here. It's not headless — since MT isn't — but it can run as an AWS instance pretty easily and you can use Remote Desktop to manage the server instance. It's probably not appropriate to detail that here, so I'll write up a page on the RPTools wiki and attach the file there sometime in the next few days to explain some of the details. It's provided as-is, since I won't have time to maintain it much in the short-term. Dockerfile.txt