Full License Questions...

[HoloGnome]

Hi -

A couple of questions relating to license/login:

1. As a full license holder, am I allowed to run a GM instance on one machine and a client instance on another? I know that it offers

For example, I want to leave a server machine up-and-running for players to log in and access characters when we are not actively gaming, but I still want to use my client from my laptop. I haven't tried it yet with the same license code, but I don't want to run into licensing errors. At the moment, I am using a license that our group purchased for someone who isn't currently playing, but if he wants to play, I might need to use a different strategy (although that license is also a full license).

2. Is there a way to log in from the FG2 client as the GM user and control the game, even though you are not on the game machine. It would, of course, be possible using Windows Remote Access or other screen-sharing software, but I would rather have the ability to log in as a super-user from a remote client. That way, I could set up FG2 to host the campaign, set up a murmur/mumble server and just let them run 24/7, even though I am traveling around as the remote GM.

ps. Also, you may be interested to know that the FG2 installer doesn't seem to correctly handle installs on Windows Server R8 - on my attempt, it put the data directory in the AppData of the Admin user instead of the current (non-admin) user. I used FG2 settings to remap the location of the data directory to the current (non-admin) user's AppData directory, but every time I run FG2, I have to run the updater so that it can "discover" where the data directory is. Otherwise, none of the campaigns/rules D&D rulesets show up. So, FG2 does not seem to be checking or correctly accessing the user data directory on launch...but once it finds it, it seems to work normally for that session.

[damned]

Hi HoloGnome -

You can run FG on 2 computers but not at the same time - or certainly not connected to each other. You will get a license error.
You can run a second instance on your GM computer and connect it to localhost which will show you the player view and is a fully functioning client but it is on the same physical computer so not much good for player use - only for GM use.
You can run an instance on 2 different computers if for example you do some prep work on one machine and run your actual games on the other but the two cannot connect as client/host.
There is no "remote admin" type mode which is what I think you are asking. Remote desktop would be the best way to achieve this. I have thought about doing this as I have hosted servers with 100x the upload speed of my home network... but too many other competing priorities...

I have installed FG on server 2008r2 without issues before.Is it possible you did install as the Admin user and installed only for the current user?

regards
Damian

[HoloGnome]

Hi Damian -

OK. Thanks. I understand. Thoughts are as follows:

1. I would like there to be some kind of GM-only mode license extension or allowance so that I can use my copy to host a game on a central server instead of having to buy another full license. I would either use it w/ Remote Desktop or just have it there for players to access and work on things, but I would like my main installation to function normally and not care that I have declared a GM-only install.

2. Remote Desktop is OK, but screen-sharing is not my favorite thing. I completely agree with you about the remote serving. It would be great to have remote GM login mode - maybe not too far removed from the way player clients work today, except with an event-passing hub as the server (event-passing mode activated when it sees the remote GM license sign on and take control) + the necessary content sync (when GM signs on in order to pick up player changes since last gaming session and post new maps, etc.). Otherwise, when the remote GM signs off, it goes back to acting like a primary server.

3. I installed it as the runtime user (but had to give Admin permission, of course). The install went into the standard install directory (C:\progs x86\fg) and failed to create the data directory in either Admin (not surprisingly) or user (more surprisingly) AppData. I manually created the data dir in the user AppData and copied my existing install (same version), then remapped the location in the Launcher settings. Everything seems to work, but it refuses to acknowledge the data dir location unless I run an update check, even though the data path is correct in the settings. Does that explanation help?

Thanks.

ps. Also, there was no Firewall step. I had to manually create the Incoming UDP/TCP rules for Port 1802.

[damned]

I dont think there is any plan to change the way the GM license/server works. It would be a big rewrite and its not a common request.
FG should be installed as a normal user (or power or admin user) and not as a runtime user. You are imposing a non standard environment on it.
UPNP will open ports on UPNP devices - not on software firewalls.
Windows Firewall on Server is not designed to automatically allow ports or to prompt you to allow ports. Its designed to be on only and modified specifically as needed.
No UDP required - just Inbound TCP 1802.

[HoloGnome]

Thanks damned - just a suggestion to improve the product. An always-on central server with remote GM capability would be great. Also, it could be done with intelligent virtualization of user i/o over the network with minimal impact on the current design. Whether an app sees you type or click locally on a keyboard or those events are generated remotely doesn't really matter, and the app already supports showing screen content to remote clients.

On the firewall front, installers on Windows most definitely have the ability to install firewall exceptions through various means (where windows firewall is the most common use case). Also, failing a pre-installed exception, windows should prompt the user to allow the exception at first launch. I'm not sure why it didn't work on the server install. That being said, anyone behind a typical router also needs to do port-forwarding. So, automatic OS firewall config. only solves 1/2 the problem. So, depending on perspective, there is an argument in favor of tech note mode.

I will try a few experiments with admin/user level to see if anything fixes the strange problem I'm seeing and let you know. When I say "runtime user", I mean a non-admin user. However, since the app seems to run fine as this regular, non-admin user and supports an alternate data directory path, the problem of the app not finding the data directory may actually represent a bug. Is the app. definitely checking the custom user path setting when it starts, or is it possible that it's looking for the default path the installer tried to set up and somehow missing the fact that the user changed the path in settings? Not implying anything here, just a question that can only be verified on the developer side.

Thx for the TCP vs. UDP info. I will delete the UDP firewall entries. I just assumed both were required - probably saw it at some non-FG site.

[HoloGnome]

After some testing, it appears that Fantasy Grounds can run from anywhere (either C: or a different drive for both app and user data) and find the campaign data as long as it runs as Administrator under Windows Server 2008 R2. I tried various combinations of app location and data directory location and all worked (again, if run as admin). If I run as non-admin, it doesn't see user data and the campaign screen is blank, as before.

Where is the application storing the user setting app/data paths? They do not appear to be in the app directory, the data directory, or in the Windows registry. Are they being stored remotely? The license key is obviously being stored locally in the registry, and I expected to see the other settings. Are the paths being stored as binary data somewhere for script/dos execution? I see the dos window when settings executes.

In theory, the application should be able to run without requiring that it run as Administrator. It may be worth a look at the startup process to eliminate the need for running with escalated privileges. Also, it might facilitate compatibility to use the Windows Registry to store the data directory path.

I hope this info helps others who have the same missing campaign info issue when not running as Admin.

[ddavison]

HoloGnome, you can run multiple instances on different computers. You won't be able to host games on both systems simultaneously or use one as a player and the other as a GM, but it should allow you to build content on a second machine without another license.

You'll want to launch FG and choose the Settings option to see where the paths are listed. You can change them there.

[HoloGnome]

Thanks. My ideal uses would be:

1. Leave one in GM-only mode for the campaign on a server that runs 24/7
2. Be able to use my main machine as a player in other campaigns
3. Be able to "take over" the license to GM on my main machine (the other server would go inactive) - one way to do this would be to extend the license model to include the concept of a slave ID that could be superseded by a master one so that only 1 instance was running at any time.
4. At some point down the road, be able to remotely GM on the main server and easily sync content from my local machine to the server.

My question about the settings is where are the settings variables being stored? File, registry, remotely?

[damned]

HKCU\Software\Fantasy Grounds\2.0

[HoloGnome]

OK - I think I have resolved this issue. Here's what was happening:

The reason FG needed Administrator access was because in the non-admin user context, the registry did not contain the necessary registry keys (only the license key was there). I was aware of the HKCU entry before, but didn't see the keys, hence my earlier question. HOWEVER, when I checked the registry for the admin user, they were there. So, I exported the keys on the admin user side, imported them to the non-admin user registry and Fantasy Grounds now runs in non-admin mode and can see campaign data without requiring Administrator privileges/password. So, if anyone has this problem, check your registry. They keys are probably missing in the runtime context as the were in my install. Also, while my app path still points to C:, it means that the app will run from anywhere as long as the runtime user registry has the correct info.

damned - was about to disagree with your post, but then I checked on my non-server machine and saw the expected keys which tipped me off. Thanks. Your post helped me find what I was overlooking. ;)

[HoloGnome]

The other shoe dropping here is that, from an installer coding/scripting standpoint, if the application installs in user context X, then it should be sure to build the registry keys in user context X to avoid requiring escalated privileges at runtime.

[damned]

You are installing what is a program designed to be run on a PC onto a server using an account that has limited ability to write to the server. Your system security is trumping the applications installers rights. When you install SQL or Exchange on the server you do it as an Administrative user and it can then gain access to write to the registry and even make changes/recommendations to the Firewall etc.

[HoloGnome]

Yes - I know - that's the point of non-admin accounts - but when the installer asks for Admin permission, the expectation is that it will do the right thing. If it doesn't, there is room for improvement. Windows Server vs. Windows PC doesn't really matter. You could be running as a non-admin user on a PC as easily as on a server. Anyway, it works now, and I know what the solution is in my case. I would suggest including server installs in the QA OS matrix and making some minor changes to the installer so that it handles non-admin users correctly.

[JohnD]

It's worth noting that if you don't know what you are doing (be honest with yourself), don't go stumbling around in the registry.

[damned]

I try telling my players not to go stumbling around in all sorts of places... do you think they listen?

[HoloGnome]

WARNING: As others have indicated, when editing the registry it is possible to screw up your Windows install and make your OS inoperable if you don't know what you're doing, make a mistake or otherwise do something you don't intend. So, unless you're sure you know what you're doing, do not attempt to edit the registry. That being said, basic registry editing is not rocket science, but requires care and understanding.

How to Modify Fantasy Grounds keys in the Windows Regsitry:

1. Go to the Windows/Start Menu
2. Type "regedit" in the search field
3. Hit return and "yes" when the regedit permission dialog appears
4. The registry should now appear
5. Select "Computer" at the top of the list
6. Select "Export" from the File menu
7. Choose a save location and filename - this is your backup of all the locations that regedit can see. Note that regedit cannot see all registry locations. It is handy to have a registry backup (and a backup of your computer in general) in the event of problems.

8. To find Fantasy Grounds' entries:
a. Expand HKEY_CURRENT_USER
b. Expand Software
c. Expand Fantasy Grounds

You should now see all the Fantasy Grounds registry keys, including things like data directory, app location and dice color, etc. Click on the "Fantasy Grounds" folder in the nav on the left and repeat step 7 above to save a copy (.reg file) of just the Fantasy Ground registry keys. (A good idea to save for quick comparison/restore.)

If you want to import the Fantasy Grounds keys to another location (like a non-admin user location on a Windows server), choose Import from the file menu and select a saved Fantasy Grounds key file. Alternately, you can just double-click on your Fantasy Grounds saved .reg file. NOTE: on registry Import, existing keys will be overwritten with the data you are importing, so please be careful, or you may end up losing data.

For more info: Google - "editing the windows registry"