31 Jul, 2010, om wrote in the 1st comment:
Votes: 0
if(IS_AFFECTED (victim, AFF_FORCE_SHIELD) && check_force_shield(ch, victim))
return FALSE;
if(IS_AFFECTED (victim, AFF_STATIC_SHIELD) && check_static_shield(ch, victim))
return FALSE;


in fight.c causes this:

gcc -Wall -O -ggdb -DNOCRYPT -DQMFIXES -c -o obj/fight.o fight.c
fight.c: In function damage:
fight.c:902: error: ff undeclared (first use in this function)
fight.c:902: error: (Each undeclared identifier is reported only once
fight.c:902: error: for each function it appears in.)
fight.c:909: error: gg undeclared (first use in this function)
fight.c: In function check_static_shield:
fight.c:1164: error: ff undeclared (first use in this function)
fight.c: In function check_flame_shield:
fight.c:1206: error: gg undeclared (first use in this function)
make: *** [obj/fight.o] Error 1


(ff and gg are the #define AFF_STATIC_SHIELD and AFF_FLAME_SHIELD in merc.h)

Any idea why this is happening? I made sure merc.h and magic.h are both defined at the top of fight.c, and it's driving me crazy.
31 Jul, 2010, bbailey wrote in the 2nd comment:
Votes: 0
om said:
(ff and gg are the #define AFF_STATIC_SHIELD and AFF_FLAME_SHIELD in merc.h)

Any idea why this is happening? I made sure merc.h and magic.h are both defined at the top of fight.c, and it's driving me crazy.


It sounds as though you need to create defines for the ff and gg bitmasks.

Somewhere, there should be defines like the following:
/* RT ASCII conversions – used so we can have letters in this file */

#define A 1
#define B 2
#define C 4
#define D 8
#define E 16
#define F 32

.
.
.

#define cc 268435456
#define dd 536870912
#define ee 1073741824


You'll need to add defines for ff and gg to the end of this list. You'll probably want to read up on bitmasks and variable types/sizes, since those ff and gg defines will put you outside the valid range for a 32bit integer.
31 Jul, 2010, om wrote in the 3rd comment:
Votes: 0
Ah. Missed that completely. Not sure what to do now, since obviously adding ff and gg is probably not the smartest idea. :|
31 Jul, 2010, Oliver wrote in the 4th comment:
Votes: 0
Well. First I would recommend looking through your list of affects that are already coded into the game. Odds are that you haven't utilized all the available space for your aff flags. The simplest way to do this is to just find the defines in merc.h.

If there are 32 flags defined A-ee, then you don't have any space left. If there's a gap where something isn't defined as its next logical successor (for instance, sanctuary is defined as 'F' and the next definition is 'L'), you can just insert your two affects there with the available bits.

If there is no space left, I would look at the affs that have been defined. Do you need all of them? If not, delete some (and their relevant code-references). In stock RoM, also, there are a couple defined aff bits that are just "AFF_UNUSED", as I recall.

But if you really have no available bits, then (as someone without a pretty comprehensive knowledge of C) it would probably be smartest for you to put in a new Affect2 field for characters. If you search for affect2 or aff2 on the code repo, you'll be able to find a plethora of snippets, I'm sure.
31 Jul, 2010, om wrote in the 5th comment:
Votes: 0
Oliver said:
Well. First I would recommend looking through your list of affects that are already coded into the game. Odds are that you haven't utilized all the available space for your aff flags. The simplest way to do this is to just find the defines in merc.h.

If there are 32 flags defined A-ee, then you don't have any space left. If there's a gap where something isn't defined as its next logical successor (for instance, sanctuary is defined as 'F' and the next definition is 'L'), you can just insert your two affects there with the available bits.

If there is no space left, I would look at the affs that have been defined. Do you need all of them? If not, delete some (and their relevant code-references). In stock RoM, also, there are a couple defined aff bits that are just "AFF_UNUSED", as I recall.

But if you really have no available bits, then (as someone without a pretty comprehensive knowledge of C) it would probably be smartest for you to put in a new Affect2 field for characters. If you search for affect2 or aff2 on the code repo, you'll be able to find a plethora of snippets, I'm sure.


They were all used, but that aff2 idea was great. rather than actually use a snippet i just grepped aff, affected_by, etc and made my own aff2. And tada.. it worked. I just had to tell the code for the shield spells to look at the affected_by2 table. Thanks. That worked perfectly.
31 Jul, 2010, Hades_Kane wrote in the 6th comment:
Votes: 0
Another solution, as you don't really necessarily have to have an AFF flag for everything affect. If there is a GSN entry for the affect, then you can check for that as well.

For example, I have a spell called zombie, and I also included gsn_zombie in the appropriate spot. Rather than having to mess with adding AFF_ZOMBIE, when I need to check if someone is inflicted with the spell, I check for:

if(is_affected (ch, gsn_zombie))


It's another way of looking at it, anyway.
31 Jul, 2010, om wrote in the 7th comment:
Votes: 0
Hades_Kane said:
Another solution, as you don't really necessarily have to have an AFF flag for everything affect. If there is a GSN entry for the affect, then you can check for that as well.

For example, I have a spell called zombie, and I also included gsn_zombie in the appropriate spot. Rather than having to mess with adding AFF_ZOMBIE, when I need to check if someone is inflicted with the spell, I check for:

if(is_affected (ch, gsn_zombie))


It's another way of looking at it, anyway.


I never thought of it that way. I might have to try that out anyway, because -one- of the three spells I added seems to be making those affected by it invisible… i can't figure out why. so, i'm going to try the gsn way and see if it does the same thing.
31 Jul, 2010, om wrote in the 8th comment:
Votes: 0
Nevermind… I found it. There was a part of the spell that looks up another spell, and I forgot an underscore in a certain spot. After I fixed that, those affected by the spell no longer get the bonus invis affect.
31 Jul, 2010, om wrote in the 9th comment:
Votes: 0
om said:
Nevermind… I found it. There was a part of the spell that looks up another spell, and I forgot an underscore in a certain spot. After I fixed that, those affected by the spell no longer get the bonus invis affect.


Actually, the mortal character I tested with still had detect invis up… BUT, I figured out what I did wrong. I mistakenly thought I could call my AFF2 stuff without adding the 2 so long as I did affected2_by… I was wrong-ish… it called the right affect, but also took the same affect with the same bit from the first AFF table… so AFF_STATIC_SHIELD was defined as B, and so was AFF_INVIS in the first AFF table… so they got STATIC_SHIELD and INVIS. I didn't notice it sooner because the A define on the first AFF set is AFF_BLIND has no effect on an immortal with holy light turned on. :| So, I redefined it as AFF2 everywhere and that fixed it fine.
01 Aug, 2010, om wrote in the 10th comment:
Votes: 0
Nope… still adding the ones from AFF to AFF2. Weird. I've gone through every AFF2 snippet available and verified that I did it right on my own, and still AFF_INVIS (B) and AFF2_STATIC_SHIELD (B) cause the person affected by static shield to gain invis. Strangely enough, though, someone with invis does not gain static shield.
01 Aug, 2010, jurdendurden wrote in the 11th comment:
Votes: 0
Hades_Kane said:
Another solution, as you don't really necessarily have to have an AFF flag for everything affect. If there is a GSN entry for the affect, then you can check for that as well.

For example, I have a spell called zombie, and I also included gsn_zombie in the appropriate spot. Rather than having to mess with adding AFF_ZOMBIE, when I need to check if someone is inflicted with the spell, I check for:

if(is_affected (ch, gsn_zombie))


It's another way of looking at it, anyway.



After much frustration and looking around I ended up doing my skills/affects this way. piece 'o cake. Just define the gsn in merc.h, db.c, and put the gsn_blah in the const.c table of skills/spells, and you're good to go.
01 Aug, 2010, Oliver wrote in the 12th comment:
Votes: 0
Using GSNs works fine actually in a lot of situations.

There is one where it doesn't, though. Using AFF bits is far more efficient regarding computational power. The general rule, as I have always understood it, is this: if you are going to be checking a character for the presence of an effect only in rare circumstances (maybe a spell that makes you immune to fireball; you would only need to check for the presence of the effect during your fireball-casting routine), using GSNs is acceptable (and even ideal).

If you are going to be checking it very frequently, though, you want to use an AFF bit. This is why spells such as Sanctuary and Invis have aff bits instead of just GSNs. Every single time the game deals damage to any character or mobile, it has to check if the victim is affected by sanctuary. Every single time stock RoM calls the PERS() macro, it checks if they are invisible (and replaces accordingly with "someone" if they can't be seen, etc.).

In my previous post, I guess I was just assuming that you needed AFF bits. I didn't really look at what you were doing. I haven't seen all your periphery code, but it seems to me that they're in the damage() routine (and functioning as additional dodges)? If that's the case, I'd highly recommend using AFF bits just for the computational power that they'll save. It's more efficient.
02 Aug, 2010, David Haley wrote in the 13th comment:
Votes: 0
Regarding efficiency of bit vectors vs. other data structures: the efficiency difference is not as large as you think, and you'd have to be checking thousands upon thousands of times a second to even notice the difference (assuming a reasonable data structure other than a bit vector).
06 Aug, 2010, Oliver wrote in the 14th comment:
Votes: 0
Out of curiosity, has anyone done any testing with this?

I'm not arguing, David Haley. I'm just curious! What if you had 50 people all fighting at the same time, and each time damage() is called it checks for the presence of an affect? Or checks more than once, even?

I wonder what the difference in CPU usage would be given a bitvector versus checking gsns.

I mean, the odds that any MUD will have 50 people fighting simultaneously are slim. That said, if the difference were noticeable, it would be worth consideration.
07 Aug, 2010, Chris Bailey wrote in the 15th comment:
Votes: 0
Oliver said:
I mean, the odds that any MUD will have 50 people fighting simultaneously are slim. That said, if the difference were noticeable, it would be worth consideration.


Eh? I've seen several muds with more than 50 players fighting simultaneously. :P
07 Aug, 2010, David Haley wrote in the 16th comment:
Votes: 0
It's pretty easy to measure the difference if you like between direct bit lookup and a hash table lookup, or a std::map which uses a binary tree. But even so the comparison you gave really isn't enough to warrant worrying on even a half-modern machine.
07 Aug, 2010, ralgith wrote in the 17th comment:
Votes: 0
Chris Bailey said:
Oliver said:
I mean, the odds that any MUD will have 50 people fighting simultaneously are slim. That said, if the difference were noticeable, it would be worth consideration.


Eh? I've seen several muds with more than 50 players fighting simultaneously. :P


No doubt, I've seen MUDs with over 1000 players online at once. Odds are at least half are fighting at the same time.
07 Aug, 2010, Oliver wrote in the 18th comment:
Votes: 0
Chris Bailey said:
Oliver said:
I mean, the odds that any MUD will have 50 people fighting simultaneously are slim. That said, if the difference were noticeable, it would be worth consideration.


Eh? I've seen several muds with more than 50 players fighting simultaneously. :P


Sure. The odds are still slim, though, seeing as how there are like 1.3x10^20 MUDs and maybe 100 with playerbases at peak reaching 50. 100's a stretch.
07 Aug, 2010, Davion wrote in the 19th comment:
Votes: 0
We're talking 50 right? And in bit lookups we're talking say, 60. Average is probably a lot less then 60, but affects are probably the more primary bit. Imagine you just store what affects a player has on them. So even with 20-30 affects on a single char, that's 30 iterations max, per player. I don't think you'll notice a difference. Most of the high level codebases I've seen don't even use bits. And we're talking about C here!
07 Aug, 2010, Runter wrote in the 20th comment:
Votes: 0
This is an example of premature optimization. The scale of negligance here is astronomical.

You'd be far better off optimizing other places with your time.

If you really want to test this then just benchmark the bitwise operations. My money is going to be on it handling 100's of thousands a second. Odds are even more.

So if that's our real concern 50 players would be a joke. If that's our only concern you could have 10's of thousands of players without need for alarm.
0.0/25