Windowclass script working differently in 3.3.6?

[darrenan]

In my Strain/Injury HP Variant extension for 3.5/PF I modify the client_ct_entry windowclass as follows:



<windowclass name="client_ct_entry" merge="join">
<script file="ct/scripts/clientct_entry.lua" />
<sheetdata>
<number_clientct_injury name="injury" insertbefore="wounds" />
<number_clientct_nonlethal name="nonlethal" merge="delete" />
</sheetdata>
</windowclass>


For reference, the corresponding windowclass in the 3.5 ruleset is:



<windowclass name="client_ct_entry" merge="join">
<script file="ct/scripts/clientct_entry.lua" />
<sheetdata>
<base_clientct_health name="healthbase" insertbefore="initresult" />
<string_clientct_status name="status" insertbefore="initresult" />
<number_clientct_wounds name="wounds" insertbefore="initresult" />
<number_clientct_nonlethal name="nonlethal" insertbefore="initresult" />
<number_clientct_hptemp name="hptemp" insertbefore="initresult" />
<number_clientct_hp name="hp" insertbefore="initresult" />
</sheetdata>
</windowclass>


This worked fine in 3.3.5, but in 3.3.6 I get the following script error when a player opens up the CT:


Script Error: [string "ct/scripts/clientct_entry.lua"]:20: attempt to index global 'nonlethal' (a nil value)

This leads me to believe that the copy of ct/scripts/clientct_entry.lua from the 3.5 ruleset is being used instead of mine, because my copy does not make any reference to the nonlethal control at all:



function onHealthChanged()
local sColor = ActorManager2.getWoundColor("ct", getDatabaseNode());

wounds.setColor(sColor);
injury.setColor(sColor); <-- Line 20
status.setColor(sColor);
end


Again, for reference, here is the same function from the 3.5 ruleset showing the line that I think is generating the script error:



function onHealthChanged()
local sColor = ActorManager2.getWoundColor("ct", getDatabaseNode());

wounds.setColor(sColor);
nonlethal.setColor(sColor); <-- Line 20
status.setColor(sColor);
end


Did something change between 3.3.5 and 3.3.6 regarding the logic used to locate the script file for a windowclass like this? Can you think of any other reason why it wouldn't be using my copy of the script file?

Thanks in advance for any help. If I can provide additional info, let me know.

[damned]

a lot of changes happens in the ct files.
you will need to look for the different templates and scripts now in use.

[darrenan]

my question is very specific. It has to do with the specific windowclass and its associated script file as explained in post #1. All the template changes were easy to track down and resolve. I don't think that is the issue in this case.

[Bidmaron]

darrennan, it sounds to me like you have an unpacked ruleset problem? Otherwise, I don't see how it can be happening assuming your lua file doesn't in fact reference the deleted control.

[darrenan]

nope, no unpacked ruleset in my rulesets directory.

24165

[damned]

You are deleting the number_clientct_nonlethal so the 3.5e script cannot find it.

EDIT: Ok - I understand what you are saying now.

[darrenan]

Attaching the current version of the extension if that helps.

24166

EDIT: In case I wasn't clear, the script error only happens on the client side, not on the host side.

[damned]

I dont know if this **might** help....
https://www.fantasygrounds.com/forums/showthread.php?44741-Issue-with-Merge-Delete&p=397382&viewfull=1#post397382
I had a merge=delete issue a little while ago that was resolved by completely closing and relaunching FG... just maybe...

[Bidmaron]

Oh. Well, apparently, there are some changes in window_classes for the combat tracker on the client side. There may be some code elsewhere that is only executed for client that needs that node to be there. See if there is another file with that name in the code base that is nested under a client side ct window?

[darrenan]

I dont know if this **might** help....
https://www.fantasygrounds.com/forums/showthread.php?44741-Issue-with-Merge-Delete&p=397382&viewfull=1#post397382
I had a merge=delete issue a little while ago that was resolved by completely closing and relaunching FG... just maybe...

I don't have any actual code in my extension.xml, other than script file declarations. My extension is modeled on the 3.5 ruleset and follows the same organizational patterns and practices.

[Moon Wizard]

Ok, here's what is happening.

StrainInjury script onInit -> 3.5E script onInit -> CoreRPG script onInit

Both StrainInjury and 3.5E scripts are calling onHealthChanged. However, when a function is defined that calls other functions, the functions are bound at load time. So, both the StrainInjury and 3.5E extensions are each calling their own onHealthChanged function.

Try these changes to the StrainInjury extension:


function onInit()
super.super.onInit();
onHealthChanged();
end

function onFactionChanged()
super.super.onFactionChanged();
updateHealthDisplay();
end


Regards,
JPG

[darrenan]

I'll give that a whirl when I get home, thanks.

[darrenan]

That fixed the scripting errors, thanks again. I think the wound-coloring inconsistency I'm seeing between the host and client sides of the CT is a bug that exists in the 3.5 ruleset which is easy to reproduce:

1. Open up a host, connect a localhost client, using a 3.5 campaign with no extensions loaded.
2. Open up the CT on the host, add any NPC. Open up the CT on the client.
3. Set the nonlethal/subdual damage field of the NPC you added to the same value as its total HP. On the host side it is colored red, on the client it is grey. Clear the nonlethal/subdual damage field.
4. Set the nonlethal/subdual damage field of the NPC you added to its total HP + 1. On the host side it is colored purple, on the client grey.

I tracked this down to the fact that on the client side the coloration is entirely based on the contents of the status control (ActorManager2.getPercentWounded) rather than duplicating the calculations performed by the host (which I think it could easily do and would return the same results as the host):



local sStatus;
if sNodeType == "ct" and not User.isHost() then
sStatus = DB.getValue(node, "status", "");
else
... host calculates sStatus in the else block ...


sStatus is returned back to ActorManager2.getWoundColor and is used to determine the correct color. The host doesn't set the new status in the node until after ActorManager2.getWoundColor returns.

It seems like the new status isn't set by the host (in ct_entry.lua, onHealthChanged) before the client side calls ActorManager2.getWoundColors in response to its onValueChanged event, so it uses the previous status to set the current color.

[Bidmaron]

Great detective work, darrenan!