Progressbar, not really working out.

[celestian]

https://i.imgur.com/61dIVp2.png

It seems any time I add a entry they look like that. When I force an update onListChanged() it clears up but ONLY for the entries that already existed and not the new one I just dropped that caused the update. I've tried several things to try and get it to update onInit() but that doesn't seem to work either (including adding an onInit to the hpbar_ctaentry template.

I'm not entirely sure why it's doing this to begin with. The Max/used are correct no matter where I check. There does seem to be some odd behavior for the x,y= getPosition() as it seems to return 70 on both... until I FORCE an update and then it becomes a sane value?

Runtime Notice: s'progressbar.lua' | s'update' | s'x' | #70
Runtime Notice: s'progressbar.lua' | s'update' | s'y' | #70

And then when I force an update that output for the same control now shows this:

Runtime Notice: s'progressbar.lua' | s'update' | s'x' | #70
Runtime Notice: s'progressbar.lua' | s'update' | s'y' | #15

This is what it looks like after the forced update.
https://i.imgur.com/M2V6d85.png



<template name="hpbar_ctaentry">
<progressbar>
<anchored height="40" width="10" >
<top parent="token" />
<left parent="token" anchor="right" relation="relative" offset="10" />
</anchored>
<source><max>hptotal</max><used>wounds</used></source>
<textprefix><textres>hp</textres></textprefix>
<script>
function onValueChanged()
setFillColor(ColorManager.getHealthColor(1 - getPercent(), true));
end
</script>
</progressbar>
</template>


That's the template I'm using to add the control. How does one get this thing to initialize properly when the control is added?

[Bidmaron]

Have you tried fastinit? Sometimes that clears up INIT problems (and the other half of the time it doesn’t). I suspect this is the problem that onInit occurs before subcontrols are done unless you use fastinit?

[celestian]

I put off debugging this while I worked on some other things that were more pressing but I came back to this and found a solution. I dunno if it's a "bug" or just the way I'm trying to use the progress bar (within a windowlist) but here is how I fixed it.

First, here is the problem. When drag/dropping a n/pc into the CT it would look like this.

https://i.imgur.com/1vIqHnb.png

These were my replacements.



<template name="progressbar">
<genericcontrol>
<frame name="border" />
<fillcolor>006600</fillcolor>
<script file="common/scripts/progressbar.lua" />
</genericcontrol>
</template>

<template name="progressbarfill">
<genericcontrol>
<anchored>
<top />
<bottom />
<left />
<right />
</anchored>
</genericcontrol>
</template>


You'll note I removed the bounds 0,0,0,0 and replaced with anchored in the XML. This was so when I used the .setAnchor() it wouldn't complain about unset positions.

The the only change to the progressbar.lua I made was this. See bolded section



function update()
if not ctrlBar then return; end

local w,h = getSize();
if (h < 2) or (w < 2) then
ctrlBar.setStaticBounds(0, 0, 0, 0);
else
local bHorizontal = (h < w);
local bOffset;
if reverse and reverse[1] then
bOffset = bHorizontal;
else
bOffset = not bHorizontal;
end

local nPercent = getPercent();

local x,y = getPosition();
local nFrom, nLen;
if bHorizontal then
nLen = math.floor(((w - 2) * nPercent) + 0.5);
if bOffset then
nFrom = x + (w - nLen) - 1;
else
nFrom = x + 1;
end
ctrlBar.setStaticBounds(nFrom, y + 1, nLen, h - 2);
else
nLen = math.floor(((h - 2) * nPercent) + 0.5);
if bOffset then
nFrom = y + (h - nLen) - 1;
else
nFrom = y + 1;
end
ctrlBar.setStaticBounds(x + 1, nFrom, w - 2, nLen);
end

ctrlBar.setBackColor(sBarFillColor);
-- this fixes the odd behavior when first placing
ctrlBar.setAnchor("top",self.getName(),"top");
ctrlBar.setAnchor("bottom",self.getName(),"bottom");
ctrlBar.setAnchor("left",self.getName(),"left");
ctrlBar.setAnchor("right",self.getName(),"right");
--

if bAutomaticText then
local sText = "" .. getValue() .. " / " .. getMax();
if (sTextPrefix or "") ~= "" then
sText = sTextPrefix .. ": " .. sText;
end
setText(sText);
end
end
end



With that I could drag/drop and they looked like this.

https://i.imgur.com/xYVbdYi.png


I tried various options outside of messing with the code like forcing an hpbar.update() at various points and none of them would work on the entry that was just dropped. I could get it to work AFTER the fact but never on the drop. Using the onListChanged() would only work for the previous entries.

Either way, nothing worked other than the mentioned above. If anyone knows why it didn't work out of the box I'd love to know, otherwise I'll let this one ride out for a bit and maybe show it to Moon for 3.8.8...

[Bidmaron]

You are a stud. I don’t know why the dang reputation add is disabled on mobile. Pisses me off.

[Moon Wizard]

Can you try again with the CoreRPG version of progressbar that I just pushed to v3.3.8 Test channel?

Thanks,
JPG

[celestian]

Can you try again with the CoreRPG version of progressbar that I just pushed to v3.3.8 Test channel?

Thanks,
JPG

That does seem to correct the problem I was having using 3.3.8!

:o

[celestian]

I did notice one other thing while tinkering with things. Using the newer progressbar.lua from 3.3.8.

If I adjusted the total HP it would not update the bar properly until I adjusted wounds. So I did a look around and I was able to correct this behavior doing this in "setMax(nValue)".



function setMax(nValue)
local nNewMax = math.max(nValue, 0);
if nMax == nNewMax then return; end
nMax = nNewMax;
nCurrent = math.max(math.min(nCurrent, nMax), 0);
if self.onValueChanged then
self.onValueChanged();
end
onUsedChanged();
update();
end


Adding the onUsedChanged() adjusted the bar to take into account the "total hp" change.

[Moon Wizard]

I don't think that change should go in the progressbar.lua code, because it would break any progress bars that didn't use a "used" source. I'll have to think on it a bit.

JPG

[Moon Wizard]

It ended up that this was an issue that no one had reported before (i.e. bars in party sheet didn't update correctly when maximum HP or HD updated.)

I just pushed an update to v3.3.8 that fixed this, without breaking anyone using the bars for current/max usage, instead of used/max.

Can you check that this fixes the issue for you?

Regards,
JPG

[celestian]

It ended up that this was an issue that no one had reported before (i.e. bars in party sheet didn't update correctly when maximum HP or HD updated.)

I just pushed an update to v3.3.8 that fixed this, without breaking anyone using the bars for current/max usage, instead of used/max.

Can you check that this fixes the issue for you?

Regards,
JPG

I totally didn't think about non-used/wounds option.

Just checked after I saw your 3.3.8 post. Works perfectly.