Jump to content

  •  

Bug Tracker Migration

June 3rd
Good news everyone! The staff has decided that it is time to slowly kill off this Bug Tracker. We will begin the process of slowly migrating from this Bug Tracker over to our Github Issues which can be found here: https://github.com/HerculesWS/Hercules/issues

Over the next couple of days, I will be closing off any opportunity to create new reports. However, I still will keep the opportunity to reply to existing Bug Reports. Doing this will allow us to slowly fix any bug reports we have listed here so that we can easily migrate over to our Issue Tracker.

Update - June 7th 2015: Creating new bug posts has been disabled. Please use our https://github.com/HerculesWS/Hercules/issues tracker to post bugs. Users are still able to reply to existing bug posts.

- Administration

Issue Information

Issue Confirmations

  • Yes (0)No (0)
Photo

Code-wise Script Variables Removal

Posted by Hercules Bot on 28 February 2008 - 11:29 PM

Originally posted by theultramage
http://www.eathena.w...er&showbug=1071

During the development of various features, there was the need to store small bits of persistent information.
And instead of making a new database field somewhere, the developer(s) decided to exploit the script engine's globalreg table.

Currently I've found:
  • jobchange_level - set when changing to 2nd job, only used by custom kafra express script
  • PC_DIE_COUNTER - death count, used for serverside novice stat calculations
  • TK_MISSION_ID and TK_MISSION_COUNT - used for tracking taekwon mission
  • various star gladiator vars - store marked locations / monsters
  • CLONE_SKILL and CLONE_SKILL_LV - the skill id/level of a plagiarized skill
  • PC_LAST_DUEL_TIME - timestamp of last duel
  • killerrid and killedrid - to let scripts know about kills/deaths
  • ZENY_HACKER - some wtf variable

... is this really a good idea?
Some of them needn't be stored between logins at all (killerrid/killedrid).
Some of them are universal and should get a table column instead.
Some of them are only related to a single class, which would probably waste space. Yet, using script variables seems like a very bad design idea to me...

Some of them needn't be stored between logins at all (killerrid/killedrid).

these are no longer stored as global regs.


others to the list:
"COOK_MASTERY"
"REPRODUCE_SKILL"
"REPRODUCE_SKILL_LV"
"jobchange_level_3rd"
feel map (star gladiator):
	pc_setglobalreg(sd,sg_info[i].feel_var,sd->feel_map[i].index);
const struct sg_data sg_info[MAX_PC_FEELHATE] = {
		{ SG_SUN_ANGER, SG_SUN_BLESS, SG_SUN_COMFORT, "PC_FEEL_SUN", "PC_HATE_MOB_SUN", is_day_of_sun },
		{ SG_MOON_ANGER, SG_MOON_BLESS, SG_MOON_COMFORT, "PC_FEEL_MOON", "PC_HATE_MOB_MOON", is_day_of_moon },
		{ SG_STAR_ANGER, SG_STAR_BLESS, SG_STAR_COMFORT, "PC_FEEL_STAR", "PC_HATE_MOB_STAR", is_day_of_star }
	};