GmOcean

Sounds like a good idea, it's a fairly easy script to make since 90% has been finished with the instance script, the only difficult task now is sifting through everything, and replacing the instance related stuff and converting it into an NPC controlled code, since we aren't using the instance engine so to speak. Sadly, I won't be taking this up since, I hate the way instance dungeons are scripted lol, makes it a pain to find stuffs :/

@Unknown - While it does sound fun to both make and to play, the Kill/Death Ratio will be annoying to work with since, rA doesn't store anything in decimal form. At the most we might just have to compare who has the highest kills, and least deaths, and if the NEXT person reaches that amount of kills, while having the same or less deaths, change them. Kinda sucks, cuz we can't just do the calculations and use a decimal number... oh wellz, we can still make it work though.

*swt* and here i thought I could retire T.T; lol... no.6 xD Well, gonna have to do it tomorrow after work I guess. Who ever feels up to the task please go right ahead and do it to help this person out. Annie has done about 90% of the script, just refer to that when you go to make your version (should you choose to try) it should prove to be most helpful for those wondering how to start this.

Lol, this sounds alot like my juggernaught event script I wrote, with the exception of it being an event, thus making it tremendously easier, since you won't have to keep track of each player in the event, instead just 2-3 variables containing who is a Beserked Godlike, Berserked (not-godlike) and lastly how long has each been as such. Edit: oops, seems i'm REAALLY late on this one lol, Annie has already taken it up =P

You must have accidentally put a different number other than 10, when specifying it's max level. It won't stop at 10 just because it's in the skill tree of another class. You need to specify the max level as well. So look back in your db file, and double check, because it is possible to change the limits based on the class of your choice, for instance making it so Knight gets to use it at only level 5. And swordsman at level 1.

it is, but it requires a src edit on those skills, to call the effects of the @hide command itself. Gonna have to head over to src request section for that

Umm, that script looks like EXACTLY what your looking for, why not just use that one?

mapname,x,y,z script Badge Distributer 123,{ if( gettimetick(2) < KMV_wait_time ) { mes "You can only receive badges once per day."; close; } getitem .itemID, .amt; set KMV_wait_time, gettimetick(2) + ( 3600 * 24 ); mes "Congratulations on reaching the 99th floor."; mes "Here are your daily KMV Badges!"; close; OnInit: set .itemID, KMV_badge_id_number; //Item ID of the item to be given. set .amt, 500; //Amount to be given.

Problem 1 with the NPC announcing the name: //Hint npctalk ""+$@Monster+", "+$MonsterName$+""; Just delete that and it'll go away. As for your second problem, I don't see anything wrong with the script, the timer labels are in place, meaning it would need to take 3 minutes for the event to start. However, you're using an outdated version of this script. You should update it to the one in the rAthena svn by default (assuming you are using rAthena).

Then I think perhaps the issue here, would be that Item Type 11, is slightly misleading lol. A delayed consumption gernally speaking means that it will be consumed eventually and if you're like me, then you probably assumed it meant it would be consumed after X/1000 seconds have passed lol. Could we perhaps just change the description so that it states, Item that will not be consumed upon use.

I agree, that it is unpractical. As Euphy stated, it's too much of a burden on the servers, even if we were to add limiters and filters it would still be too much because even with the use of limiters that would let's say, only allow for the event to be activated 1 time per second, it would still ping the server everytime you attack to see if it is able to trigger the event. That in combination with filters like mapflags would still only slightly reduce the usage, but not so much that it still wouldn't be a resource hog.

I do like the sound of this, since it would mean that the creation of the 'clone' will result in creating a monster almost dynamically on the fly, seeing as how we'll no longer be making a "ninja" monster with use of all skills and and equivalent stats, it'll now effectively reflect your actual character. Which is good, because if we can make clones this way, whats to say we can't expand on the idea, and make it so the clone's and or monsters can now be created through a command, by listing all parameters which would be useful for a number of different scenarios.

You can make rental shops, that appear as normal NPC shops, however doing so would require you make a Dynamic NPC shop, as such it would appear a Normal Shop in which you can buy the item you want with a nice GUI in the front, while the hidden back end, does all the calculations and give them the item with a rent time.

I don't see why not. It would seem like this would be a long over due addition to rA. Also, since the work has been done for us, surely there can't be a real big reason as to why we don't add it. +1 for this.

Then what you'll need to do is the following... 1. Copy and paste the Kafra Functions into a new txt document OR you can just paste it at the very end of the current file. 2. Translate all the text in the functions you just copied (This is why it helps to make a new file instead ). Here is an example: function script F_Kafra { callfunc "F_ClearGarbage"; switch(getarg(0)){ default: case 0: mes "[ Kafra Employee]"; //Translate mes "Welcome to the"; // Translate mes "Kafra Corporation."; // Translate break; case 1: mes "Good bye."; // Translate close; } } After you are done translating all the text, which shown above, is set by the command " mes ". We'll move on to step 3. 3. Now this is where it gets a little tricky / difficult, but you should be able to manage. Your going to be looking for, all of the Labels in your new copy. Most of which should be labeled like so: F_LabelName: all your going to do, is add an extra letter after the F, in your case G for german. Should look like this when your done: FG_LabelName: upon completing that it is time to move on to step 4. 4. Now that we have translated the functions what we need to do is make sure they are called for those using the translation. Look for your kafra employee script file. Which should be located in: rathena/npc/kafras/kafras.txt assuming your using a default kafra. Your going to make translations for all of this text using the following as an example. prontera,146,174,4 script Translator#tr01::Translator 727,{ mes "[Translator]"; mes " * Please choose a language"; mes " * Bitte wähle eine Sprache"; next; menu "English",-,"German",L_Ger; set #language,0; next; mes "[Translator]"; mes "Thank you."; mes "Have fun on " + $server_Name$ + "."; close; L_Ger: set #language,1; next; mes "[Translator]"; mes "Danke."; mes "Viel Spaß auf " + $server_Name$ + "."; close; } and yes that is the code you posted before, so should be easy. Now for #5, were almost done so, don't worry, only 1 more step after this. 5. Now, in that same file, your going to see sections like this: aldebaran,143,119,4 script Kafra Employee::kaf_aldebaran 113,{ cutin "kafra_05",2; callfunc "F_KafSet"; mes "[Kafra Employee]"; mes "The Kafra Corporation"; mes "is always working to provide"; mes "you with convenient services."; mes "How may I be of assistance?"; callfunc "F_Kafra",5,0,1,20,600; savepoint "aldebaran",143,109; callfunc "F_KafEnd",0,1,"in the city of Al De Baran"; } Notice that you see the lines, callfunc "F_XXXXXX",a,b,c,d,e,f,g; and such. Were going to modify it a little using the example of above, but were going to add in our custom Labels we made in step 3. Here is an example. aldebaran,143,119,4 script Kafra Employee::kaf_aldebaran 113,{ cutin "kafra_05",2; if( #Language == 1 ){ callfunc "F_KafSet"; } else { callfunc "FG_KafSet"; } mes "[Kafra Employee]"; mes "The Kafra Corporation"; mes "is always working to provide"; mes "you with convenient services."; mes "How may I be of assistance?"; if( #Language == 1 ){ callfunc "F_Kafra",5,0,1,20,600; } else { callfunc "FG_Kafra",5,0,1,20,600; } savepoint "aldebaran",143,109; if( #Language == 1 ){ callfunc "F_KafEnd",0,1,"in the city of Al De Baran"; } else { callfunc "FG_KafEnd",0,1,"GermanTranslation Al De Baran"; } } When that is complete, we'll move on to the 6th and final, easiest step, atleast in my opinion it's the easiest. 6. If you created a new file in step 1, then all your going to do is add it to your server, the same way you would any other script. Which I can safely assume you know how to do already. However if you didn't make a new file in step 1, then guess what, your done already and you can play your server, with now newly translated Kafras. Enjoy.

Your probably looking for something like this: switch(select(""+ ( (#language == 1)?"German Translation":"Yes" ) +":"+ ( (#language == 1)?"German Translation":"Quit" )+"")) That should do what you want. Atleast for the menu uptions. For the kafra functions just do what the you showed before. Sure, it may take a long time, since you'll have to translate each line and add them in yourself, but just follow the format you posted at the top and you should be fine.

Exactly, as Emistry said, it's not like the VIP system has to be a paid feature, you could make it availble through a multiple of ways. For instance: Do events in your server, collect enough Even Tokens/Points and trade them for either a Timed/Permanent VIP position. OR you could even just give it to players who have been apart of your server for X amount of time. (e.g. Give the player VIP Level +1 for every month they are actively apart of your server, capping at 3-XX months, which ever you choose to stop the VIP level at.) This way, instead of using VIP system as a way to gain money, it could be a way to reward players for being loyal to your server, rather than server hopping around. But to each their own, I personally see the VIP system as an enhancement to RO and definitely not something that will trigger it's downfall by making it P2P.

So what were trying to test here, is that it my be more effecient to calculate the max HP/SP all through src, without the use of a table? Seems, good, but would it not be better to have a db/conf file that does this for us so to speak. Example: db file, will consist of what we have now more or less... and conf file, will just have modifier changes like: //Vit HP percent modifier. Increase HP by x/10000% of MaxHP per vit. ( 0 to disable ) vit_permodifier: 1 //Vit HP Base modifier. Increase HP by x per vit. ( 0 to disable ) vit_basemodifier: 50 //Int SP percent modifier. Increase SP by x/10000% of MaxSP per int. ( 0 to disable ) int_permodifier: 1 //Int SP Base modifier. Increase SP by x per int. ( 0 to disable ) Now, I don't know how realistic or functional this may seem, but if the only reason were changing the calculation is because were not equal to official servers, perhaps were taking the wrong approach in trying to find the right formula and could get it done by doing something like this.

This may not give the exact location on the map however, it will let you know if the monster is alive or not. So it KIND of solves your problem. *mobcount("<map name>","<event label>") This function will count all the monsters on the specified map that have a given event label and return the number or 0 if it can't find any. Naturally, only monsters spawned with 'monster' and 'areamonster' script commands can have non-empty event label. If you pass this function an empty string for the event label, it will return the total count of monster without event label, including permanently spawning monsters. With the dynamic mobs system enabled, where mobs are not kept in memory for maps with no actual people playing on them, this will return a 0 for any such map. If the event label is given as "all", all monsters will be counted, regardless of having any event label attached. If the map name is given as "this", the map the invoking character is on will be used. If the map is not found, or the invoker is not a character while the map is "this", it will return -1. Also additionally, there are @commands that can do this for you. @mobsearch <monster name> Locates and displays the position of a certain mob on the current map. Output Example: 1[155:184] Poring 2[154:188] Poring 3[127:146] Poring --------------------------------------- AND @showmobs <monster name/ID> Locates and displays the position of a certain mob on your mini-map. This shows up as a small white cross (+). Do note, I am taking these at face value, whether or not these apply to monster's summoned by script or not is something you'll have to test for yourself. Should be very easy, just summon a poring/drops in prontera, and use the command, if it tells you it's location (and it is correct "assuming it hasn't walked away like 5-10 cells") then it does work for script spawned monsters. However if it doesn't tell you where it is, or show you if you used the other command, then it only applies to the monsters spawned naturally through the perm-spawn files.

This is not a SRC Help section. Information like this can properly be found and/or requested at the Source Request section of the fourms. Thank you.

This is not a SRC Help section. Information like this can properly be found and/or requested at the Source Request section of the fourms. Thank you.

+1 For this idea. It would make sense to expand on a system that would in turn allow for a more diverse RO experience. Especially since it is not " game " breaking. Also, I agree with Emistry regarding the new commands. However, setting the limit of char slots ingame, probably shouldn't be a command, as it IS only temporary. Meaning a server crash, or restart would render it useless. At these times, it's best to shut the server down for a quick maintenance. But again, I really do think this should be added into rA. Perhaps, we can even tie it in with Guild and Party limit functions. For instance: A Normal Guild can have lets say 36members, a VIP Guild ( can only be created if a VIP member ) can have 36 + VIP*6 members. | A normal party can have 12 members, a VIP party ( can only be created if a VIP member ) can have 12 + VIP*2 members. Although, I do believe the Guild and Party additions may be difficult if at all possible. But as always with these discussions, take it all into consideration. Edit: Also, perhaps there could even be a way to lower/increase zeny prices for VIP members. (Of course this does not apply to vending since those are not set by item_db). Say for instance, I'm a Non-VIP member, and I buy 10 red potions = 500z. However, if a VIP-member makes the same purchase they would or could pay at a discounted price 10 red potions = 450z (10% discount) and this is regardless of being a merchant class with the discount skill. Now, I can see how this wouldn't fit well, with most of the community because 10% + 24% (merchant skill) is 34% discount is absurd. However we could make it check to see which discount is better. Assuming there are 5 levels of VIP 1-5. Each would have 6% discount, making VIP lvl 4 = Merchant skill, and VIP lvl 5 = 30% discount. We could then give players the BEST discount and not a combination of the 2. Example: VIP3 w/ merchant skill lvl 10 buys red potion, they get 24% discount because the skill is higher. VIP5 w/merchant skill lvl 10 buys red potion, they get 30% discount because VIP 5 is greater than Merchant skill. Again, these are all speculation, and are just here to take into consideration. Also do note, that this could be achieved on the script level fairly easily, along with increased potion effects for VIP members (which is self-explanatory ).

The issue here, is that the rA version uses commands such as: implode & explode. Both of which are not apart of eA's standard revision. Also, as for using input box and the like. It shouldn't be too hard to add into the script itself, as that is how I originally created the script to begin with. However due to popular opinion I re-wrote it to use REGEX allowing for " speach " to be recognized.

rathena/conf/battle/pet.conf // Rate for catching pets (Note 2) pet_catch_rate: 100 //100% Capture rate. // The rate a pet will get friendly by feeding it. (Note 2) pet_friendly_rate: 100 //Change to 10000. This should make it loyal after 1 feed. // If your pet is hungry by how much will the friendlyness decrease by. (Default is 5) // Note: The friendlyness is 0-1000 total, at 0 the pet runs away. pet_hungry_friendly_decrease: 5 //Change to 0. Should it ever get hungry, it won't lose it's friendliness. Meaning you can have a very loyal starving pet.

Well, in this case, what about the Endless Tower. Now I do understand that ET is an official instance, where when you die, you either wait to be revived or go back to your SavePoint, and then pay to re-enter. But, it would be alot easier, to just change their save point to the first floor, during the duration of the instance. Now being that ET is an official instance, this obviously wouldn't be needed. However if we are to do this, perhaps something similar to a Temp SavePoint if it's possible, one that will only activate when they are apart of an instance, or more specifically in an instanced map. This is so, if they leave the instance (still apart of the instanced party) they can die freely and return to their original spawn point and not the Instanced one. In other words, an instanced SavePoint will only work while in an instanced map (like I specified earilier..repeats xD). Example: Original Spawn Point = Prontera. Join an instance and etner it. New Temp Spawn Point = Entrance Coordinates / Instanced Mapname. Upon Death - If player dies inside an active instance: Respawn at Temp Spawn Point - If player dies outside of instance: Respawn at Orginal Spawn Point. - If player dies inside an active instance (but not apart of the instanced party - shouldn't be possible -): Respawn at Original Spawn Point As far as I can see, this would be the only practical way to do this. Otherwise, we could get errors, because if we " offcially change " their spawn point to the instanced map, if they leave the party by: /leave command, there would be no way to change their savepoint back, aside from loadmapevent and crosscheck between a stored variable to see if StoreVariable was an instanced map. At anyrate, I am all for this idea, but only if it is done right. The last thing we want to do is, do it half assed, and have people complain that their players are getting errors, because maps don't exist, because they didn't change their spawn points back to ' Prontera ' or something from the instanced map.