Lighta

Well you don't have map_session_data at this point so you'll need to send it as parameter, but that possible since we don't use that function in many place. You'll need to take it off msg_conf cause that in common atm and shouldn't know about sd. Historical reason was that I was tempted to just do return msg_txt(number); cause afterall if we already have the langange you could have skip the switch. but the fallback will break this as well as show the enabled langage. (just in case someone would be tempted) Malasian is in lighta talk.

He would need to accept the invitation with guild_invite wich I believe he didn't want to give the choice.

"Other than english ^^" It's a bitmask we use that type of configuration on lot of other conf....anyway: LANG_RUS = 0x01, LANG_SPN = 0x02, LANG_GRM = 0x04, LANG_CHN = 0x08, LANG_MAL = 0x10, LANG_IDN = 0x20, LANG_FRN = 0x40, 1st) you can't disable english it's extra lang you add by enable them or not. (We could change default english but it's not supported) so here few example of how it work : #define LANG_ENABLE 0x00 //english only #define LANG_ENABLE 0x01 //english + russian #define LANG_ENABLE 0x03 //english + russian + spanish #define LANG_ENABLE 0x43 //english + russian + spanish + french #define LANG_ENABLE 0x10 //english + malansian So basically take LANG_ENABLE and add the value you want enable on it.

Either increase in src/map/itemdb.h #define MAX_RANDITEM 11000 or do new group right now this mean the extra item ain't added in your group.

@melv0 Euphy did a bit paragraph on it did you read ? anyway in src/common/msg_conf.h #define LANG_ENABLE 0x00 => #define LANG_ENABLE 0x20 "msg_txt(sd,6));" New function indeed pass sd (a map_session_data) but if you don't have one available in your function and can cast it, you still can use NULL instead and default langage will be used (English). "msg_txt(NULL,6));" => will display in English. Which is still the case for few msg_txt atm.

if you want to add a status to a attack that go trought put it in skill_additional_effet, this would be trigger only if dmg>0. But your starting condition is quite big not sure that really what you wanna do.

in src/map/guild.h add the following: void guild_makemember(struct guild_member *m,struct map_session_data *sd); (you can put it like juste after guild_guildaura_refresh). Ye sorry for this kind of help I would give you a proper diff normally but didn't have clean version to spare =(

idepend on your ra version, if its, after r17151 (multimsg) change (wich look the case here) msg_txt(81) to msg_txt(sd,81)

I didn't try it yet, that was just what I'd have try if I was doing the command. the warnings are just some variable that we don't use anymore. You didn't have error on console ? just converting should give something like : int atcommand_joinguild(const int fd, struct map_session_data* sd, const char* command, const char* message) { struct map_session_data *pl_sd; struct guild *g; int guild_id_; struct guild_member m; nullpo_retr(-1, sd); memset(atcmd_output, '\0', sizeof(atcmd_output)); memset(atcmd_player_name, '\0', sizeof(atcmd_player_name)); sscanf(message, "%i,%23[^\n]", &guild_id_,atcmd_player_name); if (!message || !*message || !guild_id_ || !atcmd_player_name) { clif_displaymessage(fd, "Error. (usage: @joinguild <guild id>,<char name>)."); return -1; } if ((pl_sd = map_nick2sd(atcmd_player_name)) == NULL) { clif_displaymessage(fd, msg_txt(3)); return -1; } if (pc_get_group_level(sd) < pc_get_group_level(pl_sd) ) { clif_displaymessage(fd, msg_txt(81)); return -1; } if ((g = guild_search(pl_sd->status.guild_id))!= NULL) { clif_displaymessage(fd, "Target player appears to already be in a guild."); return -1; } guild_makemember(&m,pl_sd); //This is line 7631 pl_sd->guild_invite = guild_id_; intif_guild_addmember(pl_sd->guild_invite, &m ); clif_displaymessage(fd, "Player has joined selected guild."); return 0; }

sorry been a while but that log function was introduce by Lemon in r17142, so here you go you can now see if he receive the cash and or points correctly in cash_log table.

this will work on rA with few work, 1) change pc_isGM(sd) for something like pc_has_permission and create a force guildjoin permission, or if you want to stick with lvl change it to pc_get_group_level(sd). (that will compare both group lvl) 2) add: pl_sd->guild_invite_account = sd->bl.id; nb : I would have use guild_reply_invite(pl_sd,guild_id,1); rather but it's ok how you did it too. int atcommand_joinguild(const int fd, struct map_session_data* sd, const char* command, const char* message) { struct map_session_data *pl_sd; struct guild *g; int guild_id_; struct guild_member m; nullpo_retr(-1, sd); memset(atcmd_output, '\0', sizeof(atcmd_output)); memset(atcmd_player_name, '\0', sizeof(atcmd_player_name)); sscanf(message, "%i,%23[^\n]", &guild_id_,atcmd_player_name); if (!message || !*message || !guild_id_ || !atcmd_player_name) { clif_displaymessage(fd, "Error. (usage: @joinguild <guild id>,<char name>)."); return -1; } if ((pl_sd = map_nick2sd(atcmd_player_name)) == NULL) { clif_displaymessage(fd, msg_txt(3)); return -1; } if (pc_get_group_level(sd) < pc_get_group_level(pl_sd) ) { clif_displaymessage(fd, msg_txt(81)); return -1; } pl_sd->guild_invite = guild_id_; pl_sd->guild_invite_account = sd->bl.id; guild_reply_invite(pl_sd,guild_id_,1); clif_displaymessage(fd, "Player has joined selected guild."); return 0; }

implemented in r17251 don't have russian support to read file so couldn't add it, sorry about that

oh non pas des accents ! lol Je n'aime pas trop : 1119 Vous êtes monté sur votre Dragon. => "Vous montez désormais votre Dragon" fin les "Vous êtes monté" c'est trop lourd je trouve. 1139 Vous n'êtes pas emprisonné => meme chose bref le passé composé c'est moche 1306: Retourné à l'état normal. => Retour à l'état normal La plupart sont des messages d'état, de feedback pour dire que tel actions est effectué donc pas vraiment besoin de la mettre dans le passé qui fait juste alourdir. ====== Just a few notes on the translation saying some sentence even if ok and correctly translated was too bold. nb : import: conf/import/msg_conf.txt should point to conf/import/msg_frn_conf.txt cause right now all translation point to the same import file wich gonna be a big mess.

<p>i've work on it today with what Lilith have done I now need the missing translation for the langage.</p> <p>here the current avancement :</p> <p> </p> <p>enable/disable langage => ok</p> <p>map multi msg => ok</p> <p>import "foo" => ok</p> <p>fallback lang not enable => ok</p> <p>fallback lang return ?? => ok</p> <p> </p> <p>@langtype => ok</p> <p>check enable/disable => ok</p> <p>account wide ? => ok</p> <p>kept in deco/reco => ok</p> <p>reset to default if langtype disable => ok</p> <p>available in charserv => impl not tested</p> <p>available in logserv => impl not tested</p> <p> </p> <p>@reloadmsgconf => ok</p> <p>rerad import as well ? => ok</p> <p>reload charmsg => not impl yet</p> <p>reload loginmsg => not impl (needed ?)<br /> <br /> Just need some optimisation and eventually some cleaning but it's probably ready for a beta release. Waiting Lilith opinion.</p>

yes jAbote this could be done as well. would be direct for map but probably require a packet for char and log to keep them independant. kinda thinking about how to store msg efficiently atm.

hmm applying zone is higher in cpu since the other one it's just a attribute assignement difficult to do less then that. But zone give the advantage to have all info in a same db like I said, right now info are kinda in all place and you don't really know that much what flag are on each map unless @mapinfo (wich imo should be updated to display all mapflag) Also you can inherit a zone wich is like copy those mapflag assign and add this.. that could be sweet. But what I really dislike it's that atm it bring confusion since you have mapflag and zone wich bring almost the same functionnality, so you dunno wich is what. In other hand that zone for final user is't a good way to define easily mapflag. I mean right now with our current system you could do this with restricted adding a new zone and then have item and skill blocked by default; but if you want for say that zone3 also block mail you'll need to do src edit. if(restricted&3) blabla; or add a new mapflag. With that zone thing you could simple add a new zone in the group and assign blocked functionnality. Dunno if you follow ? In short will have less src edit to add new "mapflag"; since they're just new zone.

Here the current mapzone merge from Hercules : http://pastebin.com/cUJL5PqC I didn't test it all and will probably take a long time to do all, so this are the current issues : - @gvgon/off @pvpon/off won't change the zone - @mapflag can't set zone atm like he use to with restricted But if we do that those refresh it is there really a difference between mapflag and zone ? I mean that look pretty much the same except one is on one file and could benefit heritage and could easier presentation. (yes could figure out restricted&2 = pvp not that obvious) but beside inherit it's pretty much the same. So idk, imo I think all mapflag should disapear to become zone and only deal with them but not have both simultaniously since it's bring useless complexion, please tell me what you think I'll talk to it on hercules too I think. Well I suppose we could say a zone regroup multiple map while mapflag is more for one but idk, like mapflag Town and zone Town as well kinda disturb me. add an acmd to test it: http://upaste.me/479f5591f180fd1a

that bug is already reported, fix wont be long please follow here : http://rathena.org/board/tracker/issue-7458-status-change-timer-error-%EC%8A%A4%ED%85%8C%EC%9D%B4%EC%8A%A4%ED%84%B0%EC%8A%A4-%ED%83%80%EC%9D%B4%EB%A8%B8-%EC%97%90%EB%9F%AC/

Does your guildman were in same party ? if so that would take precedence over doing guild ennemy.

didn't start yet, was still attempting to finish something else.

1. Guildsman cant attack each other you need to turn off : pvp_y_1-1 mapflag pvp_noguild 2. Pots are via mapflag disabled but also can used. you put the wrong zone, you need to do "501,64 // Red Potion" and so on, zone 2 = 64 // format: <item id>,<mode> // mode // 1 - restricted in normal maps // 2 - restricted in PVP // 4 - restricted in GVG // 8 - restricted in Battlegrounds // Restricted zones - they're configured by 'restricted <number>' mapflag // 32 - restricted in zone 1 // 64 - restricted in zone 2

@frenzmu06, no since that is just for one command only but the issues might be repeated for other charcommand, so if dev focus on this we need to have a more generique approch. Still that kinda highlight the need of gm to have the result as well for charcommand. @Gnome that was 3 different solution, choose one and I might do a tmp patch if I have time : -1) do you mind having result widely show to nearby client ? -2) do you want change atcommand to support nickname and being use as atcommand (so charcommand will be kinda useless then) ? -3) do you want log and check the result in sql ? I think sol3 doesn't give feedback fast enough and sol1 not that perfect for privacy but kinda the easiest.

For a wide solution for all #command that quite an issue since we don't usually return different values as result of function but just ask clif. But maybe we could do it via fd. Anyway more more hacky/function specific you could change : clif_disp_onlyself(sd, output, strlen(output)); to something like clif_GlobalMessage(sd->bl,output); wich will then display the result on player as a globalchat message so if you in range you could see it. (and all nearby client) or you could rewritte function to take a nickname as parameter like this: if(!message || !*message || sscanf(message, "%d %s", &value, nickname) < 1)... then map nickname to an session data, tsd=map_nick2sd(nickname); change command to effectuate on tsd then you can now display result on sd and tsd. (usage is then @cash 100 lighta) will give 100 point to lighta), ofc if no nickname found do something like tsd=sd so it will be on self amd there you go. or you could do some logs.

overwritting is server wide. actually I just think a bit more we won't even need to deal with folder, since supported filename will be hardcoded, I mean like MSG_CONF_NAME_EN = "conf/msg_conf/map_msg_en.conf"; MSG_CONF_NAME_BR = "conf/msg_conf/map_msg_br.conf"; etc, unless we make list in a file later. Anyway that why the bitmask to select wich multilang you wanna load is important, cause I doubt many will want to have en+br+mal+fr+esp+.... Currently yes we read all servers read file at begining and store them into char table, then we simply return those stored value in runtime. (look do_init ) But hmm yeah we could also move the load when a new sd->lang is defined, that would probably be best for ram and I think reading it shouldn't be too cpu extensive. But hmm I'd think we should focus on static first before then perhaps extends to that malloc possibility. (we probably need to add somes timer with it, (too not load and unload too much)). Otherwise for the sd->lang treatement, well we not necessarly need to treat them in common, more that I think about it login won't be multitable but just with the default one they wished (like an actual import). Char idk yet, need to be carefull with jobname since they repeated in map, idk what mistmatch will do yet, auction is ok since it's just some mail confirmation. But in short you could point to correct table in each server msg_txt redefinition like :map_msg_txt() wich probably be easier to deal with then the final _msg_txt(). There a small function like that for each server that point to the common one wich give as argument tell which table to use at wich index. Only annoying point is the fallback will be less effective but well shouldn't happen anyway. (maybe I'll add a bug ShowDebug to ask admin to add translation when fallback happen haha).

yes Cydh I was thinking to keep the overwritting, but yeah that pose the issue case : do we overwritte now or do we do a new table ? I think we could define like in msg_conf folder he create new table and in import he will overwritte.