Trying To Extend A Definition

[UrsaTeddy]

Hi,

So I have added a new Derived Stat - easy - no problems.

However I want to add in another script (add really) to its definition ... I have tried the merge and mergerule tags but no success.

1. Is it possible to do what I want to do?

2. If so then how do I go about it?

3. If not then how would I add extra script to this one derived statistic? I want things to occur on the change of this value.

I am providing the code below that I have setup for now in hopes someone can help me out.

The definition of the derived statistic ...



<template name="derivedstat_capacity">
<derbase>
<setup>
<attribute>
<half>strength</half>
</attribute>
<modifier>2</modifier>
</setup>
</derbase>
</template>


These are a few of the attempts to add a new script (not replace but add) to the statistic ...



<derivedstat_capacity>
<script file="charsheet/scripts/template_capacity.lua" />
</derivedstat_capacity>

<derivedstat_capacity merge="add">
<derbase>
<basicnumbercontrol>
<script file="charsheet/scripts/template_capacity.lua" />
</basicnumbercontrol>
</derbase>
</derivedstat_capacity>

<derivedstat_capacity>
<derbase mergerule="add">
<basicnumbercontrol>
<script file="charsheet/scripts/template_capacity.lua" />
</basicnumbercontrol>
</derbase>
</derivedstat_capacity>

<derivedstat_capacity>
<derbase>
<basicnumbercontrol mergerule="add">
<script file="charsheet/scripts/template_capacity.lua" />
</basicnumbercontrol>
</derbase>
</derivedstat_capacity>





Thanks in advance,
D

[IceBear]

This for the Tyrnador inventory? There's an official product coming soonish

[UrsaTeddy]

This for the Tyrnador inventory? There's an official product coming soonish

Thanks for the reply, however it is not for Tyrnador.

This is for my own game and some of the things I do within it.

I did not realise that Tyrnador had something named Capacity ... that's funny.

D

[damned]

If you have added a new derived stat then you should be able to just add the script directly.

[UrsaTeddy]

If you have added a new derived stat then you should be able to just add the script directly.

Adding a seperate script file is not a problem ... however I want behaviour to exist every time the derived stat is modified ... thus the logical place to put it would be to attach to the derived stat.

Very much similar to how conviction has attached behaviours.

The problem with a seperate script file is that I cannot easily access the derived stat and if I want to check if an option is ON/OFF to display/hide the derived stat then it is a little more complicated.

Thanks,
D

[Trenloe]

I'm not 100% sure exactly what you're trying to do. Are you trying to modify the template derivedstat_capacity ? Or are you trying to modify a control based off the template?

If you're modifying the template, something like this might work:


<template name="derivedstat_capacity">
<derbase>
<script file="charsheet/scripts/template_capacity.lua" />
</derbase>
</template>

[UrsaTeddy]

Did you try this?


<template name="derivedstat_capacity">
<derbase>
<script file="charsheet/scripts/template_capacity.lua" />
</derbase>
</template>

I am sure I did, however to make sure I tried your block of code. Inside the template_capacity.lua file I have



function onInit()

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

Debug.console("Hey This Works!")

end


The messages does not get written to the console.

Unless there is something wrong with the script and I have all along been thinking it is the XML merging.

Thanks,
D

[Trenloe]

I edited my post - can you review again please as I'm not sure *exactly* what you're trying to do. And how are you using the template?

[UrsaTeddy]

I edited my post - can you review again please as I'm not sure *exactly* what you're trying to do. And how are you using the template?

Just as you were making that edit, I was trying the same code - great minds and all that - however ...

it works the way I would want - the onInit code is executed - but the derived statistic is not calculated - it is a zero - so a Hindrance that I have set up to test it (gives a -2) - results in the value being -2.

So the question would be - does the <script> tag in this piece of XML overwrite the <script> tag in the original <derbase> ?



As to what I am trying to do - a couple of things.

The first thing I want to achieve is to respond to a change in the derived statistic - if it ever gets to 0 for example then something serious occurs (a table roll is required).


Thanks,
D

[Trenloe]

The script tag in the later defined template XML overrides the script data from the earlier defined template (earlier in the ruleset/extension initialization order). But... the original code is available via the super object.

If you want some of the original functions to run, you’ll need to call them from the new script. For example, if you have an onValueChanged event function in the original script you want to run, you’ll need to call it from the new script onValueChanged event:

function onValueChanged()
if super and super.onValueChanged then
super.onValueChanged();
end
end

[UrsaTeddy]

The script tag in the later defined template XML overrides the script data from the earlier defined template (earlier in the ruleset/extension initialization order). But... the original code is available via the super object.

If you want some of the original functions to run, you’ll need to call them from the new script. For example, if you have an onValueChanged event function in the original script you want to run, you’ll need to call it from the new script onValueChanged event:

function onValueChanged()
if super and super.onValueChanged then
super.onValueChanged();
end
end

If you notice the onInit that I posted earlier, I am doing that (at least for this test) - thus the initialisation of the derived statistic should occur using the old code as well yes?

Thanks,
D

[Trenloe]

If you notice the onInit that I posted earlier, I am doing that (at least for this test) - thus the initialisation of the derived statistic should occur using the old code as well yes?

Thanks,
D
Yes I noticed you were using that in the onInit function. But, all that does is run the onInit function. What else is in the original script? None of that will be run unless you explicitly call it via the super. object.

Sorry, I’m working blind here as I have no idea what’s in the original script.

[UrsaTeddy]

Yes I noticed you were using that in the onInit function. But, all that does is run the onInit function. What else is in the original script? None of that will be run unless you explicitly call it via the super. object.

Sorry, I’m working blind here as I have no idea what’s in the original script.

The original script is from the SavageWorlds ruleset so I would assume I cannot post it here.

The onInit() there sets up the derived stat and calls its own update function from within the onInit().

So I would assume that code would run from my onInit() using the super call.

Right now I am just trying to get the derived statistic to work (as in calculate correctly) and print a message showing that it executed the onInit().

I will worry about the onChange stuff later.

Thanks,
D

[Trenloe]

OK, so let’s take a step back... let’s see if super is available. Remove the if super... in your onInit code and just call super.onInit() straight off. If it fails with a nil exception then it can’t access the super object at that point. And we'll have to identify where the original script info is in the hierarchy.

[UrsaTeddy]

OK, so let’s take a step back... let’s see if super is available. Remove the if super... in your onInit code and just call super.onInit() straight off. If it fails with a nil exception then it can’t access the super object at that point. And we'll have to identify where the original script info is in the hierarchy.

The check for super and super.onInit is successful - I put a debugging message inside that IF statement, so I have a feeling that perhaps the script is being placed in the wrong location.

It would be awesome if there was a way to look at generated XML at any stage during execution.

Thanks,
D

[Trenloe]

What XML do you currently have?

Is <template name="derivedstat_capacity"> your own code or is it somewhere else and you're layering on top of that?

[UrsaTeddy]

What XML do you currently have?

Is <template name="derivedstat_capacity"> your own code or is it somewhere else and you're layering on top of that?

It is my own code ... are you looking at the SavageWorlds ruleset at all?

I will try and explain how this bit works ...



First define the derived statistic ...

<template name="derivedstat_capacity">
<derbase>
<setup>
<attribute>
<half>strength</half>
</attribute>
<modifier>2</modifier>
</setup>
</derbase>
</template>



In another file extend the template ...

<template name="derivedstat_capacity">
<derbase>
<script file="charsheet/scripts/template_capacity.lua" />
</derbase>
</template>



That's about it for the XML.

Thanks,
D

[Trenloe]

I am now in front of a computer and can see the SavageWorlds ruleset.

OK, that's what I was thinking. As you're extending your derivedstat_capacity template which is an extended derbase template. Calling superonInit() in charsheet/scripts/template_capacity.lua will call the onInit function in derivedstat_capacity not in derbase.

Does that make sense?

You don't need to define derivedstat_capacity and then extend it with the same name within your code (unless there's a specific reason to do that, in which case I'd recommend making a new template not extend and existing one).

Try this:


<template name="derivedstat_capacity">
<derbase>
<script file="charsheet/scripts/template_capacity.lua" />
<setup>
<attribute>
<half>strength</half>
</attribute>
<modifier>2</modifier>
</setup>
</derbase>
</template>

[UrsaTeddy]

I am now in front of a computer and can see the SavageWorlds ruleset.

OK, that's what I was thinking. As you're extending your derivedstat_capacity template which is an extended derbase template. Calling superonInit() in charsheet/scripts/template_capacity.lua will call the onInit function in derivedstat_capacity not in derbase.

Does that make sense?

You don't need to define derivedstat_capacity and then extend it with the same name.

Try this:


<template name="derivedstat_capacity">
<derbase>
<script file="charsheet/scripts/template_capacity.lua" />
<setup>
<attribute>
<half>strength</half>
</attribute>
<modifier>2</modifier>
</setup>
</derbase>
</template>

Okay, I can understand that.

I was trying to follow the structure of the Savage Worlds ruleset so that the extension will be "readable" by anyone who has access to the ruleset and has explored it.

Is there anyway for me to do it that way?

Orderly structure is important to me - to a degree.

Thanks,
D

[Trenloe]

I don't think this situation is the same as the Savage Worlds ruleset. The Savage Worlds ruleset adds new scripts into a new template which can then call super. directly in a template above. What yo're doing is creating a template called derivedstat_capacity and then overriding that with a template of exactly the same name. There's no need to do that in the same extension. There would only be a need to do that if you're layering a ruleset/extension in top of a base template. And, as I have mentioned, this means it breaks the inherited script hierarchy.

My recommendation would do what is simpler and more striaghtforward. Don't try to complicate things. Doing it in what appears to be a similar way to the Savage Worlds rulesets may not be the right way (as is the case here). Anywhere you have multiple template layers is going to make it more complex for anyone looking at your code. Keep template layering to a minimum.

[UrsaTeddy]

I don't think this situation is the same as the Savage Worlds ruleset. The Savage Worlds ruleset adds new scripts into a new template which can then call super. directly in a template above. What yo're doing is creating a template called derivedstat_capacity and then overriding that with a template of exactly the same name. There's no need to do that in the same extension. There would only be a need to do that if you're layering a ruleset/extension in top of a base template. And, as I have mentioned, this means it breaks the inherited script hierarchy.

My recommendation would do what is simpler and more striaghtforward. Don't try to complicate things. Doing it in what appears to be a similar way to the Savage Worlds rulesets may not be the right way (as is the case here). Anywhere you have multiple template layers is going to make it more complex for anyone looking at your code. Keep template layering to a minimum.

Okay cool.

Thank you for the guidance.

On another note that relates to this ... inside common/scripts/template_derivedstat.lua there is a function called createDerivedStatField(derivedStat, index) that sets minimum values.

How would I add my derived statistic into that cycle of calling?

Thanks,
D

[Trenloe]

As far as I can see it's not part of the derbase control hierarchy. So you'd have to extract that code and define it (and call it) somewhere appropriate. Probably in your custom charsheet/scripts/template_capacity.lua script file.

[UrsaTeddy]

As far as I can see it's not part of the derbase control hierarchy. So you'd have to extract that code and define it (and call it) somewhere appropriate. Probably in your custom charsheet/scripts/template_capacity.lua script file.

Okay, well you have helped me sort something out enough to play around with it and see if I can achieve what I want to do at this time.

Thank you again,
D

[Ikael]

I did not read the whole discussion but did you try:



<template name="derivedstat_capacity">
<derbase>
<setup>
<attribute>
<half>strength</half>
</attribute>
<modifier>2</modifier>
</setup>
<script file="charsheet/scripts/template_capacity.lua" />
</derbase>
</template>

[Trenloe]

I did not read the whole discussion but did you try:



<template name="derivedstat_capacity">
<derbase>
<setup>
<attribute>
<half>strength</half>
</attribute>
<modifier>2</modifier>
</setup>
<script file="charsheet/scripts/template_capacity.lua" />
</derbase>
</template>

That's where we got to in the end. The OP was trying to follow a similar hierarchy to other areas of the SW ruleset, which wasn't really appropriate in this instance.