Garr

Hmm. If you're running server on one machine, maybe try to replace all server-side connection IPs with localhost(127.0.0.1)? That will be conf/map-server.conf // Character Server IP// The map server connects to the character server using this IP address.// NOTE: This is useful when you are running behind a firewall or are on// a machine with multiple interfaces.char_ip: 127.0.0.1// The map server listens on the interface with this IP address.// NOTE: This allows you to run multiple servers on multiple interfaces// while using the same ports for each server.bind_ip: 127.0.0.1 conf/char-server.conf // Login Server IP// The character server connects to the login server using this IP address.// NOTE: This is useful when you are running behind a firewall or are on// a machine with multiple interfaces.login_ip: 127.0.0.1// The character server listens on the interface with this IP address.// NOTE: This allows you to run multiple servers on multiple interfaces// while using the same ports for each server.bind_ip: 127.0.0.1 And conf/login-server.conf // The login server listens on the interface with this IP address.// NOTE: This allows you to run multiple servers on multiple interfaces// while using the same ports for each server.bind_ip: 127.0.0.1

Also if you'll be setting equip to gender-specific, as GmOcean mentioned, don't forget to change this option in conf files: // Can any player equip any item regardless of the gender restrictions// NOTE: Wedding Rings and Whips/Musical Instruments will check gender regardless of setting.ignore_items_gender: yes

Hmm, I think it should be C_CONSTSTR. script->push_str((st)->stack, C_CONSTSTR, skill->db[index].name); May I ask why you need player data here? If you're looking for skill name from skill ID you don't really need to attach player at all. Moreso, there are predefined routines in script.h, so why use one when you already have script_pushconststr? BUILDIN(getskillname) { uint16 skill_id; int index; if( script_isinttype(st,2) ) skill_id = script_getnum(st,2); if ( !(index = skill->get_index(skill_id)) || skill->db[index].name == NULL ) { ShowError("script_getskillname: Skill with id %d does not exist in the skill databasen", skill_id); return true; } script_pushconststr(st, skill->db[index].name); return true;} P.S. I didn't check it out as I was lazy to recompile my test server for that, and I was lazy to remake that into plugin to test either

..? I may be wrong, but he even stated the line he meant, no?

Umm, but if you'll raise your eyes a bit higher the check is already there... if (Zeny < (((BaseLevel + JobLevel) / 2) * 5) && BaseLevel > 50) { mes "I'm sorry but you don't have enough zeny.";}

Why not just do a folder search with "goto"? Usually text editors provide such feature, like I know for sure both Notepad++ and Sublime Text have it via ctrl+shift+f (I use it pretty often, helps to find all the instances of something in specific folder. And if coupled with mass replace it helps even more, like I was able to switch to lowercase commands in all scripts quite easy).

That's pretty simple. There's file called sc_config.txt in db folder. // Status Change configuration database//// Structure of Database:// SC_NAME, flag//// flag 1 - SC cannot be removed by death.// 2 - SC cannot be saved.// 4 - SC cannot be reset by dispell.// 8 - SC cannot be reset by clearance.// 16 - SC considered as buff and be removed by Hermode and etc.// 32 - SC considered as debuff and be removed by Gospel and etc.// 64 - SC cannot be reset when MADO Gear is taken off.// 128 - SC cannot be reset by 'sc_end SC_ALL' and status change clear.//Example://SC_ENDURE, 21 //SC_ENDURE: cannot be removed by death and dispell and cosidered as buff. (16 + 4 + 1 = 21)

Umm... actually, item command has this useful plug that cheks for pet egg, and if it's egg it creates egg as an egg (sorry for ... that). if (!pet->create_egg(sd, item_id)) {...} So that's not the actual problem, I think? I'd say check that your egg ID in pet DB and in item DB are the same, so the monster is assosiated right.

If you'll look closer, he has .@j++ in the end of loop. That means both .@j and .@i bear the same value, and it goes through all items, even if I miss the reason for 2 variables in the first place. The thing is, I guess the problem lies within delitem2. When there are 2 of same item ( 1 and 2) it deletes 1, creates bound 1, but on next run it deletes the bound 1, and creates it bound again, thus not touching the 2 item at all. I'm a bit at loss on how you can delete a specific item. Maybe if first run all-delete, and then all add-in bound again? (Separate delete and getbound into 2 different loops). That'll take 2 loops, but without editing source of delitem I don't see a way to do it otherwise.

Ah, didn't see that it's not attaching rid. Sorry. L_reward: set .@size, getarraysize( getd(".team"+ getarg(0) +"aid") ); for ( set .@i, 0; .@i < .@size; set .@i, .@i +1 ) if ( isloggedin( getd(".team"+ getarg(0) +"aid["+ .@i +"]" ) ) ) { getitem .rewarditem[ getarg(1) ], .rewarditem[ getarg(1) +1 ], getd(".team"+ getarg(0) +"aid["+ .@i +"]" ); attachrid getd(".team"+ getarg(0) +"aid["+ .@i +"]" ); getexp 200000,200000; detachrid; } return;

L_reward: set .@size, getarraysize( getd(".team"+ getarg(0) +"aid") ); for ( set .@i, 0; .@i < .@size; set .@i, .@i +1 ) if ( isloggedin( getd(".team"+ getarg(0) +"aid["+ .@i +"]" ) ) ) { getitem .rewarditem[ getarg(1) ], .rewarditem[ getarg(1) +1 ], getd(".team"+ getarg(0) +"aid["+ .@i +"]" ); getexp 200000,200000; } return;

Subnet.conf is best when you need to recognize inside network to use inside IPs. It shouldn't have much effect, but without it I'd be doomed with my router NOT supporting NAT hairpinning >.> Maybe it could be your network problems rather? Did you try to get connected from the outside before? Some ISPs are running users behind NAT, so without proper intervention you can be lost (aka you're sharing outside IP with some other clients), and when you try to get connected to from outside network you'll fail since it needs special settings on NAT source, like port forwarding or DMZ.

It is written that if 32 then GOSPEL WILL REMOVE IT. // 32 - SC considered as debuff and (will) be removed by Gospel and etc. And one of tarot cards uses same code as gospel, so it won't be removed as well.

*facepalm* I'm sorry, but I have no words. WHY, WHY THE HELL DO YOU SET IT TO 32?

There's no SC_FULLPROTECTION. You just made that up. SC_PROTECTWEAPON, 28SC_PROTECTSHIELD, 28SC_PROTECTARMOR, 28SC_PROTECTHELM, 28 You need to change those. I think you need to remove 16 from them, but not sure. SC_PROTECTWEAPON, 12SC_PROTECTSHIELD, 12SC_PROTECTARMOR, 12SC_PROTECTHELM, 12

First of all, some weapons are indestructible by nature, from the top of my head: staves, two-handed staves, axes, two-handed axes, books, maces and huuma shurikens. Rates do affect rates that weapons/armors break with. For example, if you have equip_skill_break_rate on 100, chances are same as it is in the skill description (AD, per example, so 10%). If you have it at 10, it's 1/10 of what it was, so 1% in our case. In other words, view it as % of the original value.

Why not just use @addperm disable_pvp and/or @addperm disable_pvm? It lasts until relog, or until you use @rmvperm on them. For the mute bubble just use @mute?

Oh, nevermind me then

Manually revert all 3 changes mentioned in the comments under the report. 1 2 3

You can actually use battle_config.variable_name variables in plugin at your will, the only thing is that you'll need to replace battle_config. with battle->bc->, and don't forget to fetch battle symbol for plugin not to crash. Example: battle_config.go_delay becomes battle->bc->go_delay to be used inside plugins.

Tried what? That report shows that people can switch weapons to gain double card effects, and fixes are applied to counter that. Currently that fix is working, and that's why when you switch weapon its card and effect won't take place until attack finishes.

I believe that it's the effect of this report/fix.

It's pretty easy to reproduce: Try to vend items, that you just put in the cart from inventory, and that were in inventory when you logged on, and it will defy those items. I wrote it in the bug report. It should be fine if your local server has latest repo though, so don't even try to reproduce it there

Actually, no, but update your repo and it should be fixed.

I like using menu when I have few option that all lead to same result. switch(select) + default seems like a bit too much for such an easy task Anyways, nice one. I believe there was also a somewhat guide on scripting rules as in use of intendation/naming scheme and all that. Might help make scripts cleaner and easier to read for everyone if you'll link it somewhere.