27 Sep, 2007, Meryk wrote in the 1st comment:
Votes: 0
I'm not a programmer outside of beginner experience in PHP, so my abilities are limited to adding snippets.

I downloaded the Charge Snippet listed on this site that was written by Sadiq, and outside of minor changes that I can easily do to update the snippet, I've ran into some problems.

Everything with the snippet is fine, but I assume it is the upgrades in code that have caused the errors.

I am using FUSS 1.8 (snippet written for Smaug 1.02a, and have received the following compiling errors.
skills.c: In function âvoid do_charge(CHAR_DATA*, char*)â:
skills.c:6114: error: expected unqualified-id before âclassâ
skills.c:6114: error: expected `]' before âclassâ
skills.c:6114: error: expected `)' before âclassâ
skills.c:6147: error: expected unqualified-id before âclassâ
skills.c:6147: error: expected `]' before âclassâ
skills.c:6147: error: expected `)' before âclassâ
skills.c:6147: error: expected `)' before â;â token
skills.c:6147: error: expected `)' before â;â token

Here are the lines in question.

6114:
void do_charge( CHAR_DATA *ch, char *argument )
{
OBJ_DATA *wand;
int sn;
char buf1[MAX_STRING_LENGTH];
char buf2[MAX_STRING_LENGTH];
char buf3[MAX_STRING_LENGTH];
int mana;
int max_charge;
int charge;

if ( IS_NPC(ch) )
return;

—–>>>>> if ( !IS_NPC(ch) && ch->level < skill_table[gsn_charge]->skill_level[ch->class] )
{
send_to_char( "A skill such as this is presently beyond your comprehension.\n\r", ch);
return;
}

6147:
if ( SPELL_FLAG(skill_table[sn], SF_NOCHARGE) )
{
send_to_char( "You cannot charge that spell.\n\r", ch );
return;
}

—–>>>>>mana = IS_NPC(ch) ? 0 : UMAX(skill_table[sn]->min_mana,
100 / ( 2 + ch->level - skill_table[sn]->skill_level[ch->class] ) );

mana *=3;


Any help would be appreciated.



Also, I will be updating the snippet once this is complete, and adding it to the snippets section. So, you wouldn't just be helping me. :blues:
27 Sep, 2007, David Haley wrote in the 2nd comment:
Votes: 0
10 to 1 odds you are compiling with g++ and not gcc. 'class' is a reserved keyword in C++, so you can't use it for member field names. You might notice that FUSS uses 'Class' (note uppercase c) several times; pretty much for just this reason.
27 Sep, 2007, Guest wrote in the 3rd comment:
Votes: 0
Also further worth noting that FUSS 1.8 compiles using g++ by default, which is why "class" complains. That naturally means a lot of snippets that run into this sort of problem will need updating to work.
27 Sep, 2007, Meryk wrote in the 4th comment:
Votes: 0
Thanks.

I'll update this snippet as best I can and send it in. Appreciate the help.

BTW, changing it to 'Class' with the uppercase 'C' did the trick.

Thanks again.
27 Sep, 2007, Meryk wrote in the 5th comment:
Votes: 0
I uploaded an updated snippet, but accidentally sent it to the SWR snippets. Hope this doesn't cause too much of an inconvenience.
27 Sep, 2007, Guest wrote in the 6th comment:
Votes: 0
No worries, it's been moved to the right spot. Thanks :)
20 Oct, 2007, Noplex wrote in the 7th comment:
Votes: 0
I took a look at your updated snippet.

You can remove all the references to checking if a person is a character (!IS_NPC(ch)) after the first if-check. Because the first check prevents NPCs from using the command anyway. I haven't looked at that Macro in awhile, but its simply a check to see if the person has a network descriptor, correct? Nevertheless, unless it checks for something else, you should be find removing all the checks for it.
21 Oct, 2007, Guest wrote in the 8th comment:
Votes: 0
The IS_NPC macro actually looks to see if they have an ACT_IS_NPC bit, which is normally only applied to mobs in create_mobile. It might not be a bad idea to throw in a !ch->pcdata check since that's usually what people are really looking for is to make sure there's no pcdata pointer.
21 Oct, 2007, Noplex wrote in the 9th comment:
Votes: 0
Samson said:
The IS_NPC macro actually looks to see if they have an ACT_IS_NPC bit, which is normally only applied to mobs in create_mobile. It might not be a bad idea to throw in a !ch->pcdata check since that's usually what people are really looking for is to make sure there's no pcdata pointer.

Yeah, I haven't looked at the code forever. But he doesn't need to be checking it throughout the command when he does it at the top. I mean, you are not going to see anything in terms of optimization, but its a good thing to keep in mind for future instances.
0.0/9