Lighta

With the code I gave you few post before, It will wait the player is dead and if he was under a gvg map he will have the delay. If you want to apply the delay everytime a player change map you could look at pc_setpos into the if( sd->state.changemap ) { ... } But that would be on everymap change meaning that when you enter the castle since you entering a new map you'll have to wait 5min before casting.. If you want to apply the delay for every kind of dead well taht still in pc_dead just found another more suitable location, you could just put if after the if( map_flag_gvg(sd->bl.m) ) { } Biw about "Because right now the guild_skill_relog_delay only works for the relog but not for the death and change map." that just a name you could use it for everything you want and that what we're doing right now. Now the code I had given you probably not work cause you have outdated version and your lecture of guild_skill_relog_delay in battle.c is probably this { "guild_skill_relog_delay", &battle_config.guild_skill_relog_delay, 1, 0, 1, }, instead of this : { "guild_skill_relog_delay", &battle_config.guild_skill_relog_delay, 300000, 0, INT_MAX, }, right ? Anyway you could try with this intead: guild_block_skill(sd, 300000);

// Activate guild skills delay by relog? // Official setting is 5 minutes (300000 ms), otherwise allow guild leaders to relog to cancel the 5 minute delay. guild_skill_relog_delay: 300000 That how the config should be in last version, we no longer use yes as value but the amout of millisecond to block the skill.

I had set EC coodlown for only 30 secs but when guild_skill_relog_delay: the cooldown is set to 5 mins. Hmm well then you should set guild_skill_relog_delay = 0, but i'm not even sure that will take the cooldown from skill_cast_db.txt (that what you was refering too ye ?) You'll probably need to do some other src edit to replace guild_block_skill(g->member[0].sd, battle_config.guild_skill_relog_delay); by guild_block_skill(g->member[0].sd, skill_get_cooldown(skillid,skilllv) ); => but guild_block_skill will set the same delay to all the guildskill so that an issues... Otherwise for the case he's able to recast just after idk, are you sure you have recompiled right ?

if that a diff yes, otherwise remove the + before. note I didn't try it but that should work ye. You didn't mention where the char should be dead from so I assum it was from a gvg map. But anyway you got the code and the section where that should be more or less so you should be able to manage now =)

There no much dev arround atm, beside this concern more scripter then coredev, It's still slower then the src option so unless you want to interact with npc the src option will be better. (altought the big advantage of script is the reloadscript)

Shouldn't you ask this in source request instead ? http://rathena.org/board/forum/36-source-requests/ Otherwise what you want would be in pc.c::pc_dead: if( map_flag_gvg(sd->bl.m) ) { add_timer(tick+1000, pc_respawn_timer, sd->bl.id, 0); if (sd->status.guild_id && sd->state.gmaster_flag && battle_config.guild_skill_relog_delay) //if were dead on gvg map are guildmaster and have the config set the delay on guild_block_skill(sd, battle_config.guild_skill_relog_delay); return 1|8; }

Well there ain't much database on the src code, or you mean the running data ? like charid_db etc ? What do you think about the jathena implementation, do you guys think we should implement it ? too difficult to use ?

About your db and skill propriety, that why I kinda introduce INF3 in skill_db to add some propriety in DB and remove some hardcoded. Even tought I think we could add a field in col 6 (// 06 nk (skill damage properties)) 0x100: randomize number of hit [0;x] But if you look carefully you'll see we have 1 in number of hit for GS_DESPERADOS wich is kinda confusing : 516,0,8,4,-1,0x2,3,10,1,no,0,0,0,weapon,0,0x0, GS_DESPERADO,Desperado Anyway about the src you have edited, hmm you suppose DESPERADOS is a status, wich is ain't so taht wrong. It's actually a hard one, were using an timered unit. => (skill_unit_cast_db). A timered unit is a skill on floor that is trigger every x tick, wich is set to 100ms here : 516,0x86, , 3, 0, 100,enemy, 0x000 //GS_DESPERADO Now that unit is staying on the floor for a x ms wich is defined as unit->limit, Unit->limit when not specifyed in src is taken from (skill_cast_db.txt as duration 1) 516,0,1000,1000,1000,0,0,-1 So duration1 = 1s here 1s/100ms ok there is our 10 hits. Now to randomize this we should reduce that duration between 1-10s (yeah 0 might be problematic) so in skill.c:skill_unitsetting(): case GS_DESPERADO: limit = 1+rnd()%10; Now why we didn't set a row for limit in skill_unit_db, idk but I might do it cause this kinda suck atm. NB : May I know where you found where the 10hit should be randomize so I can push a patch about it on repo ?

Checkout the comment and the code, well your's will work fine, the only thing Ai4rei mentionned is that you didn't have to open the file at each action cause that is slower. (summerized). You could very well mimic C behaviour and specifically open(file) and close(file) and retain a reference Imagine doing .@i = 0; do { .@line$ = readline("rathena_db.txt".@i); .@i++; } while(.@line$ != ""); This is line parsing each line of your db and reading it, (idk maybe to found an ID then read the rest of the line) So in real that will open and close the file at each loop incrementation wich is quite ugly.. Now the issue about retain the pointer and expect people to close the file is that looking more and more of doing C, sure you won't have thread issues yet. (Like 2 people talking to the NPC it's still 1 execution at the time (that what he was saying)) but they could very well forget to close it and/or try to reopen it with or timer and such so it's an issue. (sorry if I may sound to look down but a good % of people scripting ain't expert of file descriptor issues). I think a ok solution would be to retain the FH in a pointer but to limit is life to a scope {}. //he will auto close the file when he's leaving it (a bit like perl). But to begin I'm sure the think you have done is fine. You may want to add a split function tought In src what Emistry started to quote is : sv_readdb( db_path, "rathena_db.txt",char_delimiter$,min_col_number, max_col_number, max_line_number, &parse_function); parse_function(char* fields[], int columns, int current){ //fields data in each field //current is the line number //colunms is the number of col in that line }

do you have any kind of dump or even picture to see what's going on. Are you able to make it work without any edits ?

How did you fixed it ?

You'll need src edit and change is equip position e.g epos = sd->status.inventory.equip; if( epos&EQP_HEAD_TOP ) { epos &= ~EQP_HEAD_TOP; epos |= EQP_COSTUME_HEAD_TOP; } nb : then I recomend you prevent combo, item script and such being run if it's a costume item.

hmm ye kinda, you're packet handling is in clif.c:clif_parse_cashshop_buy when you click buy in the cashshop you arrived directly in that function. Ok so there a probability you have misconfigured the serv to match the client so it would be great to have the value of : PACKETVER, packet_db, clientinfo version and the version the serv say he have recognized for you. Then beside this it appear we do not have a proper version linked to that date, 2010-11-16, the next one is 2010-11-24 and that packer_ver = 26. Now that one has the correct definition for the cashshopbuy : 0x0288,-1,cashshopbuy,2:4:6:10 10 is the index where he should found the amount of item you buying from cashshop wich is appear to not have found and thus having that 10 here (len 14:10)! (14 is expected value, 10 = 10 + count * itemsize) => count = 0 So since we are in 2010-11-24 we should be linked to packer_ver = 25 wich unfortunatly have that definition : 0x0288,10,cashshopbuy,2:4:6 (herited from packet_ver : 22) Wich since doesn't have the index from count doesn't fetch it and therefore failling... A simple fix would be to alter packet_db.txt and change line 1020 from 0x0288,10,cashshopbuy,2:4:6 to 0x0288,10,cashshopbuy,2:4:6:10 I think that should do it but this is a very old client quite depreciated, as you can see those packet there ain't well maintened.

WFIFO stuff ain't really hard to get it. Most of it is define in doc/packet_struct_notation.txt but in short you'll have WFIFOHEAD(file descriptor, xsize); //reserve/allocate xsize on the socket WFIFOx(file descriptor,offset) = y; //assign the file descriptor at offset position the value of y, (x represent the data len W=short, L=long, B=char, Q=64b) WFIFOSET(file descriptor xlen); //sent xlen bite to file descriptor y = RFIFOx(file descriptor,offset); //assign y the value of file descriptor at offset position, (x represent the data len W=short, L=long, B=char, Q=64b) about the storelist openup too frequently yeah I guess the only real fix I could done for this would be to attach like a tick timer and prevent open it more then twice a second, wich should be plently enough.

comment the else part

ye it go with all this but you where using PACKETVER >= 20130807 wich mean you'll received some data meant for a client of this date or newer. For exemple you'll receive some bank data stuff while you don't even have taht functionnality in version 30, around 20120410.. So yeah you need to change the version define in clientinfo, to remove the warning, but the real thing is to set the clientinfo and PACKETVER to the good date according your client.

AnnieRuru your issue should be fixed in https://github.com/rathena/rathena/commit/4212080bd98a687df108195011073436f26cd6d7 altough I didn't get why some item still couldn't be dropped even with full permission and you may still receive the message if you openup the storage too frequently. Here my npc I had for testing. prontera,155,188,5 script storagelist_test 100,{ freeloop 1; for ( .@i = 500; .@i < 1500; .@i++ ) { if ( getitemname( .@i ) != "null" ) getitem .@i, 1; getinventorylist; if ( @inventorylist_count == 100 || Weight > ((MaxWeight)*90)/100 ) atcommand "@storeall"; sleep2 200; } end; }

hmm yeah there a possible desync here, the association is in config/core.h with the : #else #define MIN_STORAGE 650 // If the VIP system is disabled the min = max. #define MIN_CHARS 9 // Default number of characters per account. #define MAX_CHAR_BILLING 0 #define MAX_CHAR_VIP 0 #endif where that MIN_STORAGE should have been MAX_STORAGE but core.h doesn't know map stuff so eh couldn't read the value... they have the same value but it would be better to have something more linked to avoid errors.

na the code is fine here. you could simplify by this : when VIP disable { MIN_STORAGE = MAX_STORAGE; sd->storage_size = MIN_STORAGE; so you have max_storage } all good now VIP enable { sd->storage_size = MIN_STORAGE; //300 chrif_req_login_operation will request() => that will ask char-serv and login-serv if he's in vip state char-serv will reply by : chrif_parse_ack_vipActive(){ sd->storage_size = MAX_STORAGE } //your storage is updated in new value } so your storage is updated wheater you're a vip member or not Now about the [Error]: WFIFOSET: Maximum write buffer size for client connection 3 exceeded, most likely caused by packet 0x00af (len=6, ip=127.0.0.1). I think clif_storagelist still have some issue, wich I start debuging it a bit. http://upaste.me/1b8589 I also added a sleep2 500; into your script so it won't flood as much.

Let me work on this, but the error you quote is a map<=>client errors, Do you have suggestion about the MIN_STORAGE to not have 2 config ?

Kinda, we still need to rewrite map<=>char item saving, cause this is what limiting now. Since increasing the MAX_STORAGE too much will increase the size of mmo_charstatus, when this one is superior to 0xFFFF, 1 packet can't hold all the information. So I'm thinking it would be better to remove storage from mmo_charstatus and make their onw packet so the limitation would be removed.

or perl tools/convert_itemtype.pl --i=../db/item_db3.txt --o=../db/item_db3.txt So you don't have to messed up the script =)

Xd wow I had missed this. I'm ok to separate vip more and expend it as you suggested as it shouldn't decrease serv performance. The next most require thing is to remove vip from groupid but to keep that kind of benefit. So in short will check your normal group then vip group for permission. Unless you guys prefer a while duplicate of groupconf for vip conf and add some level.. that could be it too and look more what cydh suggested. @GmOcean we coul move that conf into sql to rend it permanent.

Chiron we not coding in C++ and it's more compiled in std=89 right now, yes that suck Concerning *.sln no plan was taken to remove them but ye I would like to move all those windows file if possible. We have like 4 vcproj + 4 *sln file, while only a very few people use it as production server

Those are where you calculate the resist. You can reduce the resist wich increase the chance or you could alter variable "rate". But status change are really define when there being used like : in skill_additional_effect:: case MG_FROSTDIVER: if(!sc_start(src,bl,SC_FREEZE,skill_lv*3+35,skill_lv,skill_get_time2(skill_id,skill_lv)) && sd) clif_skill_fail(sd,skill_id,USESKILL_FAIL_LEVEL,0); break; In english mean When dammage>0 (mean we will enter skill_additional_effect) if the skill used was MG_FROSTDIVER Try to inflict SC_FREEZE with skill_lv*3+35 % chance. If it fail display an erorr message.