Ind

the movenpc command for some reason is restricted to the same map the npc is in o__O hu well its sort of late for me D:~ i'll think of something as i sleep +__+

indeed o-o will move it to feedback forum

i think i thought of some lazy but fast way to go around the issue o-o moving the chat rooms source npc quickly to the players sight, open the chatroom and move it back to its original location D: would that be acceptable?

aaaah i see why ._. well this just got complicated Xd would need to make the command spawn a fake chatroom in player sight in order for it to be fully functional and doing that is quite troublesome :| mhmm

ahh in chat.c find if( cd == NULL || cd->bl.type != BL_CHAT || cd->bl.m != sd->bl.m || sd->state.vending || sd->state.buyingstore || sd->chatID || ((cd->owner->type == BL_NPC) ? cd->users+1 : cd->users) >= cd->limit ) { clif->joinchatfail(sd,0); return 0; }replace with if( cd == NULL || cd->bl.type != BL_CHAT || sd->state.vending || sd->state.buyingstore || sd->chatID || ((cd->owner->type == BL_NPC) ? cd->users+1 : cd->users) >= cd->limit ) { clif->joinchatfail(sd,0); return 0; }

uhm BUILDIN_DEF(joinwaitingroom,"?"),should work o-o i think

any o-o you can create a new one and input that code or throw it into a existent

yes totally possible o-o like uh i'll show a example editing a existent command oo (didnt test btw) BUILDIN_FUNC(delwaitingroom){ struct npc_data* nd; if( script_hasdata(st,2) ) nd = npc_name2id(script_getstr(st, 2)); else nd = (struct npc_data *)map_id2bl(st->oid); if( nd != NULL ) chat_deletenpcchat(nd); return 0;}toBUILDIN_FUNC(delwaitingroom){ struct npc_data* nd;TBL_PC *sd = script_rid2sd(st); if( script_hasdata(st,2) ) /* string is npc name that holds the chat */ nd = npc_name2id(script_getstr(st, 2)); else /* assume the chat room is in this invoking npc */ nd = (struct npc_data *)map_id2bl(st->oid); if( nd != NULL && nd->chat_id ) {chat_joinchat(sd, nd->chat_id, NULL);} return 0;}let me know if you have any problems o:

[01:12:44] <~Ind> oh crap[01:12:52] <~Ind> i accidentally forgot a debug command in the release[01:12:53] <~Ind> [01:13:10] <~Ind> someone who noticed pmed me saying they liked it :|[01:16:22] <Streusel> wat[01:16:30] <Streusel> they liked that you forgot it?[01:16:31] <Streusel> o-o[01:16:44] <Streusel> have to wait till monday for my server to be setup[01:16:47] <~Ind> they liked the command :|[01:16:48] <Streusel> but it's prply tuesday[01:16:49] <~Ind> he*[01:16:51] <Streusel> ahh[01:16:58] <Streusel> cry, so long to wait[01:17:05] <~Ind> i did a @fontcolor to debug the color stuff during tests[01:17:07] <~Ind> and forgot to remove[01:17:21] <~Ind> it works like @font but it changes your global message color[01:19:07] <Streusel> ><[01:19:24] <Streusel> funneh[01:19:25] <Streusel> xD[01:19:57] <~Ind> he said he found it cool |: i wonder if its of any use o_O[01:20:10] <Streusel> new name and leave it?[01:20:13] <Streusel> why not!~[01:20:18] <~Ind> why new name[01:20:25] <Streusel> mm globalfont[01:20:27] <Streusel> fontg[01:20:36] <Streusel> fontcolor is so.. general[01:20:43] <Streusel> not saying what for[01:20:51] <Streusel> no?[01:21:05] <~Ind> o-o[01:27:07] <~Ind> well see o: i'll make a topic to discuss thisit does like the screen attached :< well i didnt really think about this at the time i made it, talked to a couple people so far and they think its useful o.o do we take it away or keep it?

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)

hum o-o try a 'make clean && make' i'd guess they're out of sync

I expressed myself poorly D: I mean save somewhere? call a npc event? ...?

and that brings me to updating that conf description since item_noequip.txt was removed .-.

yes it is official behavior, you can disable in conf/battle/items.conf // Will disabled consumables (disabled by item_noequip.txt) be consumed when trying to use them?// 1 (official): yes// 0: noitem_restricted_consumption_type:1

oki researched further o: even kro main client doesn't support this, its available on certain region-clients only :<

So you think the client no longer recognises these stuff as "hi you have a cart and this is its data"? if(pc_iscarton(sd)) { clif_cartlist(sd); clif_updatestatus(sd,SP_CARTINFO); }

both server and client i thought of something, perhaps for vendings to be allowed the client now requires a specific map type to be sent by the server? /// Set the map type (ZC_NOTIFY_MAPPROPERTY2)./// 01d6 <type>.Wvoid clif_map_type(struct map_session_data* sd, enum map_type type){ int fd; nullpo_retv(sd); fd=sd->fd; WFIFOHEAD(fd,packet_len(0x1D6)); WFIFOW(fd,0)=0x1D6; WFIFOW(fd,2)=type; WFIFOSET(fd,packet_len(0x1D6));} enum map_type { // clif_map_type MAPTYPE_VILLAGE = 0, MAPTYPE_VILLAGE_IN = 1, MAPTYPE_FIELD = 2, MAPTYPE_DUNGEON = 3, MAPTYPE_ARENA = 4, MAPTYPE_PENALTY_FREEPKZONE = 5, MAPTYPE_NOPENALTY_FREEPKZONE = 6, MAPTYPE_EVENT_GUILDWAR = 7, MAPTYPE_AGIT = 8, MAPTYPE_DUNGEON2 = 9, MAPTYPE_DUNGEON3 = 10, MAPTYPE_PKSERVER = 11, MAPTYPE_PVPSERVER = 12, MAPTYPE_DENYSKILL = 13, MAPTYPE_TURBOTRACK = 14, MAPTYPE_JAIL = 15, MAPTYPE_MONSTERTRACK = 16, MAPTYPE_PORINGBATTLE = 17, MAPTYPE_AGIT_SIEGEV15 = 18, MAPTYPE_BATTLEFIELD = 19, MAPTYPE_PVP_TOURNAMENT = 20, //Map types 21 - 24 not used. MAPTYPE_SIEGE_LOWLEVEL = 25, //Map types 26 - 28 remains opens for future types. MAPTYPE_UNUSED = 29,};

is it a mapflag or they added a new cell type that blocks vending stuff?

well pretty much you'd need to send that data through a different packet and, on map-server end where it receives such data, you append it to mmo_charstatus. This has been a common occurrence since eathena when people increased their normal storage sizes, I think I'll consider this a bug and commit a fix to send storage data separately

Very good. Ind I missed these skills do not seem to be added in the new model, txt format looks very old would it not be better to do in conf? 3013,3 //KO_KYOUGAKU//Clone Forbidden/pointless skills77,16 //PR_TURNUNDEAD79,16 //PR_MAGNUS There we go: https://github.com/HerculesWS/Hercules/commit/cfd2bdb06048c17decaafd0f5a3c04e3f0ac6a3b By the way the 3013,3 //KO_KYOUGAKUwas a flag used to normal and pvp maps, it is present in the map_zone_db.txt

we'll be adding 2013 main-client support to the repo once its support is complete

yup with clients like this http://herc.ws/board/topic/289-2013-ragexe-area/ it should be possible to implement it

ooo really nice, I personally like it

if you mean that your sizeof(struct mmo_charstatus) is higher than USHORT_MAX (65kb) its sort of problematic to increase .-. well you'd need to split the packet in char server to send mmo_charstatus split in multiple parts since you can't add more than 65kb to a single packet

last i tried to implement this I found the feature to be only available in main client (not the sakray-type ones hercules and other emus use)