Tall order regarding attributes

Posted by Jach on Fri 24 Oct 2003 08:17 PM — 11 posts, 32,872 views.

Jach USA Fri 24 Oct 2003 08:17 PM #0

What I'm looking at doing is changing the attributes so that "current" and "base" are not the same. Basically I want what the player rolls to become the "current" and have the "base" set accordingly (I haven't figured out what it will be yet).

That would involve the "base" becoming, for all intents and purposes, the "maximum" and I want it so the players attributes can only advance to the "maximum."

How would I accomplish this?

Thanks in advance to anyone that offers assistance, and my apologies to those that have to listen to my drivel.

David Haley USA Sat 25 Oct 2003 06:26 AM #1

Maybe this is a vocabulary issue, but is there not already a set of "current" and "base" stats? i.e. the stat, and then the modifier on it?

I think I see what you're getting at, but how is that different from just storing a third set of maximum values? In that case, all you have to do is set those at character creation in the same place as the normal stats are set, and then just add code to fwrite_char and fread_char, and you're set.

Jach USA Sat 25 Oct 2003 08:19 AM #2

There is a bit of a vocabulary issue. What is called base is ch->perm_(whatever), current is ch->perm_(whatever) + modifiers, so if there's no modifiers the current and base are the same. That's what I don't want.

I want the rolled stats to become the current stats, and then have maximums that those can not go over.( I have decided to have the maximums dependant on race and make it so the chosen classes prime atribute get's a small bonus.)

I'm about to call it a night so I'll try that suggestion in the morning. Thanks for the response.

EDIT: Looking at this again I'm seeing what you meant. Sorry for my confusion.

Meerclar USA Mon 27 Oct 2003 07:17 AM #3

Hrm, I havent looked into the code on how the stats arehandled, but the DoT codebase has this type of approach so maybe you can take a look and see how it's done there for some inspiration.

Greven Canada Mon 27 Oct 2003 04:01 PM #4

I think I know what your trying to do. SWR uses something similiar to this, since it comes with the trainer code. SWR uses hard coded racial statistics, referenced out of a table. It looks something like this:

/*
 * Race table.
 */
const struct	race_type	race_table	[MAX_RACE]	=
{
    /*  Race name	  Racial Affects   str dex wis int con cha lck frc hp mn re su 	RESTRICTION  LANGUAGE */
    {"Human",		  0,                0,  0,  0,  0,  0,  0,  0, 0,  0, 0, 0, 0,	0,	         LANG_BASIC      }
};

You could set something similiar up, and then have the get_curr_(attribute) functions in handler.c reference that, something to this affect:

sh_int get_curr_cha( CHAR_DATA *ch )
{
    sh_int max;
    max = UMIN(max,35);
    
    max  = 20 + race_table[ch->race].cha_plus;
    return URANGE( 3, ch->perm_cha + ch->mod_cha, max );
}

The trainging code adds to perm_(attribute), but I assume your running smaug, and I'm pretty sure its not in there. This will make it so that whatever their rolled stat(perm) and their modified stats(mod_) will never be able to go over what you set. Hope that helps.

David Haley USA Mon 27 Oct 2003 05:22 PM #5

I don't think that's the same thing, because those are racial bonuses and penalties.

SMAUG actually does have that. (At least my old 1.0 version does.) It sets the allowable maximum depending on whether the attribute is a prime attribute of the class or not.

Furthermore, we're talking here not about some maximum common to all players, but rather maximum attributes rolled individually for each player at creation.

That code you gave is also wrong. The max = UMIN(max, 35) makes absolutely no sense before you set max = (...) the line after. If the SWR people released that in their code... hrm. :) Someone didn't do their testing... :)

Jach USA Mon 27 Oct 2003 07:02 PM #6

Actually since my last post I have decided to do the maximums differently. What I'm wanting to do now is set the maximums based on race (so every race will have the same maximum stats) and then have the prime attribute of the selected class raise that particular max. Yes I'm planning on using a multiclass system once I get the time to start coding it.

If what I'm thinking is correct that would mean the rolled stats would be current (which is default) and the maximums would be referenced off the race table after being added. Does this sound correct?

David Haley USA Mon 27 Oct 2003 07:20 PM #7

Yes, that sounds correct. You would basically enter the new values into the race tables, and then adapt the get_curr_str, get_curr_dex ... functions to take that other maximum into account, given if the stat is a prime attribute or not.

However, if you do this, you no longer need to roll or store anything extra in the player files. More convenient, in my opinion. :)

Jach USA Mon 27 Oct 2003 07:30 PM #8

I would still need to roll because I want the player to roll for their starting stats. The max will be set by the race/class chosen but the starting stats would still need to be decided.

Thanks for the response.

David Haley USA Mon 27 Oct 2003 07:33 PM #9

Well, I meant to have the extra understood as distributed across the two, i.e. you won't roll anything extra, or won't store anything extra. In other words having a race table is a simpler solution than rolling an additional set of stats at the beginning.

You might want to go through your code and be very sure that all things that refer to strength and other attributes actually do use the get_curr_str function. I've noticed that not all of SMAUG follows SMAUG's conventions, so you may have a few isolated commands that don't take the correct version of the current strength.

Jach USA Mon 27 Oct 2003 07:43 PM #10

AAAAhhhh...now I see what you meant. And thanks for reminding me about checking for stray calls. I probably would have forgotten to do that.

Thanks again for the great help.