Progressbar, not really working out.

**celestian** · July 5th, 2019, 06:43

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.

Code:

  <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** · July 5th, 2019, 13:00

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** · July 12th, 2019, 08:51

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.

These were my replacements.

Code:

  <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

Code:

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.

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** · July 12th, 2019, 22:08

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

**Moon Wizard** · July 13th, 2019, 01:06

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

Thanks,
JPG

**celestian** · July 13th, 2019, 04:51

Originally Posted by Moon Wizard

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!

**celestian** · July 15th, 2019, 06:26

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)".

Code:

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** · July 15th, 2019, 18:02

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** · July 15th, 2019, 19:15

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** · July 15th, 2019, 19:56

Originally Posted by 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

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

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

Thread: Progressbar, not really working out.

Thread Tools