Paid service - Intel & Luscha Systems

(Pictures taken from our old server's description)

This was part of the Raids, dungeon instances with a specified Boss that do not get destroyed, even after restarting the server. It could be a solo instance, guild or global

Video example:

Flags for the cube to check before crafting something (a quest flag, or a skill_level). ex:

section		
	npc	20018	
	item	50723	3
	item	50724	1
	item	50730	2
	item	27995	10
	reward	50828	1
	flag	collect_item.collect_item_cube	>=	1	
	percent	100	
	gold	10000
	category	DEWS
end	

Possibility to choose multiple upgrades for a single item and to add custom items to modify the upgrade behavior (more %, cannot break, up goes -1 or -2 etc.). We also introduced a new fail mechanic, called "brick". If the upgrade fails, there is another percentage that the item gets bricked and cannot be upgraded anymore.

Video example:

Complete refactor of the guilds. Customizable roles, detailed view of the members, no more exp donation. Guild wars were matchmaking only, with a fixed size for the teams. You could choose the roster before declaring a war.  Ladder reset at the end of the season. Even the guild's terrain, it wasn't a part of a map, but a private one. A 2x2 map fully available for the guild to customize.

• Available for dungeons (even with personalized tables for every type of dungeon). Example:

	m_kConfigurations.strKillTable = "gw_kill_history";
	m_kConfigurations.strActionTable = "gw_action_history";
	m_kConfigurations.strPlayerTable = "gw_player_snapshot";
	
	m_kConfigurations.strArgsColName[0] = "war_id";
	m_kConfigurations.strArgsColName[1] = "guild_id";

This means there will be two additional columns, war_id and guild_id for those tables, in this case, concerning Guild Wars.

• You can add additional tables for detailed info. Example:

void StatsManager::GWMatchHistoyLog(TGWMatchHistoryLog & sLog)
{
	Query("INSERT DELAYED INTO gw_match_history("
	"id, "
	"guild_id1, guild_id2, "
	"guild_name1, guild_name2, "
	"guild_point1, guild_point2, "
	"ladder_before1, ladder_before2, "
	"ladder_after1, ladder_after2, "
	"winner, type, map_index, ranked, start_time, end_time"
	") VALUES ("
		"%u, "
		"%u, %u, "
		"'%s', '%s', "
		"%u, %u, "
		"%u, %u, "
		"%u, %u, "
		"%u, %u, %u, %u, FROM_UNIXTIME(%u), FROM_UNIXTIME(%u))", 
	sLog.dwID, 
	sLog.dwGID[0], sLog.dwGID[1], 
	sLog.szName[0], sLog.szName[1], 
	sLog.dwPoint[0], sLog.dwPoint[1], 
	sLog.dwLadderBefore[0], sLog.dwLadderBefore[1], 
	sLog.dwLadderAfter[0], sLog.dwLadderAfter[1], 
	sLog.dwWinner, sLog.bType, sLog.dwMapIndex, sLog.bRanked, sLog.dwStart, sLog.dwEnd
	);
}

This way we have complete info of the outcome of the wars. LPs, map, type and time.

• You can decide what to log:

	m_kConfigurations.eVerbosity = (stats::EVerbosityLevel)(
		stats::VERBOSITY_KILL | 
		stats::VERBOSITY_POINTS | 
		stats::VERBOSITY_ASSISTS | 
		stats::VERBOSITY_DAMAGE | 
		stats::VERBOSITY_HEAL | 
		stats::VERBOSITY_CROWD_CONTROL |
		stats::VERBOSITY_PLAYER |
		stats::VERBOSITY_ITEM
		);

VERBOSITY_KILL: kills will be logged

VERBOSITY_POINTS: this will log whenever a point is gained. Example: a kill in a war, 1 point -> logged

VERBOSITY_ASSISTS: yes, the game will recognize assists for the kills

VERBOSITY_DAMAGE: this logs the damage (type and quantity)

VERBOSITY_HEAL: whenever an heal from the shaman is executed

VERBOSITY_CROWD_CONTROL: Slow/Stun/Dispel/Cleanse/Poison/Fire/Bleeding

VERBOSITY_PLAYER: the system will make a snapshot of the player entering the dungeon/war/etc.

VERBOSITY_ITEM: logs the items a player has entered with, equip/unequip/use of items.

• The class is extendible for any personalized system (the installation is not included for one of your systems, like Vegas' PvP tournament).
• The system contains a quest command to initialize the log of a dungeon:

				d.new_jump(66, special.devil_tower[1][1]*100, special.devil_tower[1][2]*100)
				d.set_first_login_event("first_deviltowerzone")
				d.setf("ue_deviltower_zone", 1)
				d.initialize_stats("DEVIL_TOWER")

always, ALWAYS, put initialize_stats AFTER THE JUMP. The function needs a string as the type of the dungeon (in this case it was the devil tower one). This type will be saved in your "dungeon_run_history":

void CDungeonStats::LogMatch()
{
	TDungeonHistoryLog sLog{};

	sLog.dwID = m_dwID;
	sLog.dwMapIndex = m_pkDungeon->GetMapIndex();
	sLog.dwStart = m_dwStart;
	sLog.dwEnd = m_dwEnd;
	sLog.bComplete = m_pkDungeon->IsCompleted();
	sLog.DungeonType = m_DungeonType; //THIS
	
	StatsManager::instance().DungeonHistoyLog(sLog, strTableName, strAddArgsColName, strAddArgsColValue);
}

• Example of what's saved in the database:

• Example of what was shown in our website:

• TO DO WIP:
  • Logging of the items

• Possibility to create w/e team's size type of arenas (1v1 2v2 3v3 4v4 5v5 etc.):

			switch (pkLobby->GetSubType())
			{
				case PVP_ARENA1:
					pkLobby->SetMemberLimits(2, 2);
					break;
				case PVP_ARENA2:
					pkLobby->SetMemberLimits(4, 2);
					break;					
				case PVP_ARENA3:
					pkLobby->SetMemberLimits(6, 2);
					break;
			}

• Matchmaking between cores/channels
• There are two kind of queues: "custom" and "normal draft". Like, for example, in LoL, the first one enables x players to just form the teams by themselves. Normal draft instead utilizes the matchmaking system provided by the lobbies system
• You can ban players from the arena
• You can block the chat of a player requiring him to do a certain amount of arenas to unlock it
• If players disconnect more than three times, they get banned from the arenas
• You can choose the level limit groups between the players in the Arena. For example, you can have the system from level 40 to 120 and match the players only between levels 40 and 69, 70 and 100, 101 and 120 (default one)
• You can choose the level limit distance between players (default +10/-10)
• You can choose to limit the "normal draft" (or also called random) arenas for a specific time frame:

	if(pkLobby->GetType() == LOBBY_TYPE_PVP_ARENA)
	{
		std::time_t t = std::time(0);
		std::tm* now = std::localtime(&t);

		if(now->tm_hour < 18 || now->tm_hour >= 23) //if less than 18:00 or greater or equal than 23:00
		{
			if(g_bIsTestServer){
				pkLobby->SendChatPacketToMembers(CHAT_TYPE_INFO, "<Lobby> TEST SERVER OK! REAL SERVER: Random not open.");
			}
			else{
				return -2;
			}
		}
	}

• You can set and differentiate prizes between winners and losers. Base files give a type of coin, but you can ask me to set whatever you want:

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//with coin amount
const uint32_t PointsToWinnerByType[PVP_ARENA_MAX_NUM] = {AMOUNT_W_PVP_ARENA1, AMOUNT_W_PVP_ARENA2, AMOUNT_W_PVP_ARENA3};
const uint32_t PointsToLoserByType[PVP_ARENA_MAX_NUM] = {AMOUNT_L_PVP_ARENA1, AMOUNT_L_PVP_ARENA2, AMOUNT_L_PVP_ARENA3};

constexpr uint32_t getWinnersPrize(uint8_t ArenaType)
{ return PointsToWinnerByType[ArenaType]; }
constexpr uint32_t getLoserssPrize(uint8_t ArenaType)
{ return PointsToLoserByType[ArenaType]; }
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//with items
const uint32_t PrizeToWinnersByTpe[PVP_ARENA_MAX_NUM][2] = {
  {PRIZE_W_PVP_ARENA1[0],PRIZE_W_PVP_ARENA1[1]},
  {PRIZE_W_PVP_ARENA2[0],PRIZE_W_PVP_ARENA2[1]},
  {PRIZE_W_PVP_ARENA3[0],PRIZE_W_PVP_ARENA3[1]},
};
const uint32_t PrizeToLosersByTpe[PVP_ARENA_MAX_NUM][2] = {
  {PRIZE_L_PVP_ARENA1[0],PRIZE_L_PVP_ARENA1[1]},
  {PRIZE_L_PVP_ARENA2[0],PRIZE_L_PVP_ARENA2[1]},
  {PRIZE_L_PVP_ARENA3[0],PRIZE_L_PVP_ARENA3[1]},
};

constexpr auto getWinnersPrize(uint8_t type)
{ return PrizeToWinnersByTpe[type][0]; }
constexpr auto getLosersPrize(uint8_t type)
{ return PrizeToLosersByTpe[type][0]; }
constexpr auto getWinnersPrizeAmount(uint8_t type)
{ return PrizeToWinnersByTpe[type][1]; }
constexpr auto getLoserssPrizeAmount(uint8_t type)
{ return PrizeToLosersByTpe[type][1]; }
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

• The base system DOES NOT INCLUDE: statistics/seasons
• The base system DOES INCLUDE: lobbies system, extension of CCI infos and WarpSet and Fake Clocks system. The extension of CCI infos and WarpSet are required for checks during or before a warp, for example it cancels an exchange and the warp is delayed:
• TO DO WIP:
  • Ranked mode with an ELO rating system different for queue
  • Season system
  • Interface with your stats about rank/kda of the season in the different types of arena

• This system is part of the lobbies system and it gives the ability to create lobbies to search parties for a specific dungeon/activity
• It's also possible to select a player in the list and check some basic infos (name, level, job)
• The base system DOES INCLUDE: lobbies system, extension of CCI infos and WarpSet. The extension of CCI infos and WarpSet are required for checks during or before a warp, for example it cancels an exchange and the warp is delayed:
  • The system warps the player to the chosen location for the party and instantly creates one
  • If the leader of the lobby does not have a party, a new one gets created, otherwise their party is selected.
  • If the number of players that applied to the lobby are more than the number of players in the already existing party, the existing players in the leader's party are kicked and the ones in the lobby will be added.
  • (if you wanna change the behavior, just ask. For example, do not delete the leader's party and you can start the lobby only if the members in it plus the members of your party do not exceed the maximum number of players in a party)

• Original Blends are very limited, can't be really stacked, and not very much space for customization except for their gimmick of random values.
• This system introduce a new type of item: ITEM_TYPE_AFFECT
• This new type of item can have multiple bonuses
• You can set up the items in a simple single yaml configuration file:

RED_BLEND:
 vnum: 50821
 affect: 671
 bonuses:
 - type: MAX_HP
   value: 2000
 - type: ATTBONUS_DEVIL
   value: 20   
 duration: 600
ORANGE_BLEND:
 vnum: 50822
 affect: 672
 bonuses:
 - type: ATTBONUS_DEVIL
   value: 8
 - type: ATTBONUS_ISLAND
   value: 8   
 duration: 600
YELLOW_BLEND:
 vnum: 50823
 affect: 673
 bonuses:
 - type: ATTBONUS_ISLAND
   value: 8
 duration: 600
GREEN_BLEND:
 vnum: 50824
 affect: 674
 bonuses:
 - type: ATTBONUS_MILGYO
   value: 8
 duration: 600
BLU_BLEND:
 vnum: 50825
 affect: 675
 bonuses:
 - type: ATT_BONUS_METIN
   value: 8
 duration:

• Unlike blends, no, you cannot choose different times and/or values. They are set, but can be how many you want. You can stack them adding more time (you can set the max time of a single item, if you want to). You can activate and dis-activate them. They differentiate by the value of the affect.
• The system, as indicated before, can coexist with the blends if you want to keep them.
• If you create two items with the same affect but with different bonus types, the system right now can't determine their correct value when being shown in the top left corner (in uiaffectshower, strictly speaking). So if you have in mind to create this sort of gymmick, where you want to create different "levels" of an item, it will work, but right now they will only show the type of bonus. If the bonuses are different (but same affect) then, again, they will be the same (so only one between them can be active at the same time) but in the left top corner, only one or the other bonus type can be shown.
• This system will require a complete refactor of the item/inventory class (server and client side), hence the high price despite being a simple system.
• Video:

• The original shops in metin, are loaded from db first. In those, the price type is always Yang. To accommodate new type of prices, you could use item_shop_ex, which is limited. Only one price type per shop. Can't be multiple type of prices for a shop or even a single item.
• With this system the whole item_shop_ex will be nuked and replaced by a new class that will load all item's prices.
• Everything will be set up from a simple configuration file. Example:

ITEM_WANTED_NOTICE_C:
 item_vnum: 100467
 NPC:
  3001:
   npc_vnum: 3001
   price_index: 0
   prices:
    - price_type: ITEM
      price_cost: 102543
      price_count: 50  
ITEM_HUNTER_RUBY:
 item_vnum: 102543
 NPC:
  3001:
   npc_vnum: 3001
   price_index: 0
   prices:
    - price_type: ITEM
      price_cost: 30014
      price_count: 100
  3001_2:
   npc_vnum: 3001
   price_index: 1
   prices:
    - price_type: ITEM
      price_cost: 30048
      price_count: 100 
  3001_3:
   npc_vnum: 3001
   price_index: 2
   prices:
    - price_type: ITEM
      price_cost: 30049
      price_count: 100 

• For every item you can set:
  • npc_vnum: the npc vnum you set in the database (in the vnum column, not npc_vnum column)
  • price_index: basically a "symbolic" index, in case you want to set up the same item in the shop but with a different price (and you'd set up the index in shop_item to specify the price wanted)
  • prices: here you will set up the list of prices. price_count it's the cost for the ITEM price_type, usually just set it to 1.
• Video of the final result:
• In the video the items stack as soon as you buy them from the shop. That is not a feature of the system (it requires a refactor in the item/inventory class). If wanted, that's an additional 500€
• I momentarily disabled the behavior with the tabs (I've never used them, so I'll have to see how to handle them. For now, it's not a priority).

•  This system replaces the old "in game settings" code (and others, if available, like the shining system)
• Every option is encapsulated in a json structure (both on the server, as a master, and in the launcher). Ex:

  {
  			"general": {
  				"name_color": "normal",
  				"target_menu": "show",
  				"chat_lines": "show",
  				"char_names": "always",
  				"monster_level": "show",
  				"damage": "show",
  				"day_light": true,
  				"aestethic_effects": true,
  				"models_visibility": {
  					"pet": true,
  					"mount": true,
  					"shops": true
  				}
  			}
  		}

   

• The utility of the system, aside of easier managament of all this stuff, is that the players will keep all their settings saved, even when using a totally different computer.
•  

• With this system the description of the abilities is completely customizable.
• You can choose the colour based on the type of dmg, or type of buff/debuff.
• Local variables.
• Flexible and intuitive grammar.
• Multiple infos possible to show in game, like range, number of targets etc.
• If needed, I can help with the introduction of new abilities or changing the old ones.
• Example of Dispel: 

  {
  	"vnum": 66,
  	"name": "Annullare la Magia",
  	"description": "Magia che rimuove completamente le abilità di potenziamento avversarie. | Infligge |cFF357CA9$val|r danni puri. | Ha il |cFF2DFE03$removeaffpct%|r di |cFF03C5FEAnnullare la Magia|r per |cFFC7D610$bapeoptime secondi.|r | L'abilità viene influenzata da: | -|cFFECE185Livello dell'Abilità|r | -|cFFECE185Attacco Magico|r | Numero di Bersagli:|cFF00CB8D1|r | Nemici massimi colpiti vicini al Bersaglio:|cFF00CB8D4 (Danno ridotto del 40%)|r",
  	"polyMap": [{
  			"key": "$val",
  			"poly": "0.63*TotalMagicAtk+0.62*TotalMagicAtk*k"
  		},
  		{
  			"key": "$removeaffpct",
  			"poly": "20+40*k"
  		},
  		{
  			"key": "$bapeoptime",
  			"poly": "5+24*k"
  		}
  	]
  },

   

• How it's shown in game:
• The | indicates a new line. |cCOLOR|r to change the color of the text, and $variable_name shows the value you put in polyMap for that name

• Only two players per PC can drop, others are blocked (number of max players that can drop is customizable).
• Possibility to switch characters that are able to drop
• The system can be done for other stuff (for example, we had an autofishing system, and we made it available for 1 character per PC only)
• Delay of 15 minutes between swaps (customizable)
• lua command to check if someone/in party can drop
• compatible with dice system
• [800€ It includes our UniqueID system]Possibility to block dungeon's access to other players in the same PC. Let's say you want maximum two characters. First and second will finish a dungeon, a third character will have the cooldown of the first one. Compatible with the Dungeon Info. This type of cool down can be expanded for other stuff (we have a daily tasks system where, per PC, you can only complete 6 in total, all in LUA)

• With this system you can give a maximum duration of every kind of item in the game (promotional items, prizes etc.). For example, you can create a lv.1 Sword with 500 attack bonus that expires in 7 days (REAL TIME)
• I had already been able to set up the system in Ikarus' offline shop. For other kinds of offline shops, I'll need a bit more time to see how they work with the items' expiration.

• This system enables the possibility to send to the client the infos of a server_timer. This way a player, for example in a dungeon, can always have the remaining time of the dungeon in plain sight.
• Super easy to add in your quests:

  d.set_fake_clock("deviltower_clock",locale.deviltower.clock,60*60)

  where "deviltower_clock" is a UNIQUE string identifier (you can send multiple timers, and the string is used as an id), and locale.deviltower.clock is the name that will be shown clientisde of the timer (you still have to set the server timer, this does not replace that part).

• It is possible to see it in the Arena PvP System's video

• The damage calculation has been rewritten and completely cleaned. Attack and Defense will be simple points instead of being fully calculated every time battle_hit/damage is called. Ex in battle_hit (no Attack Rating version):

  	// calculate melee damage flat
  	int iPhysicalDam = pkAttacker->GetPoint(POINT_TOTAL_PHYS_ATT);
  	// then apply percentage modifiers
  	NormalAttackAffect(pkAttacker, pkVictim);
  	int iVictimPhysicalDef = pkVictim->GetPoint(POINT_TOTAL_PHYS_DEF);
  	iVictimPhysicalDef = PhysicalDefensePenetrationFactor(pkVictim, pkAttacker, iVictimPhysicalDef);
  	// then substract defense flat
  	iPhysicalDam -= iVictimPhysicalDef;
  
  	if(iPhysicalDam <= 0)
  		iPhysicalDam = number(1,3);

• Possibility to choose the order of the damage. For example, the physical attack given by Aura of the Sword calculated before or after some other variable:

  		//let's find the additional points that add flat value to the physical attack
  		iPhysicalAttack += GetPoint(POINT_PHYS_ATT_BONUS); //APPLY_PHYS_ATT_BONUS
  		iPhysicalAttack += GetPoint(POINT_PARTY_PHYATTK_BONUS); //BONUS FROM PARTY
  		//let's find the additional points that add % value to the physical attack
  		iPhysicalAttack = (int) (iPhysicalAttack * (100 + GetPoint(POINT_MELEE_MAGIC_ATT_BONUS_PER)) / 100); //BONUS FROM MELEE / MAGIC % BONUS
  		//Then we store this physical attack as the "clean" one, base + item + bonuses
  		PointChange(POINT_PHYS_ATT_BONUS_CLEAN, iPhysicalAttack, false, false, bBroadcastPointsPakcet, false); //fix double melee/magic atk
  		//let's add the bonuses from skill affects:
  		iPhysicalAttack += GetPoint(POINT_AURA_PHYS_ATT_BONUS); //AURA SKILL -> let's say we put this after POINT_PARTY_PHYATTK_BONUS
  		//in that case the MELEE / MAGIC % BONUS will take into account the bonus from Aura, otherwise Aura is added AFTER the % calculation 
  		iPhysicalAttack += GetPoint(POINT_SOOTHINGATTACK_PHYS_ATT_BONUS); //SOOTHING ATTACK SKILL
  		iPhysicalAttack += GetPoint(POINT_MAGICBLADE_PHYS_ATT_BONUS); //MAGIC BLADE SKILL
  		//Then we store this physical attack as the complete one, base + item + bonuses + skills
  		PointChange(POINT_TOTAL_PHYS_ATT, iPhysicalAttack, false, false, bBroadcastPointsPakcet, false);

• Unlocking of Magic Attack/Defense (optional but it's on the files server, the value0 of armor items, if I recall correctly).
• Way way way less lag when damage and affects are calculated.
• Possibility to choose to maintain the randomness of the damage or not.

• This system provides a refactor and expansion of the skill_proto
• You would have FULL POWERS to do any kind of ability you have in mind, both for players and monsters (ex: a boss that dispels or that buffs itself)
• Specifics of the ability are all editable with a json structure
• Example of a json for an ability of a boss that deals magic damage, always pushes the enemy (you) and buffs its magic attack for 20 seconds:

  {
  	"nodes": [{
  		"type": "DAMAGE",
  		"amountPoly": "5*k*matk",
  		"damageType": "MAGIC",
  		"flag": "ENEMYONLY",
  		"splash": {
  			"maxTarget": 4,
  			"splashRange": 600
  		},
  		"nodes": [{
  				"type": "CRUSH",
  				"amountPoly":	"200"
  			}]
  	},
  	{
  		"type":	"AFFECT",
  		"flag": "COMPUTE_SELF",
  		"point": "SKILL_SPACEBOSS_MAGIC_ATT_BONUS",
  		"amountPoly": "40*k+150",
  		"durationPoly": "20"			
  	}]
  }

• SKILL_SPACEBOSS_MAGIC_ATT_BONUS is just a new point that adds magic attack to a character (in this case, npc only)
• Yes, party buffs are available (simple flag to apply to the skill in the json structure)
• The old and new skill_proto columns, in order:
  • dwVnum: skill's vnum
  • szName: skill's name
  • eSkillType: CLASS/HORSE/SUPPORT/GUILD
  • bMaxLevel: max level of the skill (usually 40 -> P)
  • bLevelStep: just 1
  • bLevelLimit: minimum level to use the skill
  • prerequisiteSkillVnum: skill's vnum that's checked to see if the skill that you are trying to level up is at the right level
  • prerequisiteSkillLevel: skill's level to check for the skill that you are trying to level up (let's say prerequisiteSkillVnum: 3 and prerequisiteSkillLevel: 20 at row 2. This means Berserk needs to be level 20, M1, for Sword Spin to be levelled up).
  • szCooldownPoly: cooldown formula
  • szCostType: cost of the skill (SP/HP/GUILD_SP)
  • szFlag: flag of the skill (generally, for damage it's ENEMYONLY|CLIENT_HIT, SELF buffs SELFONLY, general buffs ALLYONLY)
  • dwTargetRange: maximum distance from where you can cast the ability and do damage (ex: Sword Spin is 400, Spirit Strike 470)
  • dwUseTimeout: 2500
  • szMaxHit: how many hits the skill has (Three-Way Cut for example has.. well, three max hits)
  • szMaxTarget: self explanatory, except for abilities with splash damage, they have 1 max target, then the splash damage will take care of the others
  • jEffect: where the magic happens (and the json is pasted)
• Two new skill effects:
  • PULL, probably the most broken stuff we've ever designed for metin. Basically you can pull x enemies to the target selected. You can set min/max distance, max number of targets, all as CPoly, so you can use the usual formulas:

    	typedef struct SPull : public TNodeBase, public TNodeWithChildren {
    		SPull() : TNodeBase(), TNodeWithChildren(){}
    		~SPull(){};
    		CPoly								kAmountPolyLength;		//Pull Length
    		CPoly								kAmountPolyMinDist;		//Max distance that someone can pull from
    		CPoly								kAmountPolyMaxDist;		//Minimum distance that someone can pull from
    		CPoly								kAmountPolyMaxHit;		//Max Players to pull
    	} TPull;

  • CURSE, a very particular effect. The caster hits the target with a spell. This spell will last x seconds. During that time, the damage done by the victim is registered. When the spell ends, the victim takes a percentage of the damage he dealt:

    	typedef struct SCurse : public TNodeBase {
    		SCurse() : TNodeBase(), unAff(0), unAffect(0) {}
    		~SCurse() {};
    		CPoly				kAmountPoly;				//Amount of damage taken at the end of the curse based on the damage dealt by the cursed
    		CPoly				kDurationPoly;				//Duration of the curse
    		unsigned int		unAff;						//Aff associated
    		unsigned int		unAffect;					//If not 0 specifies the vnum of the affect, the vnum of the skill will be used otherwise
    	} TCurse;

• Video example:
• TO DO WIP:
  • Splash logic refactor
  • Documentation (terribly needed unless you are a developer and understands what to write in the json structures)
  • SQL base file (since we changed some abilities, we need to revert them back to what they were before)

• You can create a season for every kind of system with a ranking.
• You can choose start and end of season.
• You can choose if the seasons can be cycled and be the same, or have a pause etc.

• The "window"s of every interface will be of PeekWindow type. You define how big is the rendering square, and all the childrens (even other peekwindows) will be hidden outside of that range, rendering a more natural and smooth scrolling
• All your current and future interfaces will be refactored to accommodate the new Window type (this is going to take a bit of time for the first time)