Acting on a container's contents

[frumple]

I have a container that needs to perform some actions on anything that is put inside it. I am implementing the container as a piece of gear that has the Helper.Helper tag.

How can I check that a container 1) has stuff in it, and 2) do a foreach through that stuff in order to perform the actions I want to do?

 

[Aaron]

1) Use the gHeldCount field, or if that isn't available, use gearcount

2) From the sbgear procedure

foreach gear in focus
ammo = splice(ammo,eachpick.field[stackQty].value," and ")
ammo &= " " & eachpick.field[sbName].text
nexteach

 

[frumple]

Ah! Thank you!

 

[Azhrei]

Hm. Could this somehow be used to add a field to all items in a container that would flow through to the "Save Custom Output" XML file? That would allow a character sheet to know which items were in which containers, something that HL doesn't currently export.

Thanks.

 

[ShadowChemosh]

Hm. Could this somehow be used to add a field to all items in a container that would flow through to the "Save Custom Output" XML file? That would allow a character sheet to know which items were in which containers, something that HL doesn't currently export.

Thanks.

I don't think anything we do in the HL Scripts have an impact on the XML that is outputted at the end. Meaning to get container logic into the Custom Output XML I am 99% sure requires a change in the HL binary...

 

[Azhrei]

I'm looking into using a JavaScript library that can read ZIP files so that the char sheet could be put in the same folder as the .por file and when the sheet was opened up, it would read the container information directly from the portfolio. I don't know how practical this is yet; it's only in the idea stage. But the containers and their contents are easily found within the portfolio... (And I filed a bug report on this. Maybe if enough people file bug reports they'll make a change. Can't be very tough, right? )

 

[ShadowChemosh]

I'm looking into using a JavaScript library that can read ZIP files so that the char sheet could be put in the same folder as the .por file and when the sheet was opened up, it would read the container information directly from the portfolio. I don't know how practical this is yet; it's only in the idea stage. But the containers and their contents are easily found within the portfolio...

So to take a look you can open up a .por file with any zip tool like 7-zip. If you take a look inside the "data" you can read is less than what the custom output does. Basically the readable part of the por file is just a basic statblock. The custom output actually gives more information. Because while in the file is the XML data to have HL rebuild the information its not in a usable format for anyone else. Take a look you will find lots of references to Picks Chain's and numbers.

Granted its been awhile sense I looked but thats what I saw the last time I looked at one. Just FYI.

(And I filed a bug report on this. Maybe if enough people file bug reports they'll make a change. Can't be very tough, right? )

This is true....

 

[Azhrei]

So to take a look you can open up a .por file with any zip tool like 7-zip.

Been there, done that.

If you take a look inside the "data" you can read is less than what the custom output does. Basically the readable part of the por file is just a basic statblock. The custom output actually gives more information.

Generally, yes. But the containers have an ID associated with them and the contained items have attributes that reference that ID. It would be very simple to relate the two of them together.

Sample snippet is below. Note that the backpack has index="1001" and the caltrops have holder="1001":

<pick thing="fBackpack" index="1001" batchindex="835" refcount="0" fieldcount="5" source="gTable">
<field id="slOriPrice" text="50 {size 32}GP{size 40}"></field>
<field id="usrChosen1"></field>
<field id="usrChosen2"></field>
<field id="usrChosen3"></field>
<field id="usrChosen4"></field>
</pick>
<pick thing="fCaltrops" index="998" batchindex="832" refcount="0" fieldcount="5" source="gTable" holder="1001">
<field id="slOriPrice" text="50 {size 32}GP{size 40}"></field>
<field id="usrChosen1"></field>
<field id="usrChosen2"></field>
<field id="usrChosen3"></field>
<field id="usrChosen4"></field>
</pick>

I can find all pick's with an attribute of holder with //pick[@holder], then iterate through those and pull out the values. Then another //pick[@index=value] for each value gives me the containers themselves. Easy stuff.

My plan is to make the .por file optional. If it's there, the JS will only use it to construct the container hierarchy -- the rest of the file will be ignored.

I have some time off next week so I'll look into this more pretty soon; I'd like this sheet to work as completely as possible. My main concern is performance: will reading the ZIP in an interpreted language be too slow to be usable?

(As an aside, I am pretty impressed with the design work LW did with the XML data. They broke a few rules, but probably for expediency. For example, the text attribute in those two picks contain presentation information (font size) and it really should be two separate fields (perhaps "amount" and "unit"?), then the software should control the presentation by reducing the font size for the unit. But as I said, I'm being pedantic and overall they did a great job with it.)