ToastOfDoom

@manabeast You can either increase the update time of the banner to something longer (default 10 sec) set .banner_refresh_rate, 10; //how many seconds per banner refresh...keep 1 or above (in seconds) Or you can completely remove it by changing the WoE Info NPC as so: FROM: prontera,163,194,4 script WoE Info 837,{ if(getwaitingroomstate(3, strnpcinfo(3)) == -1) donpcevent strnpcinfo(3)+"::OnInit"; doevent "WoEInfoBase::OnStartMenu"; end; OnInit: while (1) { //only updates if msg is different set .banner$, getwaitingroomstate(4, strnpcinfo(3)); if(getvariableofnpc(.roomMsg$, "WoEInfoBase") != .banner$) { delwaitingroom; waitingroom getvariableofnpc(.roomMsg$, "WoEInfoBase"), 0; } sleep 500; } end; } TO: prontera,163,194,4 script WoE Info 837,{ doevent "WoEInfoBase::OnStartMenu"; end; }

Have a minor optimisation. http://pastebin.com/TUZBLnr0 The idea is you loop once when the script loads, instead of loop every time a player enters a map. Also sets up the loadevent mapflags dynamically so no need to set outside the script. =D

I'm sure someone can make bots do any of the following depending on the botter's skill: Click NPC at specific spot. Click NPC of specfic name. Search for any NPC in a certain area. Randomizing name, location and menus would hinder them but won't make it completely bot proof. It's all a matter of time and determination. Yes that is what I meant. You could block people of the same IP from playing the game, but as I said before this would block out people that play together on lans or net cafes. If you put them on the same team, noone gets blocked and noone can farm points/prizes by teamselves (at least by only using 1 IP) Put all the players into an array. Shuffle the array. Split the array in half. First half is team A, second is team B. You want to use the battleground commands for this. (maybe some additional ones that let you setup bg without chatrooms)

Toasty's Warper by: ToastOfDoom So this is a project I've been working on and off for a while and only really just had it done to a release standard recently. The original reason I started this script was cause of Annie's Favorite Warper script. While pretty original in that I think it was the 1st one to implement a favorites menu in a warper, I absolutely detested how ugly that script looked. No offence to annie, but it looked like an absolute nightmare to configure (menu structure in one area, warp data in another, lots of duplicated data all over the place making it very easy to make a mistake). So I set out to write a warper that meets this one objective: Be able to portray the configuration of all map and menu structure data in a single glance. Features: Easy to configure layout Zeny cost configuration on menu/submenu/map levels Configurable dynamic access to menus and maps Remembers last warps Brain hurting complexity in other parts of the script (not guaranteed) Download: ver 1.32 - 21-04-2011 (r14682 trunk) ver 1.31 - 27-04-2011 (r14682 trunk) ver 1.30 - 26-04-2011 (r14682 trunk) ver 1.20 - 12-02-2011 (r14682 trunk) ver 1.10 - 13-01-2011 (r14413 trunk) ver 1.00 - 08-01-2011 (r14413 trunk) Mirrors: ver 1.32 - 21-04-2011 (r14682 trunk) How to configure: Look for the 'LoadData' label in the script (line 184). All menu and map data is stored in this one subroutine. Configuring the menus is as easy as moving lines around. Details for each function as follows. AddLastWarpNode(): Will add a menu item to access previously used warps. The maximum amount of stored last maps is 64, however by default it has been set to 10 (.numLastWarps) AddNode(<node_name>{, <modifier>, <modifier_value>{, <modifier>, ...}}): This will add a submenu to the current menu. The cost value for zeny is optional. The cost value will carry on to all nodes and maps within the submenu unless overwritten but another cost value either at a lower node or map. Setting cost to 0 will cancel any costs from being carried down. //Eg. This will make a menu called "Dungeons" with a menu called "Abbey, Cursed Monastery" within StartNode("Dungeons"); StartNode("Abbey, Cursed Monastery"); AddMap("Abbey, Cursed Monastery - Level 1", "abbey01", 51, 14); AddMap("Abbey, Cursed Monastery - Level 2", "abbey02", 150, 11); ... EndNode(); EndNode(); EndNode(): This will exit the current menu that was opened with AddNode() and go back to the parent menu of that menu. Consider it like brackets. All StartNode()s must end somewhere with an EndNode(). AddMap(<map_title>, <map_name>, <x>, <y>{, <modifier>, <modifier_value>{, <modifier>, ...}}): This will add a map to the current menu. //Eg. This will make a menu called "Towns" and place 5 maps within StartNode("Towns"); AddMap("Alberta", "alberta", 28, 234); AddMap("Aldebaran", "aldebaran", 140, 131); AddMap("Amatsu", "amatsu", 198, 84, 5000); AddMap("Ayothaya", "ayothaya", 150, 163); AddMap("Comodo", "comodo", 209, 143); EndNode(); Modifiers: With the 'AddNode' and 'AddMap' commands you are able to add modifiers to either give a set price or dynamically allow access to the specified menu or map (and some other things). All modifiers will cascade down all children nodes until overwritten by another modifier. You can apply multiple modifiers but only one of each (ie..can't use 2x "gm" modifiers, but you can use 1x "gm", 1x "woe") Descriptions of all avaiable modifiers and examples follow: "zeny" - This sets a zeny cost to either all maps within the set node or the set map depending on how it was used. //Eg. This will make all maps within the 'Dungeons' menu cost 1000z StartNode("Dungeons", "Zeny", 1000); StartNode("Abbey, Cursed Monastery"); AddMap("Abbey, Cursed Monastery - Level 1", "abbey01", 51, 14); AddMap("Abbey, Cursed Monastery - Level 2", "abbey02", 150, 11); ... EndNode(); EndNode(); "gm"- This limits access to the menu/map according to the player's gm level. If set to positive it will check if the player's gm level is above or equal. If set to negative, it will check if the player's gm level is below or equal to the absolute of the value //Eg. This will make all maps within the 'Fields' menu accessible to only GMs above or equal to level 20 StartNode("Fields", "gm", 20); StartNode("Amatsu Fields"); AddMap("Amatsu Field 1", "ama_fild01", 190, 197); EndNode(); StartNode("Ayothaya Fields"); AddMap("Ayothaya Field 1", "ayo_fild01", 173, 134); AddMap("Ayothaya Field 2", "ayo_fild02", 212, 150); ... EndNode(); EndNode(); //This will make all maps within the 'Fields' menu accessible to only players below or equal to level 40 StartNode("Fields", "gm", -40); StartNode("Amatsu Fields"); AddMap("Amatsu Field 1", "ama_fild01", 190, 197); EndNode(); StartNode("Ayothaya Fields"); AddMap("Ayothaya Field 1", "ayo_fild01", 173, 134); AddMap("Ayothaya Field 2", "ayo_fild02", 212, 150); ... EndNode(); EndNode(); "woe"- This limits access to the menu/map according to the current state of WoE. This relies on the OnAgitStart/OnAgitEnd events at the end of the script. //1: active when woe inactive //2: active when woe active //3: active regardless of woe setting(default) //Eg. This will only allow access to the Castles menus and maps when WoE is active StartNode("Castles", "woe", 2); StartNode("Aldebaran Castles"); AddMap("Neuschwanstein(Aldebaran)", "alde_gld", 48, 83, "mapUsers", "aldeg_cas01"); AddMap("Hohenschwangau(Aldebaran)", "alde_gld", 95, 249, "mapUsers", "aldeg_cas02"); ... EndNode(); EndNode(); "job"- This limits access to the menu/map according to the player's current job. Calculation method is exactly the same as the one used for jobs in item_db (ie..add up the bitmasks) (S.) Novice (2^00): 0x00000001 Swordman (2^01): 0x00000002 Mage (2^02): 0x00000004 Archer (2^03): 0x00000008 Acolyte (2^04): 0x00000010 Merchant (2^05): 0x00000020 Thief (2^06): 0x00000040 Knight (2^07): 0x00000080 Priest (2^08): 0x00000100 Wizard (2^09): 0x00000200 Blacksmith (2^10): 0x00000400 Hunter (2^11): 0x00000800 Assassin (2^12): 0x00001000 Unused (2^13): 0x00002000 Crusader (2^14): 0x00004000 Monk (2^15): 0x00008000 Sage (2^16): 0x00010000 Rogue (2^17): 0x00020000 Alchemist (2^18): 0x00040000 Bard/Dancer (2^19): 0x00080000 Unused (2^20): 0x00100000 Taekwon (2^21): 0x00200000 StarGladi (2^22): 0x00400000 Soul Linker (2^23): 0x00800000 Gunslinger (2^24): 0x01000000 Ninja (2^25): 0x02000000 //Eg. This will only allow access to the Payon dungeons to Wizards and Hunters and only when WoE is inactive StartNode("Payon Dungeon", "job", 0x00000A00, "woe", 1); AddMap("Payon Dungeon - Lvl 1", "pay_dun00", 21, 183); AddMap("Payon Dungeon - Lvl 2", "pay_dun01", 19, 33); AddMap("Payon Dungeon - Lvl 3", "pay_dun02", 19, 63); AddMap("Payon Dungeon - Lvl 4", "pay_dun03", 155, 159); AddMap("Payon Dungeon - Lvl 5", "pay_dun04", 201, 204); EndNode(); "upper"- This limits access to the menu/map according to wherever the player is a normal/high/baby class. Like with 'job' this works the same as the 'upper' value in item_db. //1: Normal jobs //2: Upper jobs //4: Baby jobs //Eg. This will only allow access to the casino to baby classes AddMap("Casino", "cmd_in02", 179, 129, "upper", 4); "gender"- This limits access to the menu/map according to the sex of the player. 0 is female, 1 is male, 2 for both. "blvl"- This limits access to the menu/map according to the base level of the player. This works exactly the same as with "gm" except with baselevels instead of gmlevels. "flag"- This will limit access to the menu/map depending on the value of a specified variable. This is very useful for restricting access to things when an event is on or wherever the player as passed a certain quest. //Eg. This will only allow access to the guild dungeons if the global variable $@testEvent is not set to 0. StartNode("Guild Dungeons", "flag", "$@testEvent"); AddMap("Baldur Guild Dungeon", "gld_dun01", 119, 93); AddMap("Luina Guild Dungeon", "gld_dun02", 39, 161); AddMap("Valkyrie Guild Dungeon", "gld_dun03", 50, 44); AddMap("Britoniah Guild Dungeon", "gld_dun04", 116, 45); EndNode(); "function"- This will limit access to a menu/map depending on the output of a specified function. Works very similar to the 'flag' modifier only will allow greater control but is also alot more computationally expensive. Recommend only using when needed and to keep things simple in the function. The script will automatically pass the following variables to the function: //Node: "Node", <nodeid>, <nodename> //Map: "Map", <mapid>, <maptitle>, <mapname>, <mapx>, <mapy>, <mapcost> //Eg. This will only allow access to the Thanatos tower to players that are in a party and above or equal to level 90 StartNode("Thanatos Tower", "function", "PartyCheckFunc", "blvl", 90); AddMap("Thanatos Tower - Lvl 1", "tha_t01", 150, 39); AddMap("Thanatos Tower - Lvl 2", "tha_t02", 150, 136); AddMap("Thanatos Tower - Lvl 3", "tha_t03", 220, 158); AddMap("Thanatos Tower - Lvl 4", "tha_t04", 59, 143); AddMap("Thanatos Tower - Lvl 5", "tha_t05", 62, 11); ... EndNode(); ... function script PartyCheckFunc { return strcharinfo(1) != ""; } "mapUsers"- This will change the map used for the getmapusers() calculation. This allows you to warp to one map, but display the user count for another map (like for castles) Other Settings: .showNodeUserCount: 0/1 turns on/off the user count display for nodes/menus .showMapUserCount: 0/1 turns on/off the user count display for maps Important Notes: In the case that you add a map that doesn't exist a message will be displayed within your map server console indicating the name of the map. There is a limit to the length of the menu can reach. This limit is defined by 2047 characters. When this limit is reached the client will crash. The script has measures to prevent client crashes, but the menu in question will still be broken. A message in the map server console will display indicating the affected menu. Please modify the structure of the menu to prevent the overflow. Additionally all GMs above the set .gmAccessLvl will have the option to check which menus will overflow. Likewise this overflow problem will also affect the lastwarp menu so it is advised you keep the .numLastWarp value to a reasonable value (10-20) Technical stuff: Just some data on the structure of the script for those who want to modify functions (read this if you are interested in picking apart the script) ShowMenu(): Displays the menu and returns the map id of the selected map ComputeMenu(<menu_ptr>): Generates menu string. Modify this to change how you want the menus to look SelectMap(<mapid>): Does the final zeny subtraction and warping to the map after selection. You can modify this to have it do other things with the cost value (eg, subtract coins instead) All map data are stored in an infinite style array of the following names: # = index / 128, % = index % 128 .maps_name_#[%] .maps_map_#[%] .maps_x_#[%] .maps_y_#[%] .maps_cost_#[%] Node data are stored in the following manner: node_ptr$ = .menu_<nodeid>$ node[0] = Node title node[1] = Basic precomputed node menu string node[2+] = Either a pointer to a map or another node_ptr$. If it is a number it is a map id otherwise it is the menu pointer for the next submenu. Last warp menu is simply a pointer to "@menu_lastwarps$" As always will appreciate bugs reports, suggestions & criticism. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License

Toasty's WoE Controller So...once upon a time when I did have a server to run and one of the few questions that would always come up was..."What time was WoE and what region was it?" (WoE on this server was broken up into regions). Usually I didn't know the answer and so I had to go through the awful task of trying to find it in the forums and eventually I just directed everyone to it. And then there's the issue with people not understanding timezones or knowing how to substract. Soo...one day i got off my lazy ass and wrote this little thingymabob that would tell people exactly how long left it is till WoE, where it was and other random tiddy-bits of info. Worked pretty well. Anyways...just recently I was pretty bored and decided to clean it up abit and thought...well...since it's already keeping time..why not just let it do all the agit_controller stuff too. So I added that and presto!....this came out." Features: WoE 2.0 ready Novice WoE ready Real-time updated time display of how much longer till WoE starts/ends WoE configurable on a Castle level basis Useful castle owner listing feature Even more useful region map warper feature Some random skip/start/end WoE functions for GMs Auto-Restart WoE after server crash Now with a mildly easy to use online generator script. Though tested on trunk, will very much likely work on stable (provided you tick the correct box while generating the script) Description: Basically what you get is a little banner NPC with a chatroom on it who's title updates with the amount of time left till WoE starts or ends. (Little idea stolen from one of annie's scripts =P...some mvp arena i think) Clicking on the NPC (the npc not the chatroom) opens up a menu with a couple useful options which are self-explanatory. Note: Castle Owner listing is only for castles of the current/upcoming WoE session. Too much spam to print all Scripts: ver 1.22 - 26-05-2011 (r14829 trunk) (Mirror) (Mirror) ver 1.21 - 21-12-2010 (r14413 trunk) ver 1.20 - 18-10-2010 (r14413 trunk) ver 1.11 - 25-01-2009 (r13435 trunk) ver 1.10 - 03-01-2009 (r13405 trunk) ver 1.02 - 09-10-2008 (r13271 trunk) ver 1.01 - 21-09-2008 (r13091 trunk) ver 1.00 - 10-09-2008 (r13091 trunk) Backup ver1.22 Installation: Generate the script by inputting the times you require and any options you may want in the generator form Install the script as you would for any NPC. Depending if you want to use this to replace agit_controller.txt or not you can replace the contains of ./npc/guild/agit_controller.txt with this script. IF you use this script to manage your WoE timings (which you prob would..). Remove any existing WoE timing management scripts. By default... ./npc/guild/agit_controller.txt -if you didn't replace it with this script ./npc/guild2/agit_start_se.txt -for woe2 controller If you want to use any of the Novice castles make sure you enable them in ./npc/scripts_athena.conf npc: npc/events/nguild/nguild_dunsw.txt npc: npc/events/nguild/nguild_treas.txt npc: npc/events/nguild/nguild_guardians.txt npc: npc/events/nguild/nguild_warper.txt npc: npc/events/nguild/nguild_ev_agit.txt npc: npc/events/nguild/nguild_flags.txt npc: npc/events/nguild/nguild_managers.txt npc: npc/events/nguild/nguild_kafras.txt Restart/Startup server...enjoy =D Limitations: Since WoE can be run in pretty much any format, it's kinda impossible for this script to accommodate for all types of WoE. Anyways...here are the limitations of this script. WoE sessions have to start and end on the same day (usually the case but good to state) Only one WoE session is available at a time. In order to start another one, you must end the current one. The generator will complain if you try to overlap sessions. Standard array/variable limits. 128 for number of WoE sessions and separate regions. 31 different castles per region(Not that anyone is gonna use all that...unless they're planning like an all world WoE extravaganza). Time is actually updated using an infinite loop. Depending on the refresh rate setting timing can be off sync with the time WoE actually starts/end (default 500ms/half a second. This isn't a problem if you are using the built in controller) Due to the way in which the original WoE scripts were coded and how I implemented the castle based controller (calls OnAgitEnd/2 events) castles MAY remain open if they do not have an owner. Notes: Yup...idea for timer based waitingroom was stolen from annie's Mvp Ladder script This script is semi-protected against @reloadscript/@loadnpc commands. Though not recommended that you load the script using this manner, if you must after loading the scripts, to restart the script click each NPC (one NPC only needs to start to initialise the floating main script that controls the WoE timing, but each banner NPC needs to be clicked to start the waitingroom) When doing the timings, it is VERY IMPORTANT that you have the times in order from sunday to saturday and starting time. If you don't do this it'll skip over them till the next week. WoE happens in the order that the timings are specified. Sometimes it may be desirable to have them out of order so it can do one region this week and another one a different week...But this is only a side-effect to the timing design and weird things might happen..so do it at your own risk. (This is no longer a problem in ver 1.10 provided you didn't mess with the config after generating the script) You can change the rate at which the banner is updated by modifying the ".banner_refresh_rate" value in the CONFIG section. The banner will update every '.banner_refresh_rate' seconds. This script is rather dynamic and so adding additional castles just involves modifying and adding arrays. Adding castles to existing regions should be self-explanatory. But setting up a new region...maybe not.. Steps to setup a new region are as follows: Make up a prefix for the region you are adding (in this example I am using "test" Put all the maps for the castles in an array named ".castles_***" (eg. .castles_test$) Put all the put all the woe ending function addresses into an array named "woe_kill_***" (eg. .woe_kill_test$) Go to the constants section in the script (search for CONSTANTS START) Add the castles and portals in the corresponding sections Add the prefix to the end of the array .regions$, the name of the region in .region_names$ and the map that contains all the castle entrances in the array .region_maps$ Tah da!! you have now added a new region. Feel free to test the hell out of this and report bugs/suggestions/criticism. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License

Part 1: Not very effective against bots. They can 'click' NPCs alot better than humans. Part 2: Thats not a bad way of doing it but not 100% effective. One way possible to prevent self farming is to force all the people with the same IP on to the same team. This way they have no possible way to fight against themselves but also if it's actually some folks playing at a net cafe or at a lan you're not preventing them from playing the game.