&GETVALUE/ &SETVALUE (CSBwin)

[beowuuf]

Is there a way to get and set the value for misc items? If not, could this be easily added?

[Paul Stevens]

I see no reason not to do this. Should be relatively easy.
Next release will have:

Code: Select all

&INCRMISCVALUE ( increment  id . . .  oldValue )

That will suffice for both functions you need.
Set increment to zero to fetch; negative or positive to change.
It is only a 2-bit field.
You gotta be careful.....Don't change the value of
dead champion's bones.
OK?

[beowuuf]

Sounds good, thanks! : )

So if you implement the &INC to change a value, you'll need an &drop afterwards?

[beowuuf]

Also, would this function have a wrap around protection (3 <-> 0, ), or will this need to be checked by the designer before using it?

[Paul Stevens]

Looking through the list of available functions I see
a &GETCHARGES and &SETCHARGES. Right now it
only works for weapons. But it commonly means the
same sort of thing for MISC objects. Let us expand that
word to include MISC objects rather than build an entirely
new word.

In the case of MISC objects only the bottom two bits of
the value you supply will be used.

[beowuuf]

Funnily enough, that's what I tried to use before, incase you were fetching the whole of that byte : )

You say the bottom two bits, but doesn't it go the other way with 'misc bits, weapon charge bits, bits for broken/cursed/poison flags' ? Or have I got my endian wrong? : )

[Paul Stevens]

Nothing to do with 'endian'. The MISC value field
is a 2-bit field. It can hold the values 0, 1, 2, or 3.
If you try to put a big number into it ( for example,
binary 1111111100 ) then
what will be put into it is the bottom two bits of that value
( binary 00 ). I am not going to check the number you
provide. I simply put the bottom two bits into the
value field.

Endian has to do with the order that the bytes are stored
in a multi-byte value. It has nothing to do with the order of
the bits in a value. Bits in a value are always displayed
with the most significant to the left. As in the decimal number
one-thousand-two-hunderd-thirty-four ( 1234 ). The
value may be stored in strange ways but when we speak of the
decimal value of this integer we will always say that the
'bottom' digit is a 4.

In the case at hand, you are going to provide a 32-bit integer.
The bottom 2 bits will get placed in the object's value field.
We need have no idea how the 2-bit value is represented in the
computer's memory so long as when we FETCH it back we get the
same number we provided when we SET it.

[beowuuf]

Ah, I mis-interpreted, I thought you were expanding the &getcharge so you would use it to pull the value of charges (0 - 15) or misc value (16, 32, 48). That confused me, as in this case the least significant bits were charges, not misc values. Now i see, you mean it will be 'getvalue' or some such, and work exactly like &getcharges

[Paul Stevens]

work exactly like &getcharges

Not only 'exactly like'. It is the same.

&GETCHARGES and &SETCHARGES can be
applied to WEAPONS or MISC objects.

For MISC objects it references the Value field. This
is like charges in many cases (like how many sips of
water in a Waterskin).

MISC values are not 16, 32, 48! They are 0, 1, 2, and 3.

CSBwin9.8v73 implements this application to MISC values.
It also corrects the DSA filter error so that now the ! FIRST !
DSA at a location will be activated as filters. Let me know
if you find otherwise.

Zyx : Your private, debug copy of CSBwin also incorporates
these changes. Any comments on the method I proposed to
implement virtual masks? I am not going to proceed until
we agree on the method.

[beowuuf]

Filter seems to work fine - I just need to wade through my view filter code to see my own mistakes, but the getcharge seems to be goign fine too : )

[Zyx]

Ouch! Only the first DSA? what about the others!

As for the masks, I'm still pondering about your method. One thing is probable: I'll need the transformation mask to also alter the sourceX, sourceY destinationX, destination Y of the mask.
But I fear things will get complicated because of the sourceX multiple-of-16, one-hand-in-the-back restriction.

[Paul Stevens]

Ouch! Only the first DSA?

There never was more than one activated. It used to
be the last one in a couple of cases. Now it is the
first one. Why the cry of pain?

complicated because of the sourceX multiple-of-16

I thought we took care of that with the arbitrary (even negative)
values for destX. Now what? Got an example of where this
is still a problem?

[Zyx]

No, for months all the DSA were activated, which was perfect!
Fusing all the DSA into a single one is going to be a pain in the neck.

As for the sourceX, it seems you're right.

Instead of using a transformation mask, could this be done by code?
After all, storing the parameters of the transformation in a pseudo mask or in a skincode is the same, except it is simpler, more readable and easier to update in the code.
Besides, functions could be applied on the parameters (like the destX depending on the width of the picture).

[Paul Stevens]

for months all the DSA were activated

We are both right. The Spell Filter, Feeding Filter,
Monster Attack Filter, and Viewing Filter worked as you
say. I have restored that for you.

The Party Attack Filter always called the first DSA only.
The Monster Move Filter used to call the last DSA but
now calls the First DSA.

I think. I am basing the past action mostly on recollection
and a couple of check-marks on a 3x5 card.

Instead of using a transformation mask, could this be done by code

Yes. Tell me how you want it to work. Do you want to supply
any of the parameters in an 'empty' mask? Or do you want the
code to build a new mask completely from 'scratch'? Since this
is a once-only kind of thing, I am open to most any suggestion.

For my benefit could we add a word 'NeedVirtualMask?' that you
would used in an IF THEN to skip the construction if the mask already
exists?

Code: Select all

<maskID> <masknum> NeedVirtualMask? IF <build the mask> THEN

I would enforce this with a one-time error message if you construct
a mask that already exists.

[beowuuf]

Would it be possible to expand the &get/setcharges to clothes (since shields come under this catergory) ?

[Paul Stevens]

Yes. By tomorrow.

[beowuuf]

Cheers!

[Paul Stevens]

CSB98v77 should allow &GET/SETCHARGES to work
with Clothing.

[beowuuf]

It does indeed (the getcharges at least, no reason to doubt settign either) : )

[beowuuf]

Incase you couldn't spot this coming, would it be possible to have a &setpower for potions? And if the receiprocal &getpower is easy, that would be good (though of course can just &type L256 &% if needs must!)

[Paul Stevens]

CSB98v78 should allow &GET/SETCHARGES to work
with Potions.

[beowuuf]

Ooh, again won't have to change any code - cool!

Edit: While I can only assume the DSA is working right, the get/set definitely is