17 Jul, 2010, David Haley wrote in the 21st comment:
Votes: 0
I would recommend against adding another effect flag field; it's not that much less work than a proper arbitrary-sized bit-vector and makes things confusing.
17 Jul, 2010, Scandum wrote in the 22nd comment:
Votes: 0
Hades_Kane said:
I did some searching on google and some searching through the site but wasn't able to come up with any information on converting a ROM to using an unlimited bits system, other than links to places no longer working.

Have you already converted from 32 to 64 bit bitvectors?
18 Jul, 2010, Davion wrote in the 23rd comment:
Votes: 0
David Haley said:
I would recommend against adding another effect flag field; it's not that much less work than a proper arbitrary-sized bit-vector and makes things confusing.



Actually, it's a lot more work. This may only be a ROM thing, may not, but switching to use anything other than a basic int for affects is annoying as -hell-.

ROM Object values (eg. obj->value[0]) are stored as integers. These values are sometime used to represent the flags an item will hold (as example, weapon flags- vorpal, flaming, holy, etc). So if you're going to use an arbitrary sized bit vector, you're probably biting off more than you can chew. AFF2, or using 64bit bitvectors is the way to go in ROM.
18 Jul, 2010, David Haley wrote in the 24th comment:
Votes: 0
Umm, if you are using value[0] to store bits 0-31, how are you going to use it to store bit #32 for the second flag int? (Or bit #64 if you want to go 64-bit)
18 Jul, 2010, Davion wrote in the 25th comment:
Votes: 0
David Haley said:
Umm, if you are using value[0] to store bits 0-31, how are you going to use it to store bit #32 for the second flag int? (Or bit #64 if you want to go 64-bit)


If you're using a secondary set of bits, you can use another obj-value spot in the array. If you're switching to 64bit, you can just change the integers involved.
18 Jul, 2010, David Haley wrote in the 26th comment:
Votes: 0
That's assuming you still have another obj-value spot in the array. And changing to 64-bit is likewise only deferring the problem. The point being that you will eventually run into the same problem of the obj-value system being a rather poor way of storing this kind of information.

Besides, you could just as easily store bits in obj-values and stick them into an arbitrary-sized bitvector. In fact, the bitvector will be able to contain all of the bits you want to put in obj-values, and more. So really, obj-values are completely irrelevant as an argument here because they can be made compatible with bitvectors. :smile:
18 Jul, 2010, 3squire wrote in the 27th comment:
Votes: 0
This cannot be this hard, right? Here's the code in PHP when I made it for Kusht… translate into your language of choice…

[php]/* — EXTENDED VERSIONS OF THE BIT FUNCTIONS — */
/* NOTE: These overload normal bit operations to arrays
*/

function bit_index($num) {
return floor($num / 31);
}

function to_bit($num) {
return 1 << $num-(bit_index($num))*31;
}

function SET_BIT(&$var, $num = 0) {
$i = bit_index($num);
if(!isset($var[$i])) { $var[$i]=0; }
$var[$i] = ($var[$i] | to_bit($num));
}

function RMV_BIT(&$var, $num = 0) {
$i = bit_index($num);
if(!isset($var[$i])) { $var[$i]=0; }
$var[$i] = ($var[$i] & ~to_bit($num));
}

function IS_SET($flag, $num = 0) {
$i = bit_index($num);
if(!isset($flag[$i])) { return false; }
return ($flag[$i] & to_bit($num))>0;
}[/php]
18 Jul, 2010, Davion wrote in the 28th comment:
Votes: 0
David Haley said:
So really, obj-values are completely irrelevant as an argument here because they can be made compatible with bitvectors. :smile:


My argument was that it's more work then simply adding a second set or extending to 64bits. Because adding these require little to no change with obj values.

Also, adding a second set requires no change to anything but the bitvector that's run out of room. Just sayin, switching to an unlimited bitvector system is more work then you think, in ROM. Definitely more then then your other two options, but probably the more proper fix if you intend to use 64+ bits.
18 Jul, 2010, David Haley wrote in the 29th comment:
Votes: 0
My point is that you can use the obj-value system with arbitrary-sized BVs with absolutely no change. You will still be able to express only those bits in the obj-value integer, but you aren't losing anything or adding work.

Old world:
- flag set: 32-bit int
- obj-value: 32-bit int

New world:
- flag set: flag set with over 9000 flags!
- obj-value: 32-bit int

You can still use the 32 bits to control the first 32 flags in the flag set. Yes, that's not all 9000+ flags. But you haven't lost anything! And you haven't had to do any work, either… You have gained 8968+ flags.

Perhaps you could show concretely what problem comes up here…
18 Jul, 2010, David Haley wrote in the 30th comment:
Votes: 0
Missed this the first time around…
3squire said:
This cannot be this hard, right?

The topic being discussed is not the difficulty of implementing an arbitrary-sized bit vector – in fact, that was 'solved' very quickly and you can see that several solutions were presented if you go read the earlier posts. What Davion is calling hard is the problem of integrating it into the codebase.
19 Jul, 2010, 3squire wrote in the 31st comment:
Votes: 0
But I'm saying that if you are already using the traditional ROM interfaces, those function names I presented all offer a transparent alteration to the existing methods that makes it seem as if there are an arbitrary number of bits without changing anything (save-files notwithstanding)
19 Jul, 2010, quixadhal wrote in the 32nd comment:
Votes: 0
How you go about having "infinite" bits doesn't really matter.

The question is, how stuck on the ability to do "if( bit_thing & (BIT_FOO1 | BIT_FOO2) )" style comparisons, instead of if( is_set(bit_thing, BIT_FOO1) || is_set(bit_thing, BIT_FOO2) )"?

If the latter (or something similar) is acceptable, then you can use anything from the bit-vector approaches suggested above, to actually using seperate boolean variables, to making an SQL query to check.
19 Jul, 2010, David Haley wrote in the 33rd comment:
Votes: 0
3squire said:
But I'm saying that if you are already using the traditional ROM interfaces, those function names I presented all offer a transparent alteration to the existing methods that makes it seem as if there are an arbitrary number of bits without changing anything (save-files notwithstanding)

Not really, because the bitvectors are not always modified via an interface but sometimes with direct bit operations, such as what Quix posted.
27 Jul, 2010, Rarva.Riendf wrote in the 34th comment:
Votes: 0
quixadhal said:
"if( bit_thing & (BIT_FOO1 | BIT_FOO2) )" style comparisons, instead of if( is_set(bit_thing, BIT_FOO1) || is_set(bit_thing, BIT_FOO2) )"?


If is_set works like it should is_set(bit_thing, BIT_FOO1 | BIT_FOO2) should work.

And for object giving affect, you can give it through spell method, and then do not need to change object structure at all.
27 Jul, 2010, quixadhal wrote in the 35th comment:
Votes: 0
That only works up to however many bits your native integer type can handle.

Suppose BIT_FOO1 is defined to be 16, and BIT_FOO2 is defined to be 91887.

What is BIT_FOO1 | BIT_FOO2 ? It's not bit 16 and bit 91887 as you'd hope. Unless you override the | operator to somehow magically know that your bit defines are meant to be different than other bitwise or operations on normal integers.

You could overload is_set() so it accepts an array, and overload the | operator to convert the two values into a 2 element array to pass in… maybe… but it's still pretty ugly.

The thing is, the Diku folk used bitwise operators for things that really should have been logical operators. They did it that way because memory used to be really expensive. It's not now.
27 Jul, 2010, Kjwah wrote in the 36th comment:
Votes: 0
quixadhal said:
They did it that way because memory used to be really expensive. It's not now.

I don't know, I've looked at some MUD hosting packages and it still seems rather expensive for what hardware is now. :p
27 Jul, 2010, Rarva.Riendf wrote in the 37th comment:
Votes: 0
quixadhal said:
That only works up to however many bits your native integer type can handle.

Suppose BIT_FOO1 is defined to be 16, and BIT_FOO2 is defined to be 91887.

What is BIT_FOO1 | BIT_FOO2 ? It's not bit 16 and bit 91887 as you'd hope

Hope keeps me alive ! (I had a stupid moment, it will not work..I agree..)
28 Jul, 2010, quixadhal wrote in the 38th comment:
Votes: 0
Kjwah said:
quixadhal said:
They did it that way because memory used to be really expensive. It's not now.

I don't know, I've looked at some MUD hosting packages and it still seems rather expensive for what hardware is now. :p

That's because MUD hosting services try to pack many people onto few machines, courtesy of VM technology. Today's motherboards aren't designed to handle more than about 16G of RAM unless you buy very expensive ones. The RAM itself is not that expensive. I think I paid $70 for 4G of RAM when I built my machine last fall, and I paid another $80 to buy an identical 4G to fill out the slots this spring.

My old server machine that sits in the corner has 768M of RAM, and I paid 20 bucks for 512M of RDRAM on ebay (old hardware needs expensive legacy memory), but the machine itself was free as in a friend was going to throw it out. My firewall machine has 512M and it cost me 40 bucks at auction 3 years ago.

If you actually have your own machine, RAM is cheap. If you're sharing a box with 20 other people, yeah… you're probably getting a pretty small slice because the hosting site wanted to spend 100 bucks on a motherboard instead of $1000.

Rarva.Riendf said:
quixadhal said:
That only works up to however many bits your native integer type can handle.

Hope keeps me alive ! (I had a stupid moment, it will not work..I agree..)

Were I planning to revisit RaM (or any other diku project), doing away with all that bit logic stuff would be on my short list of things to do first. It's not hard, just very tedious.
Random Picks
20.0/38