Euphy

- script #sample -1,{ OnNPCKillEvent: if (killedrid == 2200 || killedrid == 2201) { set .@map$, strcharinfo(3); getpartymember getcharid(1),2; for (set .@i,0; .@i<$@partymembercount; set .@i,.@i+1) { if (attachrid($@partymemberaid[.@i])) { if (strcharinfo(3) == .@map$ && Hp > 0) getitem 607,1; detachrid; } } } end; }

'announce' takes a string, so add a null string ("") to your integer to make it a string. announce ""+$@kc,bc_map;

Added another set of coordinates in r17224 until official ones are found (this way it works properly for players with the old map). morocc,103,144,0 duplicate(#distorted_space_) #distorted_space_1 139,1,1 splendide,141,284,0 duplicate(#distorted_space_) #distorted_space_2 139,1,1 // This is a temporary fix until new official coordinates are found. morocc,98,144,0 duplicate(#distorted_space_) #distorted_space_1-1 139,1,1

Awesome, thank you! I've updated the initial post with your file.

See this topic: Requesting Card Seller Script

This was fixed in r17221, sorry for any inconvenience this may have caused.

Interesting; I can't find any information on a new coordinate for that quest. o.o

It depends on the situation. Some examples... Scope variables: Arbitrary variables with no meaning, ex. to handle for/while loops or to store random numbers. Anything in an uncommonly-used section of an NPC, where it would serve no purpose to store the data permanently. Scripts where different instances hold different values that should not overwrite each other, ex. storing a player's name in dialogue or other player data. NPC Variables (OnInit): Commonly-referenced variables in a prominent NPC, ex. basic configuration settings in my Quest Shop or WOE Controller. Large, occasionally-referenced arrays or simulated multi-dimensional arrays (setd/getd), where it would be a waste of processing to re-set the values each time the script is called. Stored values in NPCs with many duplicates, since NPC variables are only stored for the main NPC and not its duplicates (i.e. this saves both RAM and processing). NPC Variables (not OnInit): Variable that will be referenced later, after the current script terminates, ex. counts in event scripts. Temporary reference needed in another section of a script where scope variables are not passed (goto/donpcevent), where the variable is generally un-set (to zero or "") after use. (This is very uncommon; I may actually be the only scripter that does this.)

@NeoGenesis: You're not using rAthena; there's an older eAthena-compatible version on their forums (I've dropped support for eA, so you'll have to upgrade to the newer version manually).

@Lemongrass/nanakiwurtz: Added both of you to the list. Please post the translations in this topic when finished. Thanks! EDIT: The list of people working on this project has been moved to the first page.

You're very welcome to do so! You'll have to collaborate independently with anyone else working on the translation -- I'll keep the list updated so that you'll know who to contact. Which language are you taking?

NPC variables consume RAM, that's all. It's better to use scope variables, when possible, since they're erased after use; but commonly-referenced variables should be NPC variables set OnInit (to avoid constant re-setting of variables, or multiple instances of scope variables existing).

You would need to call a script, not a function. Add an event label for your desired spawns to trigger the creation of a treasure chest. For the second part, you haven't given enough details.

@Rage: Added to the list. @jaBote: Thank you for the explanation -- I agree that there should be only one Spanish translation, so any efforts you make in neutrality are greatly appreciated. @Tragedy: Can you and jaBote collaborate on a single translation? (You can divide the map_msg file or review each others' work.)

Try this: http://rathena.org/board/topic/78650-source-documentation/

query_sql("SELECT ID FROM `mob_db` WHERE left(Sprite, 4) != 'meta' AND left(Sprite, 2) != 'E_' AND EXP > 0 AND DropCardid > 4000 AND DropCardid < 5000 AND ID < 2000 ORDER BY rand() LIMIT 1", .@mob); disguise .@mob;

@Paulinds: I remember another user released a similar script using SQL; you should use that instead, since it's bad practice to store so many permanent global variables (this was the first script I released, so it's got a lot of problems XD). @leertaste: No, it's not. The quest log is controlled by db\quest_db.txt and data\questid2display.txt, both of which scripts can't touch.

It's yours. Thanks!

That would be wonderful. Thank you for your support!

Brynner, it's already in the /doc/ directory. trunk/doc/script_commands.txt

Thanks for the hard work, Lilith. Is it possible to instead modify the msg_txt function itself to check for player lang, using the default if nothing is found/no player is attached? As for structure, here's what I think: Store language files in subdirectories, as Cydh posted, to avoid clutter: conf/msg_conf/ - English files (root) conf/msg_conf/[lang]/ - Translations (subdirectories) Define lang directory names in src. Define default directory either in conf (once, in inter_athena or a new file?) or src.

How is it incomplete? The constants are clearly defined with a sample script included. o.o

I don't know why your script didn't work; it was fine. Bryner's explanation is incorrect, both Class and BaseClass are valid variables. See script_commands.txt for further explanation.

This is a fantastic and very reasonable way for rAthena to encompass a larger community. It certainly gets my vote. If no developer disagrees, we can begin work on this immediately. Lilith: Are you able to code the implementation of this, and contribute a Russian translation? To everyone else: If you have the time, please post or let me know if you're willing to write a translation for your native language. We will need, at minimum, one file for each language in our International Forums. That's also an interesting idea; it's not as immediately useful, but worth considering. Let's return to it after msg_conf is finished or under way.