DB.getValue() for a shortcut node does not return the entered path

[Simpe]

Hi,

I'm trying to run DB.getValue(node, childname) on a node in a module I've created. The function should return the recordname entered at that path, which is "reference.traits.armored@Symbaroum Core Rulebook" but instead I get "npc.test.traits.armored@Badlink test".

The code I'm running is this:

       local the_node = DB.findNode("npc.test.traits.armored@Badlink test")
     if the_node then
         local shortcut_class, shortcut_nodeid = DB.getValue(the_node, "shortcut")
         Debug.chat("FOUND shortcut:", shortcut_class, shortcut_nodeid)
     else
         Debug.chat("Didn't find in found module ", sModule)
     end

and I'm adding it in the manager_version.lua in corerpg, in the end of the function onModuleLoad().

The module can be downloaded from https://web.rahmqvistcloud.se/share/X0Lq62f and is easy to unzip if you want to check the xml-values.

Does anybody understand why this is happening and could please explain to me what I'm doing wrong? I have this issue in a new module that we're writing and we can't complete it unless we find out why our cross-module links don't work. It seems to work nicely linking to nodes within a module.

Thanks,
Simon

[celestian]

Is "Symbaroum Core Rulebook" a read only module? If it is try removing the RO flag (I'm assuming this is your module), re-export then try.

[Trenloe]

A couple of general FG coding things here -
1) You're trying to return the DB.getValue of the shortcut DB node in the database - this doesn't have a value: <shortcut type="windowreference">
2) You're looking for 2 return values, whereas DB.getValue will only return 1.

You could try:

local shortcut_class = DB.getValue(the_node, "shortcut.class")
local shortcut_nodeid = DB.getValue(the_node, "shortcut.recordname")

I haven't tested the above, so don't know if that will work. The FG API very often restricts which DB nodes you can access with LUA code, especially within a specific DB node structure (for example, you can't access all of the <image> node data directly in the FG database). I don't know if this will be the case with this example, as FG *might* restrict accessing data in a <shortcut type="windowreference"> DB node, but I don't know if this is the case here. You could try DB.getValue(the_node, "name") and see if that returned "Armored" OK, and if the other DB.getValue entries I list above don't work, it could well be the case that the FG API is not allowing access.

[Moon Wizard]

Ok, I put the module in my modules folder, then added your code at the end of CoreRPG::VersionManager:: onModuleLoad.
Next, I created a new Symbaroum campaign, went to the library, and opened the bad link module.

Here's what I got; so it looks like it is working. (see picture)

JPG

[Simpe]

Hi all and thanks for the answers!

Trenloe: I think it's special when it comes to windowreferences, as that's a special value-type in the database. DB.getValue for windowreference returns 2 values afaik.

Moon Wizard: That's weird, why isn't it working for either me or my companion?

I just tried it and got this:

Thanks,
Simon

[Trenloe]

Trenloe: I think it's special when it comes to windowreferences, as that's a special value-type in the database. DB.getValue for windowreference returns 2 values afaik.

Good to know - thanks!

[Moon Wizard]

Simpe,

My guess is that you have other changes going on that are not accounted for in the sample you sent.

Your best bet is to reset FG to the basic installs without any changes to the files. (i.e. rename current FG data folder, and re-install from scratch) Then, create a very basic extension to add a simple script which registers an onModuleLoad handler to test your code, and only add that extension and module to your FG data folder.

Basically, when something doesn't work like it does on someone else's machine, it's always best to save off your work and reset your environment so you're on the same page as everyone else.

Regards,
JPG

[Simpe]

Moon Wizard,

Yes you were correct. I tried it in another ruleset and the link works. What could I possibly have done in the ruleset that modifies how links are fetched from the DB?

EDIT: I found out that if I wrap the <npc> tag within the module inside a <reference static="true"> then the link prevails and works. Which is weird, I don't have any code that goes through and modifies links.

Thanks for helping!

[Simpe]

Hi again,

I'm still seeing issues with this.

I've started seeing it in our core ruleset where whe have links such as:

                        <shortcut type="windowreference">
                            <class>reference_mystical_power</class>
                            <recordname>reference.mystical_powers.bend_will@Symbaroum Core Rulebook - Player's Guide</recordname>
                        </shortcut>

but when I fetch it (without modifying it), it turns out to be:

reference.npcs.necromage.abilities.bend_will@Symbaroum Core Rulebook

The <npcs> tag has static set to true, which I assume then means that all children of that node is static as well? Is there anything related to this that has changed during the last month or so? We haven't had this issue before and it has started appearing pretty recently. Now I'm not sure how to debug it or how to proceed.

EDIT: We haven't changed these links since release and they've only started to break now recently.

Thanks for any help,
Simon

[Simpe]

Ok so I solved it.

The culprit is that we have the following behavior:
If you drop an ability/trait whatever onto your charactersheet or your npc which is modifiable, then the link should be updated to a copied version of the ability/trait. The copy is only done upon drag-and-drop.

Since the npc's don't have drag-and-dropped (they have hardcoded links to the items), the code was not checking for if the link that it was changing belonged to a node that was write protected. Apparently, write protected nodes are possible to write to but it causes the side effect of copying the entire node to a place where it is editable.

So what we did was that we changed the link to be to itself in certain cases, and some other code had changed this situation to happen 100% for nodes which were not editable.

So, problem solved - it was local all along

Thanks!
Simon