You can, but it's not so easily as just that. People have been storing multiple values per counter since long ago in the 2.x days, as a way to get around the limit of 50 counters (yes, seriously). It was a gigantic hassle to do then, though, and now that it's become relatively simple to do, there's no longer much point to it unless you really want to be hackish. But I'll give you a few approaches to this.
The "leet" approach to this is to actually mark out bit ranges in the counter (you have 32 bits to work with) that will hold your data, and to do all your accessing and modification using bitwise math via expressions. So for example, in the case where you treat the counter as 32 boolean flags, this is pretty simple to grasp:
. "Access &bit& in &word&"
set "result" to "('word'>>'bit'a1)"
. "This shifts the target bit to the 1's place, then AND masks the rest of the word with 0 so that only that bit is returned."
. "Think of this as ('word'/(2^'bit')) % 2, since that's the same operation in arithmetic terms."
. "Set &bit& in &word& to 1."
set "word" to "(1<<'bit'o'word')"
. "This creates an OR mask with a bit set in the location we want to set a bit, then ORs that with the counter.
. "Clear &bit& in &word& to 0"
set "word" to "(~(1<<'bit')a'word')"
. "This creates an AND mask with all 1s execpt in the location we want to clear, then ANDs that with the counter.
. "Toggle &bit& in &word&"
set "word" to "(1<<'bit'x'word')"
. "Almost identical to the SET operation, except that an XOR mask flips all bits that correspond to 1 instead of setting them unconditionally."
Of course, you probably want more than just flags. Variable length fields, particularly setting them, is a little more complicated.
. "Access &bit& for &length& in &word&"
set "result" to "('word'>>'bit'a(1<<'length'-1))"
. "Very much like the first example, but the AND mask has to be made larger. Note that I'm using the lowest bit as a reference for the field."
. "If a field runs from bit 15-18, then &bit& should be 15 and &length& should be 4."
. "Set &bit& for &length& in &word& to &value&"
set "word" to "((1<<'length'-1a'value'<<'bit')o(~(1<<'length'-1<<'bit')a'word'))"
. "This is a little tricky, but there are two parts. One is to create a bit string that represents our value located in the correct place."
. "The other is to create a mask and that part of the target counter to 0. Then we just OR those values together.
. "The fussy stuff with (1<<'length'-1a'value') is to make sure the value fits in the field we've specified, which is generally good practice."
. "Set &bit& for &length& in &word& to 0 (i.e. clear)"
set "word" to "(~(1<<'length'-1<<'bit')a'word')"
. "Or in other words, the second part of what was done above. 1<<'length'-1 creates a string of &length& 1s, which is then shifted to the"
. "location of &bit&. Then the bit string is inverted to create an AND mask for clearing the field."
. "There isn't really a practical application for 'toggling' a field, but this will perform an XOR operation on it with a given value:"
set "word" to "(1<<'length'-1a'value'<<'bit'x'word')"
. "There isn't a need to clear anything, here, given the nature of XOR and that the result depends on the data already there."
Now, that's probably way too much information, and while you can create a series of subroutines to work with it it's really not going to be that convenient. So let me suggest something geared towards clear syntax, instead of uber space-saving skills.
set "counter.type" to 1
set "counter.wep_str" to 2
set "counter.someting" to 3
And so on. The only real drawback here is that you can't set the whole thing in one command. Since most of the time you'll be accessing and modifying individual fields, this seems like a much better tradeoff than being able to set a counter to some arcane magic number, at the expense going through a bunch of complicated math just to access fields inside of it.
Finally, one more idea, if you want to use strings. Strings are a little less cumbersome to manipulate, and there are some tricks you can apply, especially if you keep all of your fields the same length (technically the trick could be applied to bitfields as well, but it'll look cleaner with strings. There are actually two methods, here, so we'll take them one at a time.
set "type" to 0
set "wep_str" to 2
set "someting" to 4
. "Here we initialize some offsets, which will give us string fields 2 bytes, or from 0 to 99.
set "$counter" to "112233"
set "mytype" to "$counter+&type"
set "mywep_str" to "$counter+&wep_str"
set "mysometing" to "$counter+&someting"
. "These retrieve the string counters into values, MZX handles the conversion, if the strings are numeric."
set "$counter+&type" to "99"
. "The one caveat here is for numbers with a length less than the field length, you'll have to do manipulation to enter them correctly."
. "For instance, if the value is 11 and you just set it to 0, then it will end up as 01. You need to manipulate the input into the actual string 00."
The other method is to use each character in the string as a byte-length counter. This makes setting the counter initially in one stroke more difficult, though, and limits the field size to 255.
set "type" to 0
set "wep_str" to 1
set "someting" to 2
. "We still can use offsets"
set "$counter" to "abc"
. "That is, 97,98,99"
set "mytype" to "$counter.&type&"
. "mytype becomes 97"
set "$counter.&wep_str&" to "some_value"
. "The value for $counter's weapon strength becomes whatever the counter some_value is set to."
"This concludes the tour."