Party inventory control only rendering for host

[anathemort]

Hello,
I am extending my search extension to add a search control to the party inventory ("ps_inventory"). I am merging my windowclass with that one, and it works well from the host side. The weird thing is that connected clients do not get the search input box, but they do see the empty text placeholder ("Search"). The code is straightforward:


<?xml version="1.0" encoding="iso-8859-1"?>
<root>
<windowclass name="ps_inventory" merge="join">
<script file="scripts/inventory_search.lua"/>

<sheetdata>
<basicstring name="inv_search_input">
<anchored to="itemlist" position="aboveleft" offset="5,25" width="100"/>
<empty>
<textres>search</textres>
</empty>
<tabtarget next="inv_search_input" prev="itemlist"/>
</basicstring>

<buttoncontrol name="inv_search_clear_btn">
<anchored to="inv_search_input" position="right" offset="10,0" relation="relative" width="20"/>
<icon normal="button_clear" pressed="button_clear_down"/>
<invisible/>
<tooltip textres="tooltip_clear"/>
</buttoncontrol>
</sheetdata>
</windowclass>
</root>


This is the host view:
50830

This is the client view:
50831

[Trenloe]

What is your scripts/inventory_search.lua <script> doing? This will be overriding the ps/scripts/ps_inv.lua script that is set for the base ps_inventory windowclass. You may need to add some super code to the inventory_search.lua code to call the ps_inv.lua code.

[anathemort]

What is your scripts/inventory_search.lua <script> doing? This will be overriding the ps/scripts/ps_inv.lua script that is set for the base ps_inventory windowclass. You may need to add some super code to the inventory_search.lua code to call the ps_inv.lua code.

Not very much, but it's not calling any super. You can see it here (https://gitlab.com/anathemort/FGInventorySearch/-/blob/master/src/scripts/inventory_search.lua).

If I'm doing a merge, are you sure it's overriding? The same script is used for normal inventory search and it's not interrupting the char_inventory that's in that merge target.

[Trenloe]

Not very much, but it's not calling any super. You can see it here (https://gitlab.com/anathemort/FGInventorySearch/-/blob/master/src/scripts/inventory_search.lua).
I can't access that.


If I'm doing a merge, are you sure it's overriding? The same script is used for normal inventory search and it's not interrupting the char_inventory that's in that merge target.
Scripts don't fully merge, they form a layered hierarchy if the function names are the same - with the earlier defined script functions accessible through the super variable - see here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996644496/Ruleset+-+Scripting#Script-Block-Scope

[anathemort]

I can't access that.


Scripts don't fully merge, they form a layered hierarchy if the function names are the same - with the earlier defined script functions accessible through the super variable - see here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996644496/Ruleset+-+Scripting#Script-Block-Scope

Sorry, I fixed the access issue. Can you see if there's an issue there? Do I need to call super onInit?

[Trenloe]

You should have this at the beginning of your onInit function:


if super and super.onInit then
super.onInit();
end

The other functions in ps_inv.lua have different names to the functions in your invesntory_search.lua file, so these should be still available - but you should test to ensure these are still running correctly as I haven't tried this in anger in FGU.

[anathemort]

After adding that snippet, and only that, it's actually worse :D The placeholder text shows up in the middle of the window now:

50838

[Trenloe]

After adding that snippet, and only that, it's actually worse :D The placeholder text shows up in the middle of the window now:

50838
That's because the campaign setting Game (GM) - Party:Show inventory to client is set to Off. The code for that option is ran as part of the original onInit code - so now that you're running that code using super.onInit it's reading the campaign option and not showing the party coins or party items. You can see this code in onOptionChanged in the original ps_inv.lua. So you will have to code in your extension to take into account showing the search controls on the player side only if that campaign option is on.

Now we've got the correct init code running, let's see what the issue is with that search appearing correctly for the player...

[Trenloe]

Now we've got the correct init code running, let's see what the issue is with that search appearing correctly for the player...
So, the issue is that the string template used (basicstring) is actually a stringfield control (database bound). As players can't change the database area where that control is bound, then it is shown as read only for the players.

To make it work, the control needs to be changed to a stringcontrol (no stringfield). Unfortunately there's no basicstring control (not field) template so the frame code from basicstring needs to be included in the XML and the base template needs to be changed to simplestringc.

So, try this:


<simplestringc name="inv_search_input">
<anchored to="itemlist" position="aboveleft" offset="5,25" width="100"/>
<empty>
<textres>search</textres>
</empty>
<tabtarget next="inv_search_input" prev="itemlist"/>
<frame mergerule="replace" name="fielddark" offset="7,5,7,5" hidereadonly="true" />
<stateframe>
<keyedit name="fieldfocus" offset="7,5,7,5" />
<hover name="fieldfocus" offset="7,5,7,5" hidereadonly="true" />
<drophilight name="fieldfocus" offset="7,5,7,5" hidereadonly="true" />
</stateframe>
</simplestringc>

[Trenloe]

Note - the earlier comments about the script layering is still very valid - without this the campaign option won't be applied; also if the extension is enabled for a new campaign the coin categories won't be set in the party sheet, as these are built in the base onInit function.

And you also need to code to hide that search field on the player side if the Party:Show inventory campaign option is set to off, as it makes no sense to show it if the players can't see the party inventory.

[anathemort]

Interesting! Thanks for the guidance, Trenloe. I'll report back with my results! :)

[anathemort]

Thanks again for this, Trenloe. Actually implementing the unbound search control works really well, and it fixes some another questionable issue I was having. Working really well now, thank you!

[anathemort]

@Trenloe I think it's a similar problem I'm having here (https://gitlab.com/anathemort/FGInventorySearch/-/blob/inventory-filter/src/xml/record_char_inventory_search_5E.xml#L34) where I am using the combobox template. Internally, the combobox uses a simplestring too, so that is a shared node (when I change the value on the host, it changes on the client). I could use simplestringc to rebuild the combobox, but then is it possible to reference the combobox LUA script from CoreRPG? Or maybe there is a different way to "unlink" host/client in this case?

[Trenloe]

@Trenloe I think it's a similar problem I'm having here (https://gitlab.com/anathemort/FGInventorySearch/-/blob/inventory-filter/src/xml/record_char_inventory_search_5E.xml#L34) where I am using the combobox template. Internally, the combobox uses a simplestring too, so that is a shared node (when I change the value on the host, it changes on the client). I could use simplestringc to rebuild the combobox, but then is it possible to reference the combobox LUA script from CoreRPG? Or maybe there is a different way to "unlink" host/client in this case?
If you want the same data to be displayed on the GM and PC then tie it to a database node - the issue with this is that only the GM and an owning player (once ownership is granted) can change that data. Making assumptions from your XML code, the combox box will be on the character sheet? If so, then the GM and the owning player (the only person who can open the character sheet) will be able to change the combobox value, and this will be shown on both the GM side and the player side whoever makes the change - so you need to consider cases like this carefully as in gneral you don't want a PC sheet displaying differently (and therefore potentially running different code) on both the GM side and the player side as it could screw up the view/data for either the player or the GM and result in incorrect data on the character sheet. However, in this case as it's just a filter this may not be an issue - see the end of the next paragraph.

If it's a common window - like the party sheet, you don't want to use a database sourced control as then only the GM can change it and it would change for all players - unless this is the desired functionality. If you want combobox selections to be different across the GM and players then use the comboboxc template which uses a simplestringc template to store the selected value - the main gotcha here is that the result isn't stored in the database, so it won't persist between sessions of FG.

[anathemort]

Trenloe, thanks for the dive. The comboboxc is exactly what I was looking for. In my case, I don't want the value persisted, nor do I want the filter shared, so simplestringc and comboboxc are perfect.

[Trenloe]

Trenloe, thanks for the dive. The comboboxc is exactly what I was looking for. In my case, I don't want the value persisted, nor do I want the filter shared, so simplestringc and comboboxc are perfect.
Great! :D