11 Mar, 2014, Whitenoise wrote in the 1st comment:
Votes: 0
in skills.c i noticed something as I was going through adjusting fighting styles.


I am rewriting all the style types and changing them up a bit i could not find this reference in tables.c though I may have over looked it but would love to know if anyone has a clue where I might find it to adjust this so I dont have issues in the future.

– edit –
my issue isn't finding skill_table I wish to find where gsn_style_evasive is defined so i may adjust this reference as well as others in the future.

this is referenced around line 5814 in skills.c
11 Mar, 2014, Pymeus wrote in the 2nd comment:
Votes: 0
Looks like db.c, function boot_db() does it with a macro ASSIGN_GSN.
11 Mar, 2014, Whitenoise wrote in the 3rd comment:
Votes: 0
perfect thank you … i see many of them are defined here so I will be visiting this file a lot in the next week i think.
11 Mar, 2014, Whitenoise wrote in the 4th comment:
Votes: 0
however db.c seems to define these skills as
short gsn_style_evasive;

but upon removing the old *.o and recompilling after adjusting them lets just call it as

short gsn_new_name;

and altering
ASSIGN_GSN (gsn_new_name, " .. " );

when I alter the code i want adjusted in skills.c I still get an error stating that gsn_new_name is undefined…. which means it is defined somewhere else? I dont know why or how they could define it twice and not get a warning thrown.

– edit –

*declared (where applicable)
11 Mar, 2014, Whitenoise wrote in the 5th comment:
Votes: 0
meh they probably were not declared globaly let me go back into the function in skills.c and make sure they were not declared there as well.

**sorry for multiple posts**

– edit –

Yea I am stumped it is in function do_style() in skills.c that this all comes up later I will look at the scopes that call do_style and hopefully find my issue… however if i leave gsn_new_name as is after it compiles the c files the o files come up with an undefined reference… so all i can think of is the check the parent scopes.
12 Mar, 2014, Sharmair wrote in the 6th comment:
Votes: 0
Ok, this is a basic C question. When you compile a program in C you compile each file through the 3 stages we will all call
here compile, that is from the c file to the o file. then you use the link stage to make the final binary. Each c file is a self
contained unit and has no knowledge of any other c file.

What you do in the case where you define (actually allocate memory space for) something and want to have another c
file use it , is declare the item as being extern in the 2nd c file so it knows it exists but is someplace else and should resolved
in the link step. Normally (and in this case) such things are put in an h file that is #included in the c file, in this case mud.h.
12 Mar, 2014, Whitenoise wrote in the 7th comment:
Votes: 0
thanks i did find them in the mud.h header. And thanks for the example by the way sharmair. There are still some coding concepts when it comes to design that I am still learning. that makes a lot more sense of it.

Feel like a newbie, but glad I learned something.