Brainstorming

Forget about it... After reading it again I understand that's something wrong. Special Variables retrieve local variables of the character executing script. So, if I want to know mines BaseLevel, both works and first one is better. But if I want to retrieve BaseLevel from someone else, first one won't work.

This is a short example of what i'm meaning. I want to know what do you think is better for script optimization: Using Special Variables: ... mes "Player ID: "+[color=#000000]getcharid(.@CharName$);[/color] mes "Player Sex: "+((sex==0)?"Female":"Male"); mes "Player Level: "+BaseLevel+" / "+JobLevel; mes "Player "+((upper==2)?"Is Child":"Is not Child"); ... Using query_sql: ... query_sql("SELECT char_id,sex,base_level,job_level,father WHERE name = '"+escape_sql([color=#000000].@CharName$[/color])+"';"),.@CH_ID,.@CH_Sex$,.@CH_Blvl,.@CH_Jlvl,.@CH_Father); mes "Player ID: "+.@CH_ID[color=#000000];[/color] mes "Player Sex: "+((.@CH_Sex$=="F")?"Female":"Male"); mes "Player Level: "+.@CH_Blvl+" / "+.@CH_Jlvl; mes "Player "+((.@CH_Father!=0)?"Is Child":"Is not Child"); ... First case: - 1 temp string variable. - 4 Special Variables (Sex, BaseLevel, JobLevel, Upper). - 5 queries (getcharid to retrieve Char_ID and 1 query for every Special Variable). Second Case: - 6 temp variables (2 of them strings). - Only 1 query. What is your suggestion? Case one (less variables, more queries) or case two (less queries, more variables)?

Thanks, you both helped me a lot. After reading quietly your answers and some write - try - rewrite work, It's clearly for me now.

Looks a bit clearly now. Goto sounds for me like a low level statement, so, as I thought, it's faster to emulate. I suppose that every While / For statement is disassembled to goto's sequence, so it was a surprise for me to read this in the manual: About, DoEvent / DoNpcEvent and Functions, I understand that is better to use Functions if you're gonna write them in a separate script file, and DoEvent / DoNpcEvent are better if you are writting a subroutine in the same script file. It's right? My project is an advanced utility NPC for Adminstration. My objective is to male easier to find users, information, ban, unban, etc. I think now atcommands are too many and, sometimes, a bit confusing, so an interactive menu is much more freandly. The FULL structure would be something like this: I know is an ambitious project. First time for me scripting rAthena, but I've already worked with others languages (Assembler, Ladder, C++, Java, PHP, Javascript...). So, I want to do it as optimous as possible from the begining.

Well, I'm working with my first project and there´s a something that I can't understand completely which are the differences between: - Goto - DoEvent / DoNpcEvent - Functions Well. I know Goto must be avoided if possible, but I find it really similar to DoEvent / DoNpcEvent statements. In addition, Functions works pretty similar to DoEvent / DoNpcEvent statements (in both cases, you are creating a subroutine). So... I know that they are 3 different things for differents purposes, but at this time it's a bit blurry for me to see the limit between them. Could someone explain me the differences and tell me wich one is the best option in each case? At least a little example to clarify mi mind. I've looked for another support topics and also have checked Wiki and manual, but it's still confusing for me. Thanx a lot and sorry for my bad english!

Hola, me cree la cuenta porque me pareció interesante tu propuesta, y por ello mismo quería dar una perspectiva propia desde mi experiencia en trabajos de traducción (de anime, en mi caso). Espero no ofender y que sepan sacarle el jugo a mis consejos: 1- Por regla, colocar el traductor de Google como herramienta útil converge en una sobre-explotación de dicha herramienta, al punto que los traductores, al poco tiempo, se limitarán únicamente a copiar el texto en inglés, pegarlo allí y reemplazar con el resultado obtenido. En mi caso (el del fansub) o en cualquier otro proyecto de traducción serio, quien utiliza el traductor de manera más que ocasional o de consulta, esta fuera y no es apto para participar (al menos no como traductor principal). 2- Colocaste un puesto con el nombre de "Revisador". Te sugiero corregirlo. Si llevarás adelante el proyecto de traducción, tu mejor amigo debería ser la RAE, y si buscas, la palabra "Revisador", no existe. Por lo que interpreto, el nombre adecuado debiera ser "Corrector" 3- Llevar un proyecto no es sencillo, te recomiendo que busques analogías en proyectos similares para evitar errores que, con frecuencia, solo conducen al fracaso. Por ejemplo, observa como trabajamos quienes llevamos un fansub. Hay 3 puestos en el fansub que comparten ciertas características con tu proyecto: traductor, corrector y quality checker. El traductor, claramente, traduce. Pero limitar su definición a ello, es muy pobre e inexacto. Por traducción nosotros entendemos una correcta sintaxis y semántica de la oración. Es la base del proyecto, si falla el traductor, el proyecto fracasa. El corrector cumple una función muy importante, pero diferente a la del traductor. El traductor (en este caso) transformará el texto en inglés en un equivalente al español sintáctica y semánticamente correcto. La función del corrector es validar y corregir esa sintaxis y semántica en relación a la versión original. El corrector no debiera tener que corregir errores ortográficos (salvo que sean leves, como acentos). Si lo tiene que hacer, entonces el traductor no está realizando bien su tarea. Por último, el quality checker es quien da el visto bueno a la traducción en su totalidad. Si, bajo su criterio, hay errores de algún tipo, no los corrige, sino que rebota el proyecto y marca los errores que encontró, o bien, hace llamados en donde quedan dudas de interpretación. 4- Asociado a la tarea del traductor y el corrector, algo que creo necesario destacar (y ya comentó Leeg algo al respecto). Al hablar o escribir nosotros comunicamos algo, enviamos un mensaje. Lo que importa es que el significado de dicho mensaje sea el mismo en inglés y en castellano. A veces, hay palabras o frases que tienen significado solo en inglés (por ejemplo, juegos de palabras) o que bien, su traducción literal puede generar confusión. Un buen traductor debería leer en inglés, interpretar el mensaje y escribirlo con sus palabras en español de la manera más fiel posible. 5- Siguiendo con los puntos anteriores, enuncié que el quality checker (lamento utilizar el término en inglés, es costumbre) es quien da el visto bueno a la traducción en su totalidad. Con esto quiero decir que la forma de traducción debiera ser por equipos de dos tipos al menos. Un tipo de equipo debería trabajar con la traducción de NPC aislados o "de relleno" (esos que no hacen nada ni intervienen en quests alguna). El otro tipo debería trabajar por quests, y no por NPC o ciudades. Esto es importante, porque a la hora de realizar el chequeo final, se debe tener una visión global del desarrollo de la quest, de forma que sea clara y no presente ambigüedades. Por equipo se entiende, al menos, 1 traductor y 1 corrector. Lamento haberme extendido. Sinceramente, seguiría, pero mi intención no es desanimar el proyecto, sino marcar unas cuantas falencias que encontré en base a los comentarios. Si un proyecto funciona o no funciona depende, en primera medida, de la organización. Sin organización o capacidad para "ponerse la mochila" y administrar las tareas, aunque haya recursos, apoyo y tiempo, el proyecto estará condenado al fracaso. Muchos éxitos. Si veo que va por buen camino y estoy con tiempo, quizás participe. EDIT: Una última cosa que no quiero dejar pasar, cada participante debería realizar una única tarea. Si el traductor también es corrector, hay una tarea que no se realiza. Claramente si el lo tradujo (se supone que) lo hizo de manera correcta, con lo cual la función del corrector nunca se aplica.