PDA

View Full Version : 2.8 Feature request: Force create node



Ikael
July 5th, 2011, 21:23
This post is especially for the FG staff/developers

I have been doing migration for Unicore ruleset from 2.0 to 2.8 compatable and during the voyage I have experienced very nasty stopper on the way. On FGII v.2.4 compatability issue/fix state:

"Players can no longer create database nodes within database trees they do not own."

I understand that before this has been a bug and it's generally sensible that non-owner cannot create nodes for xml trees. However this compatabiliy fix is a total stopper for Unicore's client combat tracker. The reason is that Unicore dynamically generates fields that are displayed on the tracker for both GM and for players. The issue is for players where when combat tracker is shared as client tracker and new entry is added to the list, the player won't have access to nodes. Only the "fixed" ones are there but all those dynamic fields are created using windowlists and for some reason players see all windowlists as nil entries. The issue could be resolved by closing combat tracker and re-sharing it, but this is not meanful way to handle the issue.

I was having the same issue with 2.0 compatable ruleset but I could easily create nodes as a client which would oversome the issue. Unforuntately after 2.4 it's not possible at all :( . Changing the ownership is neither and alternative nor good practise to resolve this.

So my initial thoughts were that could it be sensible feature to have ability to allow clients to create nodes 'by force'? I mean that could there be optional parameter on createNode functions that could ignore the owner check? In this case the common way would be to respect the owner but in some cases the developers would want to have freedom and take the responsibility themselves to add such a code that would break the sacred line (ownership of the node).

I am not sure if I am able to give good code examples about my issue as the dynamic logic on client tracker is very complicated, but if people see it necessary I can give a try.

Zeus
July 5th, 2011, 21:42
Hmmm. Not sure about the 'allowing clients to create nodes under XML nodes they do not own by force' approach. This could lead to situations which break the integrity of the database.

As an alternative approach, what you could do is update the CT code in your ruleset such that when an entry in the CT windowlist is created, in its onInit() function, you loop through all active identities adding a holder tag for each identity to the windowlist entry. Adding a holder tag to a node will automatically apply the holder tag to all child nodes.

This will give clients (owners of the identities), read permission for the entry's nodes, regardless of the fact the clients do not own the nodes. From there on in when you create a new CT entry, all clients will see the windowlist entries. This is the common approach thats taken in 4E and 3.5E when sharing windows which use a windowlist.

Your ruleset is probably only adding holder tags when the CT is opened and shared, hence the reason why entries created after sharing are not seen by clients.

Ikael
July 5th, 2011, 21:58
Thanks for your input, but I already have such code that gives holding to all players. The issue won't appear if I have entries already in non-shared combat tracker and I share it after that. In that case players will see the nodes and have access to them. But my issues comes when I have already shared combat tracker where GM will add entries. For some reason windowlists inside entries are seen as nil and even for stranger case the first, or the second or the third (etc) windowlist's window database node is never seen nor accessed. This issue seems like that windowlist nodes inside combat tracker entries are actually created during the sharing process.

I do not agree that 'node creation by force' could ruin database integrity as it's only optional way of doing it and it's ruleset developer's responsible to avoid such all possible issues. I have been doing very well with the feature for long time but I have always known what I can and what I should not do with the feature.

Ikael
July 5th, 2011, 22:06
and to point out again, in 3.5E and in 4E rulesets there are lots of "fixed" fields such as HP, Initiative etc. which are presented as one simple controls. But in my case I create those fields as windowlists. For example I have rules configuration file that state that you you field A, B and C, and when you open you combat tracker each entry will automatically create windowlist with which "fields". So basically the issue is to have windowlist windows inside windowlist windows. I used to allow clients to create nodes to which represent the fields (they all have pre-declared full nodename) and so I get the access to them during any part of the code even if they are not created yet by the windowlist itself. But now that I cannot create those nodes I simply have no access to them until combat tracker is closed and shared again (not a good practise).

Zeus
July 5th, 2011, 22:40
OK understood.

I still think the issue lies in that the your code probably only adds holder tags when the window is opened and shared and not when the windowlist entries are created.

Creating sub controls dynamically should not really matter, you can check out my 4E Tables extension as an example. It uses windowlists within windowlists to create the columns and rows all of which are created dynamically.

I would take a look at the campaign db.xml file and review the nodes under the CT window, do all the nodes have the correct holder tags?

What about the nodes for any dynamically created fields (assumed to be bound)?

Ikael
July 6th, 2011, 18:29
I tested your suggestion but no result there. I have made also several other tests and I think I have narrowed the issue to this: it's about timing. I want to have access to databasenodes during onInit, but for some strange reason the first node of the windowlist is never available.

In the test I created new debugging function that will print client's combattracker nodetree completely to the output console. I did also create slashcommand that can be used to call out the function. Now during all windowlist's and it's child window's onInit (and in one field of the child window, and in one another controller outside the windowlist) I call the function and the result is that only "fixed" fields are there and windowlists are seen as nil. The only exception is that when first windowlist's window is created some windowlist nodes are there...

when I use the slashcommand after that, I get the full nodetree! There is no issue with this when inputing/adding fields manually. So my issue actually is how I could alter the timing of creating dynamic entries, the fact is that it must be done programmicatilly at start, but how can I do that?

Zeus
July 6th, 2011, 19:40
Its kinda of difficult to understand the exact cause of what your describing, perhaps if you could post up some of the code it would help.

In terms of controlling when dynamic runtime controls are built, if the controls are built based upon the values of other fields then you would want to create them during the initialisation phase i.e. in onInit() and then update them should the source field values change i.e. in the source fields onValueChanged() or via the source fields databasenode and an update() handler.

Or perhaps I have misunderstood the issue.

Ikael
July 7th, 2011, 18:59
I just solved the case. The question was about timing: when database node will be accessed and I believe I had some bad code in initialization that somehow broke in the current build. The solution was to call window initialization code after all nodes can be accessed and I had to move the accessing code from windowlist item's control level to item's window level. I didn't know that onInit is called for controls before it's called for the window level and that's where my old code got scrapped badly.

Anyways, needless to say, thanks DrZeuss for your effort again, you made me believe it's possible without need to new features in FG engine :)