Not sure why adding onInit() to rollable control kills the die icon?

[Varsuuk]

Any idea what is messing up the "rollable" icon on this control if in the script attached to it I simply add an onInt() method - even if it is empty?

The control, number_savingthrow_monster, works fine in both cases, rolling. However if the onInit() is added, away goes the 20sided dice icon. It's weird - I don't get the angle here.

	<template name="number_savingthrow_monster">
		<number>
			<frame name="frame_charsheet_savingthrow" offset="7,5,7,5" />
			<anchored width="32" height="20" >
				<top parent="**MISSING ANCHOR**" anchor="bottom" offset="5" />
			</anchored> 
			<nokeyedit />
			<rollable />
			<script file="campaign/scripts/monster_saves.lua" />
	</number>
	</template>

...


			<number_savingthrow_monster name="savingthrow">
				<anchored width="32" height="20" >
					<top parent="columnanchor" anchor="bottom" relation="relative" offset="7" />
					<left offset="97" />

				</anchored>
			</number_savingthrow_monster>

[Trenloe]

This happens because "number" is not a base control (it's not in the API documentation), it's a template based on the numberfield control. Search for that template in CoreRPG and look at the attached LUA script - the onInit of that script sets the rollable icon. As you're defining a new onInit function in your template based on the "number" template, you're overriding the onInit function in the "number" template.

Use the following code in your layered template onInit function to call the higher level code:

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

Search for super.onInit in various rulesets to see examples of it being used.

[Varsuuk]

Great, I was on a roll (no pun intended) adding various fields in the NPC UI. I did a quick search on WEB basically of "lua calling parent method" and got bunch Lua style "oop" stuff which I read once long ago when reading the Lua Ref book and I knew our version didn't do this. So since I was paying like 1/8 of my attn on the search, I thought hmmm guess that is't it - we don't have a way to call parents because... didn't think it through, of course we can

In this case, I didn't need to do much in there - was just for some debugging and testing so removed it to go on - will return it later and thanks on the super() memory