Working with the registry...

[Oberoten]

It was mentioned in another thread that the campaign registry might be a good place to store variables for everyone. Like per example a target value for rolls or a flag to see if a dice is wild or normal et all.

This is very interesting. Sadly there is no documentation on how to do this in the library here at the site.

Anyone that can give any pointers on how to store/retrieve things from the registry?

[Foen]

Hmm, I'm not very familiar with the campaign registry, but didn't think it was visible to clients.

For settings that need to be seen by the host and clients, I've tended to use the database.

Sorry I'm not much help, perhaps Toadwart has some wise words?

Stuart

[joshuha]

The registry files are only local to the users machines but are good for storing toggles for that user. It is much faster access than the DB and there are two types. CampaignRegistry and GlobalRegistry are the two registry files where Campaign is specific to just that campaign and Global can be accessed by any campaign.

Storing and retrieving a variable to the registry files is very simple. You just set it and get it like any other variable but precede with the registry location. Note that the registry does support tables. I used this in the Savage Worlds ruleset to store things like the toggle for the wild die control, the contents of the deck on the GM side, etc.



CampaignRegistry.variablename = value;
if CampaignRegistry.variablename == comparision then
end

[Oberoten]

What would then be the best way to set a toggle on the GM-side to make sure it would work for all players? I expect that there is a way to monitor a DB entry, but only if every player is a holder.

[Moon Wizard]

That's exactly what you have to do, in order to make an option GM-controlled for all clients. You have to set up a portion of the database for which all clients are subscribed as holders, but only allow the host to make changes to these options.

Check out my v3.5 D&D upgraded ruleset. I actually did this to support campaign-wide GM-controlled options, like "Show NPC names on rolls", etc. (Note: I also used registry entries for per-client options like double-click rolling.)

Cheers,
JPG

[Oberoten]

These snippets from characterlist.lua :



function onLogin(username, activated)
ChatManager.addWatcher("options", username);
ChatManager.addWatcher("combattracker", username);
end


and



function onInit()
User.onLogin = onLogin;
User.onUserStateChange = onUserStateChange;
User.onIdentityActivation = onIdentityActivation;
User.onIdentityStateChange = onIdentityStateChange;
end



Should be the most important parts of the key on how to handle this, yes?

[Moon Wizard]

Yes, I added the code to onLogin (which was already part of d20 ruleset), and added the addWatcher function to specify which node I wanted to share.

Then, the clients will be updated with any changes to those database nodes. You can either subscribe via an onUpdate function, or just query the node when you want to check the value.

Cheers,
JPG

[Oberoten]

Once again... I am stumped. Worked with this for the evening and somehow I get only error messages.

I created a nice little "Target" box in the DesktopPanels.xml
Not so hot looking ATM, just a copy of the modifier box. Trick is that I aim to share it to the players so that I can set a target difficulty for an action they are attempting.

I made it a field, made sure that the field in question should be shared and all... yet it doesn't. I am doing something wrong no doubt but I can't seem to figure out what the problem is.

Each player is added to the field on login as a holder ... but can't even find the field in the DB... Very very wierd.

[Foen]

Oberoten

You might want to create your own code module for this rather than relying on the onInit event in characterlist.lua.

A code module registered in base.xml receives its own onInit events and can access the onLogin event for new connections. It keeps the code cleaner and removes a dependency on characterlist.lua (which might change in the future).

The line to add to base.xml is:



<script name="TargetManager" file="scripts/targetmanager.lua" />


You can then create your own target manager code module, which would include:



function onLogin(username, activated)
if User.isHost() and targetnode then
if activated then
targetnode.addHolder(username, false);
else
targetnode.removeHolder(username);
end
end
end

function onInit()
User.onLogin = onLogin;
end


This adds the newly-logged-on user as a holder (not owner, hence the second argument is false) of the target node, and removes them on logoff.

You could then add a method in targetmanager.lua to return the top-level target db node:



function getTargetNode()
if not targetnode then
targetnode = DB.createNode("target");
end
return targetnode;
end


Elsewhere in your code, you can invoke TargetManager.getTargetNode() and it should return the DB node of the new target sub-tree (whether from host or client).

Hope that helps,

Stuart

[Oberoten]

Hmmmm... I am starting to think that the problem is more with me using a panel than anything else.

But so far it does not update when I change it nor save it to the DB at all.

[Moon Wizard]

I'm not sure if this is helpful, but you might want to try breaking down the work a bit.

When I was working on the client tracker and options dialog, I made sure that the host could access all the same views/functions. Then, once I verified everything was working on the host side, then I attempted to implement on the client side.

Since I ran into challenges in both stages, it was easier to do this way.

JPG

[Foen]

That is the same approach I used for a host/client shared combat tracker. In fact, it means you don't have two separate code forks to maintain in parallel.

Stuart

[Oberoten]

Right now the major problem is that I can't get it to write the data to the DB for some reason.

[Moon Wizard]

I would rip out any code relating to sharing the database node, and just focus on getting the data to save to the database with the panel. Just like you were making any other window for the GM side.

Given that there are no panels that save data, only panels that have buttons which open windows that save data, perhaps you've hit a limitation?

You can try posting your code, if you'd like others to take a look.

JPG

[Oberoten]

Hmm.. Decidedly starting to think that panels can't hold numberfields now...

Any official word from the developers on this? Any chance to get it fixed to the next version of FG or is this so by intention?

[Toadwart]

Looks like it is by-design

From the Library reference:
Each panel contains a window instance. The window instance is created with no data source. The window class used for the panel should not contain any positioning or size constraints. In other regards, the window functions similarly to conventional windows and can contain all the same functionality.

However, you can probably bypass this limitation using lua script. The DB.createNode and DB.findNode functions should grant you access to the database.

[Oberoten]

Ah... At the least I haven't been getting stupider then. :)
Yeah, it should be pretty possible. :) OnUpdate should at the least write the DB... *hmmm* Might be a problem updating the value on the other side though.

[Bidmaron]

Obi-wan, can you share your eventual solution with us padwan-learners?