WEAR locations in smaugfuss based codebases
< Newer Topic
:: Older Topic >
Pages:<< prev 1 next >>
#1 Sep 30, 2013 12:20 am
Apprentice
GroupMembers
Posts58
JoinedNov 22, 2010
Hi guys,
I would like to ask you something about smaugfuss codebases. If someone knows the answer and can explain me, I appreciate it.
I am trying to add new wear locations in a smaugfuss based codebase but I am having some troubles. I founded a snippet wich explains how to do it and I followed all the instructions on it but when I show the items with equip command, it doesn't show well. for example, when i put a head wear flag, it shows me on finger, and something like that.
I don't understand why happend it. then, I am trying to add more ITEM_WEAR defines, but it only can do until a maximum of 31 items. I know that it seems too difficult to complete these, but I want to use each item separately from other items.
I forgot to tell you that I am trying to show the equipment from the top of the body to the bottom. for example, first head, then face, then eyes, etc, until the last thing I want to show is back.
Thanks so much if someone can help me.
Antram
I would like to ask you something about smaugfuss codebases. If someone knows the answer and can explain me, I appreciate it.
I am trying to add new wear locations in a smaugfuss based codebase but I am having some troubles. I founded a snippet wich explains how to do it and I followed all the instructions on it but when I show the items with equip command, it doesn't show well. for example, when i put a head wear flag, it shows me on finger, and something like that.
I don't understand why happend it. then, I am trying to add more ITEM_WEAR defines, but it only can do until a maximum of 31 items. I know that it seems too difficult to complete these, but I want to use each item separately from other items.
I forgot to tell you that I am trying to show the equipment from the top of the body to the bottom. for example, first head, then face, then eyes, etc, until the last thing I want to show is back.
Thanks so much if someone can help me.
Antram
#2 Sep 30, 2013 8:39 am
Last edited Sep 30, 2013 8:42 am by Patriot
Make sure everything stays on same order in all files.
#3 Sep 30, 2013 12:57 pm
Apprentice
GroupMembers
Posts58
JoinedNov 22, 2010
Hi,
Thanks for answering but I made sure good. Has any other suggestions?
thanks again. I founded a snippet wich explains how to convert bitvectors in extended bitvectors, but is for channels. I'm not sure if I have to follow the same instructions with ITEM_WEAR_HEAD and the other items in mud.h. I had seen that extended bitvectors are better than bitvectors because it allows you to enlarge the list of an item like I want. also I see that most things uses this system. why nobody has changed the other things wich are with bitvectors?
thanks again and sorry but I'm not sure if my english is good enough. I am trying to improbe it.
Thanks for answering but I made sure good. Has any other suggestions?
thanks again. I founded a snippet wich explains how to convert bitvectors in extended bitvectors, but is for channels. I'm not sure if I have to follow the same instructions with ITEM_WEAR_HEAD and the other items in mud.h. I had seen that extended bitvectors are better than bitvectors because it allows you to enlarge the list of an item like I want. also I see that most things uses this system. why nobody has changed the other things wich are with bitvectors?
thanks again and sorry but I'm not sure if my english is good enough. I am trying to improbe it.
#4 Sep 30, 2013 1:26 pm
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005
The problem with bitvectors, is that they were designed to solve a problem that no longer exists. Back in 1988, the typical MUD would be lucky to have access to a machine with 8M of RAM, and so trying to compress everything as tightly as possible was important.
Thus, you'll find lots of code that does stuff like:
if( x->bitthing & BIT_FOO | BIT_BAR | BIT_ACK ) do_stuff();
Now, you can easily change your structures to use extended bit vectors, or better yet, just stop using those antiquated things and "waste" the extra memory to make each "bit" a full boolean field. Oh no, your MUD will now take 64M of RAM instead of 8M... what will you do with the extra 3.9G ?
But, in either case, that will break the aforementioned style of coding, since you'd now do something like.
if( x->foo || x->bar || x->ack ) do_stuff();
Basically, nobody wants to go through all that legacy code and change it.
Thus, you'll find lots of code that does stuff like:
if( x->bitthing & BIT_FOO | BIT_BAR | BIT_ACK ) do_stuff();
Now, you can easily change your structures to use extended bit vectors, or better yet, just stop using those antiquated things and "waste" the extra memory to make each "bit" a full boolean field. Oh no, your MUD will now take 64M of RAM instead of 8M... what will you do with the extra 3.9G ?
But, in either case, that will break the aforementioned style of coding, since you'd now do something like.
if( x->foo || x->bar || x->ack ) do_stuff();
Basically, nobody wants to go through all that legacy code and change it.
#5 Oct 2, 2013 8:24 pm
Geomancer
GroupAdministrators
Posts1,917
JoinedJul 26, 2005
Haha I've done it before. I even once did them all as their own bool but later decided doing the EXT_BV was the best choice lol. It can be a bit of a pain depending on what you are changing from an int to an EXT_BV or even to a bool list.
#6 Oct 2, 2013 11:09 pm
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005
If you're willing to do the work, it's best to make every field its own value (boolean or not). Not only does that make the code easier to read, it also makes it trivial to export your data to a serializer like JSON, or to an SQL database schema where the schema is actually useful.
Consider, if you have a database schema where ROOM_DARK is a boolean, and SECT_TYPE is an integer that's a foreign key to a table that holds all the sector types (an enum, in code), you can do a query like SELECT vnum FROM rooms JOIN sector_types ON (sector_type_id) WHERE dark AND sector_type_name NOT IN ('indoors', 'underground'); to find all the dark rooms that are not indoor or underground rooms.
Doing that with bit vectors requires obnoxious math on the query side to filter out the bit values.
Consider, if you have a database schema where ROOM_DARK is a boolean, and SECT_TYPE is an integer that's a foreign key to a table that holds all the sector types (an enum, in code), you can do a query like SELECT vnum FROM rooms JOIN sector_types ON (sector_type_id) WHERE dark AND sector_type_name NOT IN ('indoors', 'underground'); to find all the dark rooms that are not indoor or underground rooms.
Doing that with bit vectors requires obnoxious math on the query side to filter out the bit values.
#7 Oct 4, 2013 8:47 pm
Geomancer
GroupAdministrators
Posts1,917
JoinedJul 26, 2005
well looks like in lop i switched most from using an int to EXT_BV only the object values still use IS_SET etc... and area status. I might consider it one of these days though just for the ease of things lol. Well I guess it all uses the bits though since EXT_BV does the same just with more ints haha. Might see just how hard it is to switch all the EXT_BV over to bools now though haha
#8 Oct 10, 2013 6:40 am
Apprentice
GroupMembers
Posts58
JoinedNov 22, 2010
Hi,
Since I asked here how to add new wear locations in smaugfuss, I've managed to expand the list of locations, but I have a problem. There is only a location wich I'm not able to use well.
Is te wear_hold location. I tried to use like others, without the argument "hold" when I write wear
Since I asked here how to add new wear locations in smaugfuss, I've managed to expand the list of locations, but I have a problem. There is only a location wich I'm not able to use well.
Is te wear_hold location. I tried to use like others, without the argument "hold" when I write wear
Pages:<< prev 1 next >>