11 Mar, 2014, Whitenoise wrote in the 1st comment:
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.
11 Mar, 2014, Whitenoise wrote in the 4th comment:
however db.c seems to define these skills as
but upon removing the old *.o and recompilling after adjusting them lets just call it as
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.
11 Mar, 2014, Whitenoise wrote in the 5th comment:
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.
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:
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.