Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Development

Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum)

Reply
 
Thread Tools Display Modes
  #1  
Old 02-05-2014, 09:38 PM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

I don't know if ScaleItem() if fully implemented yet..could very well be...

https://github.com/EQEmu/Server/blob.../Item.cpp#L710


The last assignment of that function sets the m_scaledItem->CharmFileID = 0 to keep the client from scaling it.

If the item is being sent with the original m_item data and not overriding the m_item->CharmFileID..and the client does its own
scaling modifications..you might see a double scaling going on...

I dunno..I haven't gotten that far in the code yet


If this is the case, I'll fix it in my rework..I've already got ornamentations planned. If it's not, I'll let someone else touch it because
I don't want to stop my rework
__________________
Uleat of Bertoxxulous

Compilin' Dirty
Reply With Quote
  #2  
Old 02-07-2014, 03:35 PM
DrakePhoenix
Fire Beetle
 
Join Date: Jan 2014
Posts: 22
Default

Thanks for the response Uleat.

I don't think the ScaleItem function actually affects item stat scaling for when the character level is below the recommended level. The ScaleItem function looks to me like it only affects evolving items, and here's why...

The function is only ever called if the m_scaling value of the item instance is true. The m_scaling value is only ever set to true in the Initialize function (at least, there is no other occasion that it is set to true in my current version of the source code, but I haven't updated since 01/23/2014), and then only if the CharmFileID for the item is non-zero. In the current peq database there are exceptionally few items that have a non-zero charmfileid (or at least the 01/24/2014 dump that I'm currently using has exceptionally few). Additionally, the ScaleItem function itself doesn't check against the character level for the MOB that has the item equipped, nor against the reclevel for the item instance. Instead, the function checks against the *item's* accumulated EXP. As far as I know, only evolving items ever accumulate EXP.

Also, the items that I've used and noticed discrepancies with do not have non-zero charmfileid values, so they wouldn't be scaling from the ScaleItem function anyway.

Thanks for the suggestion, but I think the issue has to be somewhere else in the code. Also, I've ignored the apparent discrepancies and played normally a bit anyway, and it seems as though the HP discrepancy diminishes as the character levels up, but that Mana and Endurance discrepancies appear and then increase as the character levels up. I only just started paying attention to this last night, so I'm not positive that is actually happening. I'm going to do some deliberate testing for this and see if I can confirm the trend.

Also, I was poking around the code in a few other places, and I noticed that item stat scaling does not occur for bots based on bot level being below the reclevel for the equipped item. Is there a specific reason for this? Or was it simply not addressed previously? It seems to me that bots should *not* get full, unscaled stats from items if they're below the reclevel for the item.

Anyway, I'll keep poking around and see if I can figure anything out for this.

Thanks,
Drake Phoneix
Reply With Quote
  #3  
Old 02-08-2014, 03:01 PM
DrakePhoenix
Fire Beetle
 
Join Date: Jan 2014
Posts: 22
Default

OK, so I did some more checking and experimenting...

It turns out that while the original code appears to handle scaled HP incorrectly, it does handle Mana and Endurance correctly. I had made changes to the code to try and get HP to work, and that's when the Mana and Endurance started showing discrepancies. I'm not sure why this is the case, but it appears that HP is handled differently than Mana and Endurance in terms of the actual data values used. I can't figure that one out, but I'm not too worried about it.

When I changed the code to try and fix the HP issue, I used implicit type conversion, and this caused the issue with Mana and Endurance to show up. Apparently there was some data loss and it was setting the return values for scaled Mana and Endurance to be 0, so the server was using values as though there was no bonus Mana or Endurance, while the client was showing the correct values for what should have been there. I changed it again to use explicit type conversion and now all three seem to work correctly, at least on my client and server combination (server is slightly modified from 01/23/2014 git, client is RoF).

If anyone is interested, all I changed was the CalcRecommendedLevelBonus function in bonuses.cpp to use float values instead of int values. I didn't honestly expect that to work, I just wanted the code to make more sense to me personally, but it seems to have solved the issue. Following is my modified function...

Code:
int Client::CalcRecommendedLevelBonus(uint8 level, uint8 reclevel, int basestat)
{
	if( (reclevel > 0) && (level < reclevel) )
	{
		// DrakePhoenix:  original function...
		/*int32 statmod = (level * 10000 / reclevel) * basestat;

		if( statmod < 0 )
		{
			statmod -= 5000;
			return (statmod/10000);
		}
		else
		{
			statmod += 5000;
			return (statmod/10000);
		}*/

		// DrakePhoenix:  my function... designed to use full float values, then use standard rounding
		// values between 0.0 and 1.0 will always be 1.0
		// negative values will not be scaled
		int32 statmod = 0;
		float statmodf = (float(level) / float(reclevel)) * float(basestat);

		statmodf = statmodf + 0.5; // used for rounding, necessary for float-to-int truncation
		// standard rounding would normally require a -0.5 for negative values, but since negative values are not scaled, no need

		// if scaled stat bonus is greater than 0.0 but less than 1.0, use value of 1.0
		if((statmodf > 0.0) && (statmodf < 1.0))
		{
			statmodf = 1.0;
		}

		statmod = int32(statmodf); // convert float value to int value so we can return int.

		// if basestat is a negative value, do not scale, but use full amount
		if(basestat < 0)
		{
			statmod = basestat;
		}

		return statmod;
	}
	
	return 0;
	
}
Using my modified function as above the client and server both now seem to agree on max and actual stats for HP, Mana, and Endurance when using level-scaled bonuses.

Take care,
Drake Phoenix
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 08:50 AM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3