Eurydice

We'll be starting our Monthly Digests so that we can keep our community informed on whats going on with Hercules!
 
 
March Digest 2013
The following digest covers the month of March 1st - March 31st 2013.
 
Team Addition
[*]Wolf has joined as a Portuguese Moderator.

Development Highlights
[*]Hercules' Channel System (7ec1e8f) [*]Re-Introduction of ERS Report (646f978) [*]Garment Costume System (9aded8a) [*]Slot Change Feature (889a866) [*]Hercules' Map Zone Database (90f117f) [*]Re-introduction of Console Input (3b89a13) [*]Dropping of StatusChangeStateTable (70a3d73) [*]Hercules' Renewal Pincode System (d2d734c) [*]Follow Up: 84e8f18, f214021, 5b1fee9
[*]Introduction of Account-Dependent Character Slot Count (0241d01) [*]On-Going process of Hercules Renewal (Topic)


Command Additions / Updates
[*]Added 'itemeffect' script command (c58f741) [*]AccountInfo command updated to work with Pincode (9b5ec24)

Statistics
[*]During the period there were 62 commits. [*]Of these 62 commits 15 included bug-fixes. [*]1 Commit from Pull Request [*]In this month, there were 21,330 Additions and 16,692 Deletions. [*]February's Statistics: [*]- 112 Total Commits (merges not included) [*]- 29 Bug Fixes [*]- 21 Commits from Pull Requests

Introducing Hercules' Channel System
Hello~! - What?!
1st, it is a replacement for the old @main 2nd, it is a super ultra mega improvement compared to the functionality @main provided. 3rd, whops. there is no 3rd. channels.conf format
    /* default channels (available on boot) */     default_channels: {         /* channel_name : channel_messages_color */          main: "Orange" /* available as #main */         support: "Blue" /* available as #support */         trade: "Red" /* available as #trade */         offtopic: "Cyan" /* available as #offtopic */         /* as many channels as you like */     }     /* colors available */     colors: {         Default: "0xffffff" /* custom channels will use the first in the list unless a font is selected thru @channel */         Red: "0xff0000"         Blue: "0x83cfe9"         Orange: "0xe57c00"         Cyan: "0x00b89d"         Yellow: "0xffff90"         Green: "0x28bf00"         Normal: "0x00ff00"         /* as many colors as you like */     }     /* allow users to create their own (private) channels through @channels command? */     /* (must also allow players to use @channels in groups.conf) */     allow_user_channel_creation: true     /* "map_local_channel" is a instanced channel unique to each map */     map_local_channel: true     map_local_channel_name: "map" /* available as #map */     map_local_channel_color: "Yellow"     map_local_channel_autojoin: true /* can disable autojoin in specific maps through mapflag or zone: nomapchannelautojoin */     /* "ally_channel" is a channel shared by all your guild allies */     ally_channel_enabled: true     ally_channel_name: "ally" /* available as #ally */     ally_channel_color: "Green"     ally_channel_autojoin: true Notes on the format/configuration
default_channels is the list of reboot-persistent channels, you can setup as many as you like and each can have its own color for chat, which you can specify in colors (again, you can setup as many as you like) map_local_channel is a feature that grants each map its own instanced channel (available, by default as #map -- which can be changed as per map_local_channel_name) map_local_channel_autojoin whether users will autojoin the local channel when they load a map with it enabled map_local_channel_autojoin can be disabled on selected maps (e.g. if you dont want it on gvg maps) through a mapflag (with a horribly long name D:) '<map name><tab>mapflag<tab>nomapchannelautojoin' ally_channel_enabled is a feature that grants a instanced channel for each guild's allies (as well as their own members), available by default as #ally -- which can be changed as per map_local_channel_name ally_channel_autojoin whether users will autojoin their respective ally chats upon login. New Commands Explained
@join Simple: @join <#channel_name>or, for password-protected rooms: @join <#channel_name> <password> @channel Does a number of things. Create a new channel (option available as long as allow_user_channel_creation is enabled) @channel create <#channel_name> <password> List public channels (groups with hchsys_admin can view private channels as well) @channel list Change a channel's color (requires to be owner of said channel or be in a group with hchsys_admin permission) @channel setcolor Samples available colors and displays their keys/names @channel list colors Leaves a specific channel @channel leave <#channel_name> Binds your global chat to a specific channel, making everything you type that'd normally be displayed to nearby characters be redirected to that channel instead @channel bindto <#channel_name> Unbinds your global chat from the current (if any) binded channel @channel unbind Bans a specific character from a channel @channel ban <#channel name> <character name> Lists all banned characters from a channel (groups with channel system admin permission can also see their account id) @channel banlist <#channel name> Unbans a specific character from a channel @channel unban <#channel name> <character name> Changes a channel's options (for now, channel message delay and announce-when-someone-joins) @channel setopt <#channel name> <option name> <option value> How to speak in a #channel
You can either bind a channel to your global chat (see @channel bindto above) or PM the channel you want to speak to, if you attempt to send a pm to a non-password protected channel that you have not joined, you'll autojoin. Other stuff
as I coded this feature I also improved overall guild processing/lookup, extremely, extremely faster (did I already say its ridiculously faster? WoE overhead probably more than halved with this). over a hundred lookups were replaced by a cached guild state that takes only 4~8 bytes per player. The commit also fixed a "wearing-garment-removed-costume-garment-look" bug - special thanks to jTynne for letting me know~! Groups with channel admin permission can bypass the channel message delay Special Thanks
to Streusel for proposing an idea that'd end up as the @channel bindto feature. to Frost for proposing the per-channel message delay limitation to Fatalis for proposing what'd end up as the @channel ban, @channel unban and @channel unbanall to Zopokx for proposing an improvement to how the map/local channels function Links~!
Commit Commit (update)

Introducing Hercules' Map Zone Database
Hello~! - What?!
1st, it is a merge from item_noequip.txt and skill_nocast_db.txt functionality. 2nd, it is a major improvement on what these features did in both performance and usability. map_zone_db.txt format sample
{     name: "My Zone"     inherit: ( "My Other Zone" )     disabled_skills: {         AL_HEAL: "PLAYER | MONSTER | ELEMENTAL"         AL_TELEPORT: "MONSTER"         MG_FIREBOLT: "NONE"         //MG_NAPALMBEAT: "PLAYER"         //ID11: "PLAYER"     }     disabled_items: {         Assumptio_5_Scroll: false         //Apple: true         //ID501: true     }     mapflags: (         "adjust_skill_damage    MG_FIREBOLT    250",         "adjust_unit_duration    PR_SANCTUARY    50"     )     /* "command:min-group-lv-to-override" e.g. "heal: 70" */     disabled_commands: {         //Example Below makes @heal be used in maps within this zone only by those group lv 70 and above         //heal: 70     }     skill_damage_cap: {         //Exemple Below caps firebolt damage in maps within this zone to a maximum 50 damage,         // (depends on HMAP_ZONE_DAMAGE_CAP_TYPE in src/config/core.h)         // when cast vs players and monsters.         //MG_COLDBOLT: (50,"PLAYER | MONSTER")     } } Notes on the format
In disabled_skills the var following the name (: "PLAYER | MONSTER | HOMUN | MERCENARY | ELEMENTAL | PET | CLONE | MOB_BOSS") is what allows a zone to know what unit types should have this skill disabled. In the sample above, for example, in My Zone, player, monster and elemental unit types are unable to cast heal, while only monsters are unable to cast teleport. this variable may also be used to ignore skills from inheritance, for example if My Other Zone disabled a number of skills, including MG_FIREBOLT, in My Zone all of them will be disabled as well, except for MG_FIREBOLT since it is set as NONE. In disabled_items the var following the name (: true or : false) is what allows a zone to override what it inherited, for example if My Other Zone disables a number of items, including Assumptio_5_Scroll, in My Zone all of them will be disabled as well, except Assumptio_5_Scroll since it is as false. A zone may enforce an unlimited number of mapflags on all its maps, by using this sample all maps under My Zone will have Fire Bolt damage increased by 2.5x and Sanctuary will have its duration halved. A unlimited number of maps may be linked to a specific zone through a mapflag '<map name><tab>mapflag<tab>zone<tab><zone name>' Changes The mf_restrict (restrict) was dropped. item_noequip.txt and skill_nocast_db.txt were dropped, replaced by map_zone_db.txt. setmapflag script command was modified to support the new zones. @mapinfo was modified to support the new zones, also modified the formatting and made it include the amount of vendings. Improvements As opposed to item_noequip.txt and skill_nocast_db.txt, map_zone_db.txt supports an unlimited number of zones. map_zone_db.txt implementation surpasses the ones from item_noequip.txt and skill_nocast_db.txt, making item equipping (pc_useitem/status_calc_pc) and skill using (previously skillnotok, now status_check_skilluse) processing much faster and efficient. @mapinfo performance was improved (was doing chat room dbmap lookups without even checking if player was on the map in question) Special Thanks to Muad_Dib <3. to lighta for discussing the feature with me and helping design the unit-based restrictions on skills to Bahmut and Emistry for ideas on how to format the file. to kyeme for feature ideas. Links~! Commit Commit 2 (update) Map Zone Database File

Starting today we'll be going throughout all of our source code to modify how functions are called. so what?
Benefit
With this new implementation chances to have custom source modifications conflict when you update hercules will be drastically reduced. How? Instead of modifying existing functions users will be able to create a new version of them elsewhere, e.g. in a custom file, and have it replace the original one. How? very simple.
battle->check_target = my_new_check_target_function; PluginsThis change opens the possibility for a new plugin implementation in the future.
Project Vision
We understand this move will conflict with some points in our project vision, we'll be modifying it soon.
More
We want Hercules to stand out, with that in mind we've been planning features exclusive to Hercules, features other projects won't be able to merge. And how is that even possible? features that will integrate with our forum is one example of them. For example a feature capable of automatically looking for new updates in scripts/modifications downloaded from our upcoming downloads section.