Lighta

Agree with this suggestion and we could also add homreset, found it usefull for some test. I don't like too much code duplicate so when it's use in 2 interface I think we better put the generic in homon, and reduce the call in atcommand and script. nb : if( sd == NULL ) is useless, you already check it with nullpo, and at this place it would have been wrong since you used it before =)

we don't have it all but : that your issue right ? : if( pc_delitem(sd,ind,price,0,0, LOG_TYPE_NPC) )//somehow it failed to delete... Just quick verification does price > 0 ?? couldn't see a check about it

then it's a bigger issues then I tought, cause right now some skill erasing all unit, like LP = ok let's erase what on the ground and put me. definitly not database related only, and probably medium changes. won't have time to fully support this, so you need to try to preserve your skill_unit for the dance unless changing weapon, could take a look at guild_skill_unit like UNT_GD_HAWKEYES and such.

I'm in favor of AStyle too, but when I tryed some function was getting quite long. The better IDE I had to do this was codeblock, "format projet" using IDE, you'll see what I was talking about.

You mean like whatever you do you'll keep dancing until your weapon get off ? That even if you dispel or ganbat.. your song will continue ?

you forget the "<" wich in this case mean read. so try cd /home/ra && patch -p0 < /home/updates/patchfile or just patch -p0 /home/ra/myfiletarget /home/updates/patchfile

please show your final diff so we know what we're working on

src/map/battle.c block 2448:2457, change the skillratio to alter dammage ratio from atk. or use the http://rathena.org/board/topic/62238-manage-skill-damage-20/ of lilith

- pc_delitem( sd, ii, 1, 0, 0); + pc_delitem( sd, ii, 1, 0, 0, LOG_TYPE_CONSUME); or whatever type you want from e_log_pick_type, just make sure they're defined as enum type for logging item

int32 yeah but they could tryz with int64 or make it unsigned to test 3b

So I looked the patch EvilPunker and there some issues : script error on db/re/item_db.txt line 1053 parse_callfunc: not enough arguments, expected ',' * 1053 : { bonus bStr,2; bonus bInt,1; bonus2 bAddRace,RC_DemiHuman,95; bonus2 bVariableCastrate,"MO_EXTREMITYFIST",-25; autobonus "{ bonus2 bVariableCastrate,"'M'O_EXTREMITYFIST",-100; }",50,6000,BF_WEAPON,"{ specialeffect2 EF_SUFFRAGIUM; }"; bonus bUnbreakableWeapon,0; } This is due to " " quote, since you using them for the skill name you breaking the quote thus generating an error on autobonus. Then another more important error is that right now not all bonus can support skill name, just a few do the resolution to skillid. So that was just to give you some feedback, I'll work on it.

That cause you already have 1M from getttick and multiply by 50 but int32 it's limited to 2M when signed. Don'T get exactly why you giving such a big value on SC_ITEMBOOST and SC_EXPBOOST, what are you trying to do ?, the 1st argument is the ending tick wich I guess you already set by doing gettick+day... so why *1000 again ? That cause you already have 1M from getttick and multiply by 50 but int32 it's limited to 2M when signed. Don'T get exactly why you giving such a big value on SC_ITEMBOOST and SC_EXPBOOST, what are you trying to do ?, the 1st argument is the ending tick wich I guess you already set by doing gettick+day... so why *1000 again ?

no biggy then =) I don't want subjet to slip, I was just thinking in a way to improve tests like automatique test of command after a rebuild etc..

Didn't get exacly what you wanted I check there, those command read it just like I do without really checking the lenght of the list, well we do lastdata wich give us the lenght cheking if it's pair and that all. Anyway I did a small other version with array, wich imo I found more usefull. I didn't integrate this one with the previous checkweight as he may complicate it a bit. http://upaste.me/f6491597e6d952ad all 32 tests succed.

Warnings depends on compiler and on wich architecture. like gcc won't complain if you declare a new variable in middle of a scope {} while MSVC will complaint he want it at begining. (or more recent the ret unintialise you can check the buildbot result for that) The forget part is not good but doesn't mean neither that the src wasn't test, well not the final release one but it was probably tested on localbranch then forget while merging for commit. The only thing certain is that commit aren't perfectly tested before commit. Well after all it's a trunk and there no QC team so... I do agree that split version is generally how project are handle and i'm in favor about it but your last comment just look like small flame sorry.

I don't get it Beret can you elaborate your point ?, If you ask if that will influence msg_athena.conf the awnser is no, not at all.

There other way of doing my example I agree. You could just dump the message put it in sql table wich is read by npc IG and even have your log commit display automagically without reloading the npc etc.. ok Still right now the way I see it, is simply taking off a feature for medium+ user. They already can do a NPC like that on their own and probably already did something like that. But reading a common file and display it to the game that probably less common. So in short you taking away something "dunno how to do" for something pretty basic. Like if one day I wanna read another file for display at a certain hour/event whatever. Assuming I'm intermediate I can just look MOTD behaviour and reproduce for a new event. Advance won't care much they'll fread... Still the global idea is good but im just nor in favor to pure remplacement. To encourage OnPC... in a same file the best thing would be to limit it in source to a certain premade file.

Ah sorry Cookie I tought I missunderstood, but if you look the diff you'll see that I'm checking for multiple item at once. I was trying to say it's mean to fix check for multiple item without chaining them with if. Those if that currently won't work unless you rewrite a whole NPC function. Question and little leak here is how many argument could be pass to a script, right now I'm taking as mush as I can and check if it's a pair but a array ref would be better to increase the nb of item that could be checked.

Somewhere you trying to read quest index 70000. Do a recursive file search on this index or chekquest to figure out where if it's really the case or no eg linux : grep -R -i -n 'checkquest(70000' npc/ || grep -R -i -n 'checkquest' npc/ || grep -R -i -n '70000' npc/ (yes that actually 3 chained search, if not found use next search etc)

I think they shouldn't sync, well I just modelizing the thing as 2 different map-server so it normal that those doesn't follow. Otherwise they would need to be handle differently and perhaps complicate stuff without good reason, at worst/better we could always add a new symbol for that feature. A easy quickaround for that would be to writte in sql then when char totaly disconect to erase all variable referenced with that symbol. The query_sql is a much more important matter imo, even trough most people install all 3 server and schemas on the same host, they could all be splitted, was working quite well when I tryed. Or I often see people doing script with direct acces to char_db implicitly breaking that indenpendancy. (Just imagine setting another schema in same host wouldn't work either so we implicitly nerf inter_conf) Guess we could add type for query_sql wich then will redirect to inter to do the proper job. Altough this will increase sql result latency in scripts. But working on this and renew it may even facilitate the threading implemantation of Sirius White. saw he was trying to do those as thread instead seq like now.

What's this version ? seem like your makefile is broken so make sure you have the latest version. Or try with the cmake (well that kinda the same solution as above)

It does complicate a bit cause you need to be sure change won't break pre-re compability, so when it's a case or you're thing is only meant for RE you need to add an #ifdef etc, preventing flexibility. Llike let say I would want SC_FOO->val2 for a new feature I would have to search all reference of sc->data[] usage and check if it ain't use in pre-re, (checking reference may be tricky as some may be hide with jsut sc->data[FOO2+5] with FOO2 declare 5 row before SC_FOO... Then right now buildbot don't even build without #RENEWAL wich mean we could broke something for a plateform and won't even notice since he doesn't do it. Not likely but could happen very easily. Finally there is no more or very few PRE-RE specific improvement, most of change concern both like new group system (doesn't care if you RE or not) or skill update (since 3rd ain't finish yet) etc. So imo if we keep it there right now it's just to not replicate those change on the PRE-RE version or vis versa. It do bring avantage but now that thre more and more #ifdef I think would be better 2 version that we syncronise frequently for common change.

Hi, so I already had that suggestion in the past : http://rathena.org/board/topic/59194-upgrade-checkweight/page__p__79979#entry79979" but I feel it was refused, well Kenpachi didn't look that interested. Nethertheless I'll retry a last time cause I feel he didn't get my point or just didn't want to bother core dev. 1st Here the diff for easier explanation : http://upaste.me/b38515856bea1995 (yes I know label are useless here etc doesn't matter) So right now the issue is that checkweight only return true or false for chekcking space for a new item. That small return prevent to chain check like for say : chekweight(517,500) && checkweight(516,500) <=> test 17 right now the && check will return true and true wich is true but doesn't check the total weight of both. But that not all it also prevent slot amount check, <=> test 19. 32K overamount could also be fooled even if this one should be rare <=> test 22 Now I'm sure we may do a NPC function to fix those chaintest (I was originally planning to do so to demonstrate in the test npc), but doing so ain't the good way looking it imo : 1 - chekweight is meant to check if you have enough place in inventory so it would be change like a sub ? or even not used at all ? 2 - chekking via NPC will always be slower, just think of all the pushint, getnum, rechek if sd, recalculate slot etc when we already have all that. 3 - only bad point that I see is that is complexify a bit the chekweight command. nb : by doing the npc I originally wrote .@succes += ChkResult().. but this failed so we may have a little issue on this.

saw that, there a small mistmatch with size constant wich ain't the same for mob and player but that another issue

I think the pool need to be restarted since the last option was insert way after, (people had already voted...)