plankt

Try to change the values to 0.

You wouldn't like to show the global broadcast for everyone at login tho. I'd do like this: -%tab%script%tab%vote%tab% -1,{ OnClock0100: OnClock0500: OnClock0700: OnClock0900: OnClock1300: OnClock1500: OnClock1700: OnClock2000: OnClock2200: OnClock2400: OnInit: announce "Hallo Liebe Spieler, Bitte vergesset nicht zu Voten unter blablabla.",bc_all,0xff1414; end; OnPCLoginEvent: announce "Hallo Liebe Spieler, Bitte vergesset nicht zu Voten unter blablabla.",bc_self,0xff1414; end; } The broadcast would be seen by all at the times, and only for the user when he/she logs in.

You can easily tell if it's an issue with SQL write permissions. Try logging out at a different spot from where you login. If you return to the previous place, it's SQL related.

Small: 2 Big: 4 AI: 8 Small and AI: 2+8 = 10 Big and AI: 4+8 = 12 You enter the red values as event.

Is it the rebirth system or another script you have which resets the stats? Or is it an unknown "bug"?

If you want to change between 1029, 1030, 1031 and 1032 you write: The green is the start value. The red is how much it can increase at the most.

If I understand you correctly, if they get rewarded 7 days in a row, you want them to get a better reward. One way to do this is to keep track of: 1) The last day they were rewarded 2) How many days in a row they have been rewarded And when they get rewarded, you check if it's a subsequent day. If it is, increase the day count, if not set it to 0. If it reaches 7, they have been active for a week.

Re-upload your script on http://upaste.me/ with correct intendation (tabs and spaces). Check the NPC header, the red part: Try removing everything except the NPC header to check if it spawns. If it doesn't, then the problem isn't with the code but with the loading of it.

You should http://upaste.me/ the script with intendations (tabs, spaces etc). If you want to use a list of mobs, you can change: for (set .@k, 0; .@k <getarraysize($Forbidden); set .@k, .@k+1) { if ($monster == $Forbidden[.@k]) { To for (set .@k, 0; .@k <getarraysize($Forbidden); set .@k, .@k+1) { if ($monster != $Forbidden[.@k]) { And it will treat the array $Forbidden[] as a list of monsters it is allowed to use. It will only use monsters in that list. Note that it will only be able to randomly choose monsters between 1001 and 1950 unless you edit this row and change the red to a higher number:

The NPCs that are on prt_are01 are all in npcquestsskillsrogue_skills.txt You can disable them by removing or moving them.

The 15 in "bonus2 bSubEle,Ele_Water,15;" is in %. So that's 15%. Same for all of them.

Setting the event field to 4, for a big monster, would give you:

https://rathena.svn....pt_commands.txt <map name>,<x>,<y>,<xs>,<ys>%TAB%monster%TAB%<monster name>%TAB%<mob id>,<amount>,<delay1>,<delay2>,<event>

Survey time! I've been working on application development for smartphones recently and it would be great to see what kind of phones everyone got. If you fill out an option that's not iPhone, please reply with: screen size, ex: 4.5'' version, ex: Android 2.2 If you don't know your screen size, you can respond with your cellphones name or model. Thanks in advance.

Doesn't this has anything to do with pings? (clif.c) void clif_parse_TickSend(int fd, struct map_session_data *sd) Might be way off tho.

This contest wasn't made for the prize as "about the contest" states, the prize was just more of a fun thing. I guess people just aren't interested in these kind of activities.

Update: No entries for two weeks in a row. Since there's no interest the contests are stopped for now.

I guess the first one is at 'rAthenanpckafrascool_event_corp.txt', the other one should be in the kafra folder aswell.

Those are good suggestions for events and could give participants some tips. As for categories, Survival and Pirates would be fun to have A preview schedule will be posted at the end of this week to give a hint of coming categories.

That's a good point. I'll leave it up to the participants to decide how many to eliminate. Not all elimination systems work well with a 60% limit.

Update: New category posted! Deadline 29/1

You could, theoretically, just add the script twice (or more times) and do these changes to the copy: Change: prontera,155,188,4 script Banquet Houseman 109,{ To: -<tab>script<tab>BH#<tab>-1,{ Where # is the current copy And make sure that they have different '.map$'. That should give you two of the same event, sharing queue, without them messing with each other noticeably

Thanks for the comments! Mysterious, This event is made for single players since it adjusts the difficulty but I've thought about it and might add the feature of joining as a party later on. MisterLayzee, The queue systems topic is here, I'm glad if you post issues and suggestions regarding it there to bump it a bit The queue system itself just handles putting people in queue and returning the AIDs you want. You can have many events working with the same queue if you just use the same number for all of them. In that way you have full freedom in handling rooms etc in your code. The queue itself isn't limited in size as long as your database can handle it, so you can put thousands of people in the queue but you can only take out 127 players at a time.

It seems like you're missing the 'end;' above 'OnPCLogoutEvent:' in the NPC 'queue_main'. The download should have it in place, if you still get the same error message, check from line 30 in 'queue.txt' that is looks like this: end; // Removes a player or the party from the queue if they log out. OnPCLogoutEvent: set .@id, getcharid(3); Please re-download the 'queue.txt' Version 1.01.

Thanks for the input KeyWorld The getcharid(3) was a later input to make sure I re-attached the right player after checking party members, guess I missed that I had the ID already, bad habit when coding at night ^^ The '$@pull_lock' is there to make sure the '$@vars' aren't overwritten until the scripter has been able to save them locally in their script. As for the '$@pull_lock, 0;' before the return, it should definitely be there. I think I accidentally removed it in an attempt to make the code section within the lock smaller. As for input checking, seeing this function wants as little code executed as possibly for speed, not that it's been though optimization yet, but I chose to rely on the scripters ability of giving input. I'll probably add some kind of input check in the next release. The user is automatically removed from the queue when logging off so there's no chance to switch characters unless they can bypass the log off event.