Lighta

It would be better to use checkweight for this but yeah checkweight wont check if you have more then 50% of weight but just if with the news items you'll be overweight. right now you may have some issue : - you checking if you are at 50% but not the itemweight nor the quantity : let say my maxweight = 1000 I'm at 300 (30%); my itemweight is = 10; by using your script I could have items but if I try to have more the 7 I,d be overweight wich ain't check by this. gettiem,myitem,8; => boom I'm overweight item at drop on floor if possible. - you're not checking empty slot. let say your maxinventory = 100; and you have 100item on yourself. getitem,myitem,1; => boom that will fail once again if that item wasn't stackable or we didn't have this id yet into our inventory list yet. -you're not checking overamount: this case apply only stackable item. let say you already have 32K arrow. getitem,arrow,1; => boom will fail once again we already reach the max amount of this arrow we could have into our inventory. All those case are being check by checkweight and you could provide a list of argument so it stack the conditions togeter. Your 50% check right now isn't best like I demonstrate but you still could use a combinaison of checkweight and are we 50% under to have something more correct. (Even if current state taht doesn't mean after getting the item you'll still be under 50%).

yes SC_REBIRTH is currently broken, http://rathena.org/board/tracker/issue-7634-death-vs-status-effects/

check this bugreport : http://rathena.org/board/tracker/issue-7537-guild-emblem-problem-on-latest-revision/?gopid=19160#entry19160 the fix is on the clif.c changeset in r17260

still not related, try revert to r17179 the implementation of close and end ain't there and your bug still present

Brynner please stop spreading that false rumor, I told you 3 time already on each bugreport you bring this issue that it wasn't related to this. You don't believe me ? fine you can go to "src/config/secure.h" comment out //SECURE_NPCTIMEOUT recompile and try by yourself. The issue still here. or you could "svn up -r 17279 && ./configure && make clean sql", that was before any change on this. SECURE_NPCTIMEOUT was disable by default and close; end; was acting as before Your bug is really independant of this, and yes a dialogue, (a mes in script) will prevent the client to hide the menu from "select","menu","prompt" and then prevent the issue. (cause right now the client just hide that menu but we still believe we talking to the npc so we're getting stuck) but will continue that debug conversation in the specified bugreport you did.

Hey Capuche, canal translation note. (I'll writte in lighta english just so everyone could follow/input) 1438: (That info appear when player is trying to connect to chan, so idk I found the previous translation more descriptive) 1438: Vous ne pouvez pas rejoindre le canal '%s' car vous en êtes banni. (ye I know it was changed in the english one but I still prefer old one) You sometime use switch parameter name like : "1456: * %s ban <#nom_canal> <nom du personnage> 1457: -- Banni le joueur spécifié du canal." 1456 is the command, and 1457 his explanation but in cmd we say "personnage" while we use "joueur" in description I think we should use the same either "joueur" for both or "personnage", (same parameter are always use in man to not confuse user but on other way using synonym quite describe more) 1461 : -- Débanni le joueur specifié du canal => Le joueur '%s' n'est plus banni du canal '%s'. (we have player and chan name as parameter might use them) 1464: Bannissement du joueur '%s' échoué. => Bannissement du joueur '%s' impossible. (That true the command failed but in this way I think he may misslead as that command had a possibility of succes while it's ain't the case. That command will always fail on that user since he have the channel admin permission so that why I prefer "impossible" then "échoué", actually there a little chance of succes cause that will appear when user is offline too. offline or you don't have permission, so idk "Impossible de bannir le joueur '%s' car vous n'avez pas la permission requise ou le celui-ci est hors-ligne" ??) 1468: -- Débanni tous les joueurs bannis du canal spécifié. => Déban tous les joueurs bannis du canal spécifié. ("Debanni" seem weird with plural or maybe Debannissement, yeah adv woud fit) 1474: -- Joindre le canal spécifié. => Rejoindre le canal spécifié (idk I just found it more common, you met people but you rejoin a chan) that my input on r17305, thank for the translation and sorry for late feedback =)

did you tryed with a gm (like group_id 99) or someone that have PC_PERM_WARP_ANYWHERE. if so that the normal behaviour. You can bypass those mapflag for memo if you have that permission. // check mapflags if( sd->bl.m >= 0 && (map[sd->bl.m].flag.nomemo || map[sd->bl.m].flag.nowarpto) && !pc_has_permission(sd, PC_PERM_WARP_ANYWHERE) ) { clif_skill_teleportmessage(sd, 1); // "Saved point cannot be memorized." return 0; }

try this in cli : svn switch --relocate https://rathena.svn.sourceforge.net/svnroot/rathena http://svn.code.sf.net/p/rathena/svn <path_to_working_copy>

svn up && ./configure && make clean sql

when did you have this ? can you reproduce tell us how.

you right will need to change those documentation thanks to bring this up (didn't know we had that xd) acutally we probably need a file that list all mapflag and effect.

I think I'd be easier to open a collection on google-doc and enable edit to modify file there. (So we don't have to deal with n link for n langage and you can more or less compare to each other). @Leeg the blue parameter in that case is useless it was just to say pvp don't change mapflag to @go @warp those are 2 different concept, (nowarpto will also prevent emergencyrecall,@jumpto... etc so no I don't think it's a good idea) rest I like document presentation =)

some sc are timered yeah, so it's quite similar and 500ms is quite big. If you wanted to do it hp / sp based tough you could have done it in status_dammage and here you go.

line 9160 add a + between gettick() and 500 gettick()+500

@Reynard for logout yes, for logon rejoin they do except for map and ally who could be autojoined, but it could be something we work on like add favorite channel to join on relog @Greinz was this with r17285+ ? I tryed lot of case for those in the new version and it seem to work fine. please let me know. nb: as from r17285 chan system is extended and now offer the possibility of banning people and set some option on chat. (like msg_delay) tough msg_delay might be reworked in future cause it affect all chan atm.

map_flag_gvg(src->m) is a macro, that the same as : assuming src->m = m; (map[m].flag.gvg || ((agit_flag || agit2_flag) && map[m].flag.gvg_castle)) so ye you can put map_flag_tvt(src->m) if you wish but that mean you'll have to define what is map_flag_tvt, either a function or a macro. you can simply use your mapflag like this : assuming my mapflag is tvt; if(map[m].flag.tvt){ //the map m as the mapflag tvt on foo; //do foo }

Oki let me know how did it go =) The step I told you are to hide the dammage ye.

Hi, you need to use your mapflag in src/map/clif.c, add a condition in clif_damage, you'll found the current one for hide_dammage, so you can do something similar. Basically you want to send 0 for those attribute on packet if your flag is on.

In login server, search for all reference of MD5_String. (src/login/login.c mostly) add the sha_256 interface in src/common then use it whenever you want.

untested, and not totally finish but just so you see what I meant --- Base (BASE) +++ Locally Modified (Based On LOCAL) @@ -34,7 +34,7 @@ } /// Modifies the value of an integer variable. -bool mapreg_setreg(int uid, int val) +bool mapreg_setreg(int uid, int64 val) { int num = (uid & 0x00ffffff); int i = (uid & 0xff000000) >> 24; @@ -42,13 +42,13 @@ if( val != 0 ) { - if( idb_iput(mapreg_db,uid,val) ) + if( idb_iput(mapreg_db,uid,val) ) //issue here idb_put need int for val mapreg_dirty = true; // already exists, delay write else if(name[1] != '@') {// write new variable to database char tmp_str[32*2+1]; Sql_EscapeStringLen(mmysql_handle, tmp_str, name, strnlen(name, 32)); - if( SQL_ERROR == Sql_Query(mmysql_handle, "INSERT INTO `%s`(`varname`,`index`,`value`) VALUES ('%s','%d','%d')", mapreg_table, tmp_str, i, val) ) + if( SQL_ERROR == Sql_Query(mmysql_handle, "INSERT INTO `%s`(`varname`,`index`,`value`) VALUES ('%s','%d','%ld')", mapreg_table, tmp_str, i, val) ) Sql_ShowDebug(mmysql_handle); } }

no it's an error, your unique_id will be truncated. So when uid > MAX_INT you wont see the diff, but that still give you around 2B uid. If you want to fix it you'll have to modify mapreg_setreg to accept int64 as argument and in the sql query change it to be long instead integer.%d => %ld

like this : conf/msg_conf/import/map_msg_<lang>_conf.txt so Spn and Chn need to be updated. Actually you can put your import anywere it doesn't really matter, but it's just a format choosen for the svn one. Now if spanish and chinese were to enable this import line pointing on the same file, both of their table would be almost identical, since we would have take value from the import file to replace the current.

Add something in skill_delunit. When your unit is being deleted stop the associate status foreachinrange.

@Geinz you maybe just accept the alliance, deco reco and it should be fine.

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.