Pages:<< prev 1 next >>
#1 Apr 23, 2020 7:36 am
Apprentice
GroupMembers
Posts86
JoinedAug 25, 2003
Hi, a simple question: how is it possible build an object with affeted like "acidmist" a_flags that is out of 32 bit mask?
oset objname affect affeted acidmist
... I thin apply_ext_affect could be the solution but looking the code is incomplete.
Bye!
oset objname affect affeted acidmist
... I thin apply_ext_affect could be the solution but looking the code is incomplete.
Bye!
#2 Apr 23, 2020 5:43 pm
Geomancer
GroupAdministrators
Posts1,917
JoinedJul 26, 2005
Hmm well I haven't tested it out in smaugfuss, but it looks like it was done. It should be oset affect affected acidmist
#3 Apr 23, 2020 7:33 pm
Apprentice
GroupMembers
Posts86
JoinedAug 25, 2003
do_oset:
I also don't use smaugfuss 1.9, but it's usa a SET_BIT and not extended bitvectors.
The problem is that affect_data ( ->modifier ) is integer and not EXT_BV.
So in area files you can't create an object with an affect like acidmist becaus it's > 31 (extended bitvector).
My error?
Sorry for my bad english.
Bye!
while( argument[0] != '\0' )
{
argument = one_argument( argument, arg3 );
if( loc == APPLY_AFFECT )
value = get_aflag( arg3 );
else
value = get_risflag( arg3 );
if( value < 0 || value > 31 )
ch_printf( ch, "Unknown flag: %s\r\n", arg3 );
else
SET_BIT( bitv, 1 << value );
}
if( !bitv )
return;
value = bitv;
I also don't use smaugfuss 1.9, but it's usa a SET_BIT and not extended bitvectors.
The problem is that affect_data ( ->modifier ) is integer and not EXT_BV.
So in area files you can't create an object with an affect like acidmist becaus it's > 31 (extended bitvector).
My error?
Sorry for my bad english.
Bye!
#4 Apr 23, 2020 8:39 pm
Last edited Apr 23, 2020 9:08 pm by Remcon
Geomancer
GroupAdministrators
Posts1,917
JoinedJul 26, 2005
This is probably why I think most have redone this setup haha.
#5 Apr 23, 2020 9:36 pm
Last edited Apr 23, 2020 9:38 pm by Remcon
Geomancer
GroupAdministrators
Posts1,917
JoinedJul 26, 2005
Can you show what all you tried and the results you are getting?
#6 Apr 24, 2020 2:35 am
Last edited Apr 24, 2020 3:41 am by Matteo2303
Apprentice
GroupMembers
Posts86
JoinedAug 25, 2003
Oh yes, I simply noticed the problem. Missing other code about APPLY_EXT_AFFECT, for example an output related with ostat or identify.
More than one solution in any case: I think that APPLY_EXT_AFFECT in the smaug intention was create an extended affect. The problem, like I said, is that in affect struct the ->modifier isnt a EXT_BV so in building area files you can't store text like 0&0&0&0 (null bitmask).
If you store a bitvectory you need to chage in load_objects fread_number into fread_bitvector and and change the struct from int ->modifier to EXT_BV ->modifier. Too much code changes for a little improvment...
Another way:
you can create APPLY_EXT_AFFECT_1, APPLY_EXT_AFFECT_2 and APPLY_EXT_AFFECT_3 so you can set the EXT_BV bitmask with singles simple integer in this way:
with APPLY_EXT_AFFECT_1 will use:
SET_BIT( ch->affected_by.bits[1], mod ); (notice: SET_BIT not xSET_BIT)
with APPLY_EXT_AFFECT_2 will use:
SET_BIT( ch->affected_by.bits[2], mod );
etc...
Another way also could be this... more complicated but I'll try explain me with an example:
->modifier == 123133100 ? (we use always 9 numbers)
we split numbers in this way:
1|23|13|31|00|
1 = (no value)
23 = index of a flag in ->affected_by.bits[3] ... SET_BIT( ch->affected_by.bits[3], 1<<23 );
13 = index of a flag in ->affected_by.bits[2]
31 = index of a flag in ->affected_by.bits[1]
00 = index of a flag in ->affected_by.bits[0] (nothing to set, and equivalent of APPLY_AFFECT)
In this way you can set a single flags for each array of bitmask [0]...[3]
If you want set more flags in a specific bitmask you can make something like:
->modifier with 9 numbers but...
first number is the array [0-3] and next numbers are flags....
->modifier == 111 ?
SET_BIT( ch->affected_by.bits[1], 11 ); with flags 11 == 2^0 + 2^1+2^3 for example.
->modifier == 23 ?
SET_BIT( ch->affected_by.bits[2], 3 ); with flags 3 == 2^0 + 2^1
some ideas...
More than one solution in any case: I think that APPLY_EXT_AFFECT in the smaug intention was create an extended affect. The problem, like I said, is that in affect struct the ->modifier isnt a EXT_BV so in building area files you can't store text like 0&0&0&0 (null bitmask).
If you store a bitvectory you need to chage in load_objects fread_number into fread_bitvector and and change the struct from int ->modifier to EXT_BV ->modifier. Too much code changes for a little improvment...
Another way:
you can create APPLY_EXT_AFFECT_1, APPLY_EXT_AFFECT_2 and APPLY_EXT_AFFECT_3 so you can set the EXT_BV bitmask with singles simple integer in this way:
with APPLY_EXT_AFFECT_1 will use:
SET_BIT( ch->affected_by.bits[1], mod ); (notice: SET_BIT not xSET_BIT)
with APPLY_EXT_AFFECT_2 will use:
SET_BIT( ch->affected_by.bits[2], mod );
etc...
Another way also could be this... more complicated but I'll try explain me with an example:
->modifier == 123133100 ? (we use always 9 numbers)
we split numbers in this way:
1|23|13|31|00|
1 = (no value)
23 = index of a flag in ->affected_by.bits[3] ... SET_BIT( ch->affected_by.bits[3], 1<<23 );
13 = index of a flag in ->affected_by.bits[2]
31 = index of a flag in ->affected_by.bits[1]
00 = index of a flag in ->affected_by.bits[0] (nothing to set, and equivalent of APPLY_AFFECT)
In this way you can set a single flags for each array of bitmask [0]...[3]
If you want set more flags in a specific bitmask you can make something like:
->modifier with 9 numbers but...
first number is the array [0-3] and next numbers are flags....
->modifier == 111 ?
SET_BIT( ch->affected_by.bits[1], 11 ); with flags 11 == 2^0 + 2^1+2^3 for example.
->modifier == 23 ?
SET_BIT( ch->affected_by.bits[2], 3 ); with flags 3 == 2^0 + 2^1
some ideas...
#7 Apr 24, 2020 8:16 am
Last edited Apr 24, 2020 8:16 am by Matteo2303
Apprentice
GroupMembers
Posts86
JoinedAug 25, 2003
ps: don't miss add case APPLY_EXT_AFFECT and relative code in:
aris_affect
showaffect
affect_modify
affect_loc_name
tiny_affect_loc_name
(in my codebase, I don't know about smaugfuss1.9 but much probably the same)
aris_affect
showaffect
affect_modify
affect_loc_name
tiny_affect_loc_name
(in my codebase, I don't know about smaugfuss1.9 but much probably the same)
#8 Apr 24, 2020 10:53 pm
Geomancer
GroupAdministrators
Posts1,917
JoinedJul 26, 2005
Glad you figured out a way around it, Id changed the setup in LoP long ago and used the extended bits even though id split things up a lot more. This is one that does need addressed in Fuss though lol.
#9 Apr 25, 2020 1:00 pm
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002
I'm pretty sure this also got updated to xBV in AFKMud before I then converted all of the BVs to std::bitset instead. It's not a task to be taken lightly either since there's a lot of places these things get used and you'll need to account for any pfiles or other data files that are storing data in the original format.
#10 Apr 25, 2020 9:33 pm
Geomancer
GroupAdministrators
Posts1,917
JoinedJul 26, 2005
Agreed, I remember it being quite a bit of work when I changed it all over lol.
#11 Apr 26, 2020 4:22 am
Apprentice
GroupMembers
Posts86
JoinedAug 25, 2003
Samson said:
I'm pretty sure this also got updated to xBV in AFKMud before I then converted all of the BVs to std::bitset instead. It's not a task to be taken lightly either since there's a lot of places these things get used and you'll need to account for any pfiles or other data files that are storing data in the original format.
I agree with you. This is the reason why I proposed a simple workaround without convert to EXT_BV.
Bye!
#12 Apr 26, 2020 12:56 pm
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002
Yes, and if that works for you, cool. I just don't see that kind of a workaround as an appropriate fix for it in the main codebase. For that I'd want to actually run it through as a proper conversion to EXT_BV.
#13 May 3, 2020 11:50 pm
Apprentice
GroupMembers
Posts86
JoinedAug 25, 2003
it would certainly be a better job. In my code I converted to extbv indeed. Strange that in many years the gap on the main code has never been noticed.
Pages:<< prev 1 next >>