GmOcean

Bumb! Please if anyone has any information sharing is caring xD

prontera,150,180,4 script SkillPoint Seller 123,{ mes "^0000FF[SkillPoint Seller]^000000"; mes "Hello, I can sell you skill points."; mes "It will cost you 1TCG per 1 Skill Point."; mes "Do you want to trade?"; if( select("Yes!:No.") == 2 ){close;} next; mes "^0000FF[SkillPoint Seller]^000000"; mes "How many would you like to trade?"; if( select("I'll decide:As many as possible.") == 2) {if(countitem(7227){ set SkillPoint, SkillPoint + countitem(7227); delitem(7227,countitem(7227)); mes "All done."; close;} else {mes "You don't have any TCGs."; close;}} input .@a; if( .@a <= 0 ){mes "Invalid amount."; close;} if( !countitem(7227) ){mes "You don't have any TCGs."; close;} if( .@a > countitem(7227) ){set SkillPoint, SkillPoint + countitem(7227); delitem(7227,countitem(7227)); mes "All done."; close;} set SkillPoint, SkillPoint + .@a; delitem(7227,countitem(7227)); mes "All done."; close; } Meh, It could be refined.

It shouldn't be an issue with your client. Perhaps you have this disabled? conf/battle/items.conf // Allow changing of equipment while interacting with NPCs? (Note 1) // Default: yes item_enabled_npc: yes Because I'm unable to reproduce your issue :/

@QQfoolsorellina - Thanks for that lol.

I'm suggestion that the *addrid script command have 1 more Type added to the list and that would be for a specification of a map. Currently it only supports either the map an invoking player or NPC is in. But this kind of limit's the use to NPCs that are either invoked by a player or are on a map to begin with, so floating NPCs are kinda nulled from this (except when invoked by a player). Not a big deal, but don't see why it shouldn't be there. *addrid(<type>{,<flag>{,<parameters>}}); This command will attach other RIDs to the current script without detaching the invoking RID. It returns 1 if successful and 0 upon failure. <type> determines what RIDs are attached: 0: All players in the server. 1: All players in the map of the invoking player, or the invoking NPC if no player is attached. 2: Party members of a specified party ID. [ Parameters: <party id> ] 3: Guild members of a specified guild ID. [ Parameters: <guild id> ] 4: All players in a specified area of the map of the invoking player (or NPC). [ Parameters: <x0>,<y0>,<x1>,<y1> ] 5: All players in a specified map. [ Parameters: <map_name> ] Account ID: The specified account ID. <flag> can prevent certain players from being attached: 0: Players are always attached. (default) 1: Players currently running another script will not be attached.

I agree as well. I see no reason why we shouldn't since it does just expand a system currently implemented. It falls under the same lines of @autoloot and @autolootid

Oh? Interesting concept to a mining system. Most people use a system that requires a pickaxe and the like. Though explosives, now that's a nice and unique touch to this. Your making steady improvement with your scripting techniques. That is good to see, keep it up, and you'll reach higher levels in no time.

Yes, that is correct. It isn't persistent through a server restart or shutdown. In fact in every case where an NPC sets the cells, it is not persistent, is only through the use of OnInit does it make it reset them every start-up. The point of this small utility is just merely, to allow for on the fly setting. It was not intended to be a permanent setting until unset. If that is needed then they should create a script which will set those cells that way.

What you need may just be this: http://rathena.org/board/files/file/2240-release-script-command-equip2/ Custom Equip2 command, allowing you to equip a specific item following arguments similar to getitem2 command. This way you don't need to loop through their inventory to equip the item you want.

Well, for one I wrote the script 1 year ago, when I was JUST getting back into scripting, so I was very rusty after a 2-3 year break. However, the issue seems to be with the OnPCKillEvent, somewhere down the line, I completely wrote that wrong. Aside from a few variable changes, that seems to be the main problem. In my preliminary tests earlier today, thats what I've come to suspect i the problem.

I posted in the Original Topic, that I think you may not have the Zombie King enabled on your server, since thats the VERY first zombie to spawn. I tested it and I didn't get D/C'd. However, the script also doesn't seem to work. @LilTroll - Feel free to remake it as you see fit, because I just don't have the resources atm to rewrite and test such a script. Resources being people lol. If it were something easy to test then sure no problem, but multi-player scripts such as this, require alot of time to test, and actual people to find bugs in a so called stress test, also in order to balance it to fit needs, alot of people must be involved as 1 person can't think for a hundred.

You need to apply that "patch" to your svn by using Tortise SVN or another patch program you are familiar with.

Your issue may be the Zombie King mob. You might not have it installed either that or it was removed from the grf at some point.

Then what you need is this: http://rathena.org/board/topic/60817-extended-vending-system-18/ However, I don't know how to limit it to your needs, though, with this src edit, you can vend using Zeny/Items. Currently you just can't make it limited to a specific map. You can head to the src_request section and try to get those changes, OR you can just have GMs monitor these vending maps closely and distribute the proper punishment as necessary.

That's because when you normally use that skill, your unable to move until you use Adaption. As a result neither can the monster, try making them use Adaption afterwards.

So let me know if I got this correct. 1. You want Vending in Prontera, to use Zeny as currency. 2. You want an Item to be used as currency while shopping at your Mall section?

No, you can't get current HP of a monster through current means. Which is why you'd need a src edit. Preferably just a custom command that will inflict a status effect at the ratio given by your formula. This would be done on the src side, where the script side, would just require arguments such as this: sc_mob(<gid>,<status effect>,<duration>); //Gives X mob, Y status effect, for Z duration at the formula listed in the src edit. Of course there are better ways to go about this, such as fine tuning as well as making commands to fetch current HP of a monster, but for now this seems like the easiest to do.

I see, well, even if you DO create the OnPCAttack Label, or any of the other 4 listed in that topic, the fact remains you still need the command, which inflicts a status effect upon the target with a % chance calculated using your formula. Best of luck

What your asking for currently isn't possible. Doing so would require either one of 2 different things. 1. Either edit the src to make a custom trigger_event for mob skills which states that X skill is activated upon killing an opponent. (Currently is not available). OR 2. Create a custom script_command (also requires src edits) that will give X mob Y status effect. This method also requires the need to obtain that specific monsters GID (unique ID given to each entity in RO. Example: Player logs on Char 1, his GID = 1. He logs out, then logs in as Char 2, his GID = 2. Logs out again, then back in as Char 2, his GID = 3.) Granted GID's don't increase in this numerical order, it is safe to say, the GID changes each and every time you log in and out. Lastly each mob has a different GID. So in this case option 1 is currently you best bet. You should take your request to the src_request section.

This issue has been reported to the bug tracker a few times already, currently a solution hasn't been released yet.

IMO rAthena is far more developed than eAthena and organized. eAthena may focus on pre-RE, however, it has multiple "branches" that focus on other aspects, such as 3ceAM which is focused more on RE. All in all it's fine, but the difference between eA and rA that I think stands out the most, is it's DEVs and svn policies. Honestly, it appears that eA's Dev's update at a well mildly slow pace, where as rA is on a steady albeit slow at times, updating pace. On top of that, eA is rarely flexible with the addition of features developed by it's community. Where as rA is more open to the addition of certain features, provided it can be of benefit for a large community vs just making life easier for 1 person. All I can say after this is that it is up to you on what emulator to use, however, keep in mind that this forum is rAthena, therefore alot of scripts and code created here aren't done so with the intent of it working on eA emu's, so if your coming here for things like that, then you may want to consider switching over to make it easier on you, rather than having to convert the scripts and code to an eA compatible one.

Really? Hmm, it's been counting as negative in a few of my scripts O.o; Well, time to change them around to prevent future errors lmao. Oh wellz, Edited my post.

That's no problem. Everyone who starts scripting for rAthena, is in the same boat in one way or the other. ! - Logical Not. Reverses the boolean result of an expression. True will become false and false will become true. Example: if(!callfunc("F_dosomething")) { mes "Doing something failed."; close; } In the case I used it can be seen as that 1 = True and Anything Lower is False. General Rule of thumb is the following: True = +/- Numbers Fase = 0 Example: set @bonus,1; if( !@bonus ) { this won't be shown, because @bonus is TRUE not false. } else { this will be shown because the above didn't } Additionally, it can be seen as this to check if the statement is TRUE instead of false. set @bonus,1; if( @bonus ){ this will be seen, because I'm checking to see if @bonus is "true" instead of false } else { this will not be shown because the above was true } I may not have given the best explination/example for this, but if you were to read / briefly skim through: https://github.com/rathena/rathena/blob/master/doc/script_commands.txt You'll learn all you need to know and more. And ofcourse, you can always come back to the script_support section for further help.

*getmapflag("<map name>",<flag>{,<type>}) This command checks the status of a given mapflag and returns the mapflag's state. 0 means OFF, and 1 means ON. See 'setmapflag' for a list of mapflags. The optional parameter 'type' is used in the 'skill_damage' mapflag: 0: if mapflag is set (default) 1: damage against players 2: damage against mobs 3: damage against bosses 4: damage against other 5: caster type Example: OnPCLoadMapEvent: if ( getmapflag( strcharinfo(3),mf_town,0 ) ){ @killcount = 0; sc_end ITEMBOOST; } end;

Player's Level BaseLevel - Character's base level. Monster's Level *getmonsterinfo(<mob ID>,<type>) This function will look up the monster with the specified ID number in the mob database and return the info set by TYPE argument. It will return -1 if there is no such monster (or the type value is invalid), or "null" if you requested the monster's name. Valid types are listed in 'db/const.txt': MOB_NAME 0 MOB_LV 1 MOB_MAXHP 2 MOB_BASEEXP 3 MOB_JOBEXP 4 MOB_ATK1 5 MOB_ATK2 6 MOB_DEF 7 MOB_MDEF 8 MOB_STR 9 MOB_AGI 10 MOB_VIT 11 MOB_INT 12 MOB_DEX 13 MOB_LUK 14 MOB_RANGE 15 MOB_RANGE2 16 MOB_RANGE3 17 MOB_SIZE 18 MOB_RACE 19 MOB_ELEMENT 20 MOB_MODE 21 MOB_MVPEXP 22 For more details, see the sample in 'doc/sample/getmonsterinfo.txt'. So for you it would be something like this: OnNPCKillEvent: @bonus = ( getmonsterinfo(killedrid,1) - BaseLevel ); // killedrid is the ID of the monster killed. if( !@bonus ){ @bonus = 1; } @score += (1 + ( getmonsterinfo(killedrid,1) / 2 ) + @bonus); end;