Variant

You can use the function globally just with 'callfunc("FunctionName",arg1,arg2,...);', which other people have stated. Wouldn't it just be a cosmetic change to make it follow C syntax (as in, FunctionName(arg1,arg2,arg3,...); )? I mean... call it 'ugly' but I actually like callfunc, using it as a way to keep track of various function calls is convenient for large scripts, especially when you can just ctrl+F for callfunc when you forget your function names after a month of not looking at a script. I guess it would be cool and all, but is it really worth the work necessary to get it in? (Especially if SketchyPhoenix's Lua Script Engine gets finished and implemented) tl;dr Is it really that much of an inconvenience to type callfunc("FunctionName",arg1,arg2,...);? Edit: Wow, 10 days later, sorry! Facebook just posted this up for me today so I thought it was more recent.

If you do that you'd have to copy the images and sprites for every single card. In your resnametable find any card and copy-paste the line and change the ID to whatever your custom card is. The resnametable just tells the client what files to use as a resource, so if you want it to look like a card, you copy the resource name for the card.

In your idnum2resnametable, make sure that the cards have the same value as every other card. CUSTOMCARDID#À̸§¾ø´ÂÄ«µå# Or something like that.

"pre-re" mechanics? But then having above 99 defense would mean you'd take no damage from physical attacks wouldn't it? Well, here you go: if you go into status.h and find where the structure status_data is declared, and then find: signed char def, mdef; And change signed char into short, then def and mdef should be able to go from -32k to +32k, but there's probably several checks that cap the value to 128 (CHAR_MAX/2 = 256/2, since a signed character can go from -128 to 128) in status.c, but you could find those with a little searching. At least it shouldn't overcap unless you somehow get above 33k defense.

Const = any constant, and the +/-* are the operators. You change that to whatever you want to alter the damage by. So for example, if you wanted to double the damage you'd do return damage * 2;

Woops. Forgot about that macro function. Yeah, you could just use: return cap_value(damage,0,DAMAGECAP); //Is it 0 or 1 that's the min here? Replace return damage with return (skill_num == KN_BOWLINGBASH)?cap_value(damage,0,36000):damage;

In battle.c find int battle_calc_damage(struct block_list *src,struct block_list *bl,struct Damage *d,int damage,int skill_num,int skill_lv) Then go to the end of that function: status_damage(src, s_bl, damage, 0, clif_damage(s_bl, s_bl, gettick(), 500, 500, damage, -1, 0, 0), 0); return ATK_NONE; } } } return damage; } and change return damage; to: if(skill_num) return damage */+- CONST; else return damage; You actually don't even need that 'else', but it's for clarity. Edit: You should read that function over, just in case there's some skills that return damage beforehand (like Pressure) that you want to modify.

Replace them all (Ctrl+H to find and replace in notepad) all getmapmobs("this") and mobcount("this") with mobcount("this","") Those are all double quotes btw.

Try replacing getmapmobs("this") with mobcount("this") or mobcount("this",""), getmapmobs is way old apparently.

Verified! It does work, thanks!

You can use: int dir = map_calc_dir(src, x, y ); unit_setdir(src,dir); I'm pretty sure that's how they're used, 99% sure, based on how backstab is coded.

If atcommand/charcommand are used through a script (which I imagine they do need to be) with a player attached, it treats the command as if it were used by a level 99 GM, they don't need to be level 99 GMs to use atcommand however. As for the party request, I don't think there's commands that can do that, but with a little bit of research in party.c and script.c, you should be able to figure out how to make a script command that calls the party_invite functions (there's a few functions involved in joining a party), and the party_removemember functions. (To get the 'sd' and 'tsd' arguments you can take the character IDs as script arguments, and then use map_charid2sd(charid); to convert em)

You're only supposed to add the parts with //add commented, it looks like you copied the entire codebox. case DOTASWAP: //add DOTASWAPfu(src,bl); //add clif_skill_nodamage(src,bl,skillid,skilllv,0); //add break; ^That's the only part necessary, the rest of it is there just to tell you where to put it. If you want to get rid of the implicit declaration warnings, you could always just add a function prototype in skill.h, but it's not a huge deal... @Cephaler: From how it looks, it seems it'll work on players. You could even give mobs the skill. @Goddameit: This is pretty awesome, I love it.

Couldn't you just use clif_skill_nodamage(src,src,skillid,skilllv,1); instead of the poseffect? That should have the intended result (the skill scream).

I'm experiencing this issue too (on the 06-14-11 client), it's weird. I've definitely updated the SQL tables, because if I hadn't, all three servers would yell at me about SQL query errors. More than anything, I'm actually curious to why this happens, can anyone point out the file that was changed to cause this? (My initial guess was clif.c, but it could also be char.c, but it's a bit tricky to pinpoint the change when you don't know what you're looking for). Edit: It works correctly for normal accounts, GM accounts seem to have the issue however. I suppose this makes it easier to track down though.

int battle_calc_damage(struct block_list *src,struct block_list *bl,struct Damage *d,int damage,int skill_num,int skill_lv) Find that in battle.c, go down to the end of the function where it says return damage; and add if(damage > DAMAGECAP) damage = DAMAGECAP; before it. Replace DAMAGECAP with whatever number. Unless there's some function for some obscure skill that doesn't call this function, it should cap all damage. (Do skills like demonstration call this function actually? I'm not really sure, unit skills are weird, but I think they all call this function for damage.)

So, I was wondering how TF_HIDING works. That is, how it can be used without triggering the skill scream (Hiding !!) on usage. I thought it was in skill_castend_nodamage_id But all those clif_skill_nodamage calls look the exact same as any other. Then I decided to look at LK_TENSIONRELAX (also in skill_castend_nodamage_id). ...That didn't shed much light either. So my question is this: How exactly does hiding the skill use scream work? Is it based on the ID (and therefore, on the client)? If so, is it something as simple as changing LUA files? Or, is it actually somewhere in the source and I just missed it? I'm on rAthena rev. 15522. Thanks!

It'd be: if(status->luk >= 100) Int_ is just like that because 'int' is a reserved keyword. As for case-sensitivity... not really sure, but might as well play it safe. Doesn't having some amount of luck stop all status effects anyway?

Uh, bump again, but this time with a reason. I couldn't figure out how to display the 'k', but I did figure out how to display up to 9 digits. Using OllyDbg, with a lot of guidance from Ai4rei, I managed to rewrite the routine for how the client displays the digits (simplified the ridiculous mess of lines into one loop). For those interested, search for CMP ECX,0F423F in the main module, and read on from there. The digits are all stored in an array, and the usual method of extracting digits is 00785BC4 B8 67666666 MOV EAX,66666667 00785BC9 F7E9 IMUL ECX 00785BCB C1FA 02 SAR EDX,2 00785BCE 8BC2 MOV EAX,EDX 00785BD0 C1E8 1F SHR EAX,1F 00785BD3 03C2 ADD EAX,EDX 00785BD5 8D1480 LEA EDX,DWORD PTR DS:[EAX+EAX*4] 00785BD8 03D2 ADD EDX,EDX 00785BDA 2BCA SUB ECX,EDX 00785BDC 894C24 40 MOV WHATEVERYOURARRAYIS,ECX 00785BE0 8BC8 MOV ECX,EAX Which can be rewritten pretty easily, since all it does is divide the damage by 10 and store the remainder in an array (in my case, where ESP+20 + 4xDigit# was pointing). IDIV 0A does the same thing, I just wrote a loop to save space, whether or not it's faster or slower... well, it's less instructions.. right? Haha, it's negligible either way I suppose. I guess theoretically you could go up to even higher values... I'll pass on ever having players deal 2 billion damage though. For reference, I used the 06-14-11 client, your addresses probably won't be the same because my client was already edited elsewhere, but it's the same concept. Edit: Since this problem is solved, I guess this topic can be closed? I don't know the policy. Edit2: I think this also should go into client support.

So I've been messing around to see how far I could push the parameters of a character (such as max HP, SP, damage, etc...) and I came across a problem. When I raised my HP above 21,000,000, the HP on the HP/SP bar that the player sees (right underneath the character) showed an empty bar. My actual HP value was over 21,000,000 however. What's weird is, once HP drops below 21,000,000 from damage or something, it'll show up correctly (e.g. having 19,000,000/22,000,000, will show correctly, but if you heal past 21,000,000 it'll show as empty). Now I realize this is a limitation of the client, but while I was looking for a way to remedy this I happened to stumble upon this neat little piece of code, written by skotlex: And so I went and implemented that trick (showing the hp out of 100) in the party HP bar function in clif.c and it worked like a charm, I could see the HP bar of a party member going down accurately enough. Then I went to go look for a way to show it to the player in question, but I think clif.c just sends the HP values to the player and then the client just does something with that, as opposed to how party HP bar-showing works, where it's possible to send it as a percentage (out of 100). As a quickfix, I just made a command called @showhp that'll show your actual HP as being a % out of a 100, but this doesn't help that much... Normally I'd try to shove ShowDebug's everywhere in order to find where the problem is, but in this case, I don't really understand how the HP meter works. Does anyone have any ideas on what I could do to have HP above 21,000,000 show correctly? Is there a way to have the HP bar show as a % out of 100, but not actually show the HP (in the character information window) as being 100? Edit: Forgot to mention, I'm using the 06-14-11b client, and am on rA rev. 154XX The @showhp command I added is simply implementing the % trick in clif_updatestatus, by making max_hp show up as 100, and hp show up as a fraction (hp/max_hp * 100). This makes the HP on the character display also show up as 100 however...

*Bump* (I read the rules and it said not to bump repetitively, so just once is fine, right? Sorry if I misunderstood!)

Change that line to: sprintf(atcmd_output, "- %s (%02.02f%%)", mob_db(item_data->mob[j].id)->jname, item_data->mob[j].chance/100.);

That's the conclusion I came to also, even if I tried to send over a string, one way or another it'd just become a large number. I guess it really isn't possible, oh well, thanks for verifying that for me. Is there anyway to change the color? Or maybe make it have the double attack yellow 'floating' letter? In 'clif_skill_damage' that is.

I've been trying to figure out 'clif_skill_damage' and 'clif_damage' in src\map\clif.c and was wondering if it's possible for it to show damage above 999,999 by showing damage/1000 + "k" So 1,020,342 damage would show up as 1020k. Just having it display the number is easy enough, and I just made it show an effect whenever the damage exceeds 1 million, but if anyone knows how I could get it to show the letter at the end, that'd be much appreciated! Or even how I could change the color of the numbers shown. For reference, I'm using rAthena rev. 15399 and the 2011-06-14b RagexeRE client.

Edit: It should be "cash", not "Scash", don't change that back. Also, those warnings are normal, compare is just telling you that you're comparing an int to a string, which isn't that bad (a conversion to a higher data type), it's because the script goes through the arguments until it hits the "Cash" argument, which is the only string, which is why you get all those messages beforehand (you'll basically get one of those messages per "Item,Price" you add). So, it should be working fine, those messages don't pose a problem for you, unless you're extremely annoyed by it, in which case, I think there's an option somewhere to disable warnings... I wonder if it'd be possible to cast integers as strings... hm, I guess you could always just make a temporary variable and set it equal to "" + getarg(.e+1), but uh, that sounds like too much extra trouble.