Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ SMAUG ➜ SMAUG coding ➜ Temporary bonuses from attributes
Temporary bonuses from attributes

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 

Posted by Tseris   (98 posts)  Bio
Date Reply #15 on Sun 21 Oct 2007 07:21 PM (UTC)
Message
Oh son of a....
Top
Posted by Tseris   (98 posts)  Bio
Date Reply #16 on Mon 22 Oct 2007 03:03 AM (UTC)
Message
Okay so that allowed it to compile, though I tried it out using a test object and no luck, increasing my CON isnt increasing my max_hit. Though if I adjust the test object to give +hit, then it works. So Im going to track down the APPLY_HIT that comes from the object affects list and try to see how it works.

But my next question is, is handler.c the right source file to even be putting this snippet in? Or does it even really matter? I still havent gotten a good grounding as to which source files are doing what, alot of the code for doing anything in particular seems like its spread over three or four source files.

My other thought was maybe to put the snippet in update.c where the game would be continually checking different aspects of the character, so one of the things it could be updating is the current attributes and what bonuses they should be getting.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #17 on Mon 22 Oct 2007 04:03 AM (UTC)
Message
Quote:
Or does it even really matter?

It doesn't matter as far as functionality is concerned. It matters only insofar as stuff is easy to find when you need to change it. So, putting it into act_comm.c might not be the best place. :-)


You know, the effects system in SMAUG kind of scares me; it's kind of hackish at points and isn't good about keeping backups (it works directly on the variables, so if it makes a mistake, you just lost data forever). You're pretty courageous to be working on this problem early on. :)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Gohan_TheDragonball   USA  (183 posts)  Bio
Date Reply #18 on Mon 22 Oct 2007 12:24 PM (UTC)
Message
yeah i got tired of having to restore players due to a crash while they were being affected by a hit affect thats why i went the route of adding the third variable that is not modified by affects.
Top
Posted by Tseris   (98 posts)  Bio
Date Reply #19 on Mon 22 Oct 2007 03:12 PM (UTC)
Message
Hrmm. Advice duly noted. Maybe I am jumping the gun a bit, I wanted to do the attributes rather early because as you can tell my game design is very attribute-centered when it comes to the balance of whether one max leveled character will defeat another in pvp. Also, knowing ahead of time what attributes are doing helps me in race creation when it comes to which races should get pluses or negatives to which attributes.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #20 on Mon 22 Oct 2007 05:42 PM (UTC)
Message
If you want to follow this route, I strongly suggest you do what Gohan did. Spend a little time overhauling the system a bit, and add 'permanent' attributes. Those never got modified by the effect system. That way, if worse comes to worse and something does happen (which unfortunately always happens... sigh) you have a record of what the character's actual stats are.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Tseris   (98 posts)  Bio
Date Reply #21 on Mon 22 Oct 2007 07:33 PM (UTC)
Message
Well the game does keep track a character's permanent attributes (STR, INT, etc) correct? Thats how they are displayed on the stock do_score output anyway. All Id have to do is put in something to keep track of the character's permanent hit, mana, move, etc right?
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #22 on Mon 22 Oct 2007 08:12 PM (UTC)
Message
Yeah, you only need to add permanent markers for attributes that don't already have them.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Tseris   (98 posts)  Bio
Date Reply #23 on Mon 22 Oct 2007 08:25 PM (UTC)
Message
Alright Im gonna go through and see how it has the ones with permanent statistics already set up and see if i can use that as a template. Thanks everyone.
Top
Posted by Kregor   (4 posts)  Bio
Date Reply #24 on Sat 02 Feb 2008 06:28 PM (UTC)

Amended on Sat 02 Feb 2008 06:33 PM (UTC) by Kregor

Message
Personally, I didn't like the way attributes and skill levels were modified directly by the affects, so I pretty much castrated the affect modifying functions that added and subtracted directly from player file fields. I decided to make new functions that dynamically tally and calculate the applies on any given attribute whenever a call is made to them (which I called get_apply). I suppose storing it in the pfile was, at one point in computer history, a faster way to access them, but really with computer processors of today, just let them do a little math.

I also replaced the max_hit value with perm_hit, similar to suggestions here, to keep the total exp as a character gains level, THEN, I made another int function, get_max_hit, which dynamically tracks the current maximum hitpoints a character has.

This is an example, which you can't directly cut and paste, because there are more new functions (like a macro for calling the stat_app tables) and fields I've placed in my mods. But you could adapt if you wanted. I'm not claiming it to be the cleanest or the best, but it works :)


int get_max_hit( CHAR_DATA *ch )
{
	int pts;
	
	pts = ch->perm_hit + (stat_bonus(TRUE, ch, APPLY_CON) * ch->level);
	pts += get_apply_plus(ch, APPLY_HIT);
	pts += get_apply_minus(ch, APPLY_HIT);
	
	pts = UMAX(ch->level, pts);
	
	return(pts);
}


Note in my get_apply functions, I wanted the rules of the game to make the same apply NOT stack bonuses, so the results below only return the highest bonus. If you wanted to stack the bonuses original Smaug style, you would ditch the if (paf->modifier < mod) bits, and change the "=" in "put mod = paf->modifier;" to a "+="

int get_apply_minus(CHAR_DATA * ch, int apply)	
{
	OBJ_DATA *obj;
	AFFECT_DATA *paf;
	int mod = 0;
	
	for (obj = ch->first_carrying ; obj ; obj = obj->next_content)
	{
		if (obj->wear_loc != WEAR_NONE)
		{
			for (paf = obj->first_affect ; paf ; paf = paf->next)
			{
				if (paf->location == apply)
				{
					if (paf->modifier < mod)
						mod = paf->modifier;
				}
			}
			for (paf = obj->pIndexData->first_affect ; paf ; paf = paf->next)
			{
				if (paf->location == apply)
				{
					if (paf->modifier < mod)
						mod = paf->modifier;
				}
			}
		}
	}

	for (paf = ch->first_affect ; paf ; paf = paf->next)
	{
		if (paf->location == apply)
		{
			if (paf->modifier < mod)
				mod = paf->modifier;
		}
	}
	return (mod);
}



And if you want the hitpoint bonus to show immediately after adding the item or spell, simply place a bit in the wear command or the spell code, before the item goes on or affect gets applied, to find the difference between your current and max_hit, then after the apply, another bit to make the character's current hit = get_max_hit(ch) - the difference.

another bit in affect_strip to compare the current hitpoints with get_max_hit and level it off will make sure that the character doesn't go around with extra hit points after the apply goes away.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #25 on Sat 02 Feb 2008 11:24 PM (UTC)
Message
You could avoid looping all the stuff twice by having the function "return" results by storing them in pointers passed in as arguments.

What I would do if I were unlazy enough to implement this would be to have a caching of sorts. This information doesn't change [i]that[/i] often, so it's worthwhile to not loop over the entire equipment and effect lists every time you need to look up a player's attributes. Instead, I would have it compute it when it needs it, and then store it away in a cache; if the equipment or effects change, invalidate the whole cache (or just relevant cache items) and compute things again the next time you need them.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Kregor   (4 posts)  Bio
Date Reply #26 on Wed 13 Feb 2008 05:26 PM (UTC)
Message
So if I follow what you're saying:

Basically, it would be quicker and less looping to make new fields in the pfile that would store the get_apply tally -- in my case, probably an array, since I have round about 130 apply locations (so for example, say ch->apply[MAX_APPLY]).

Then whenever affect_modify is called it runs the tally in get_apply, and stores it in the new pfile field. Then I would call from the pfile instead of the loop. For example, "get_curr_str" will call on ch->apply[APPLY_STR] instead of the get_apply loop.

Did I follow that right?
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #27 on Thu 14 Feb 2008 11:22 PM (UTC)
Message
Yup, exactly. Create an array big enough to store the total for each tally type, and then whenever something changes (like equipment going on or off, a spell cast, etc.) recompute all of the tallies (or if you want to be smart, just the relevant tallies). This way, you will do the loop on the relatively rare event of a change, and have a one-step process for finding the tally on the relatively frequent case of needing one of the values.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Kregor   (4 posts)  Bio
Date Reply #28 on Fri 15 Feb 2008 08:02 PM (UTC)

Amended on Fri 15 Feb 2008 08:08 PM (UTC) by Kregor

Message
Done. Added the array, then put calls to get_apply in affect_modify for only the location of the affect, recording it in ch->affect[location], then replacing all the other calls to get_apply in other functions was a fairly painless find/replace operation.

While I was at it, I added a bit to calculate, then add the applicable stat bonuses before and after the actual call to get_apply, so it now adds or removes the temporary bonuses (like hitpoints, move points, etc) also into affect modify, so I was able to take the calls to adjust these out of the spells and equip and unequip char.

I see about 30-40 usec difference in typing "score" which calls on all the get_curr_<everything>'s. But that should add up with multiple players doing multiple things that make calls on multiple applies.

Thanks!
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

82,050 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home