jaBote

Ante todo tengo que aclarar que no soy ni he sido cliente de OVH/Kemsirve. Pude haberlo sido si no fuera por un cambio de idea de última hora. Esa máquina me gusta, aunque la veo muy justita en cuanto a procesador. El servidor, según la wiki, consume alrededor de 1.5 GHz de proceso en la CPU. Ten en cuenta que además del servidor deberás (o deberías) tener las bases de datos y el servicio MySQL en la misma máquina (puedes tenerlo en una distinta, y aunque no lo he probado nunca, creo que no es buena idea), además de (por supuesto) el proceso que ocupa el propio sistema operativo que tengas instalado. Si es alguno que consuma muy poco como Debian Linux puedes despreocuparte, pero no cuentes con ello. El Kemsirve KS 2G (a partir de aquí los llamaré Kimsufi, es su nombre original en francés y se usa para todos los idiomas salvo el español) tiene suficiente memoria RAM como para hacer funcionar el servidor sin problemas y una cantidad de transferencia de datos (vas a abrir un servidor de juegos, ¡¡esto es importantísimo!!) envidiable (por razones de seguridad no deberías usar un hosting que te ofrezca menos de 1 Tb, de transferencia mensual, 2 recomendados), pero tiene muy poco margen de proceso. Sí, cumple con los requisitos mínimos (su único procesador funciona a 1.6+ GHz), aunque realmente a mí no me convencería si leyeras mi párrafo anterior. También recomiendo leer alguna crítica a los servicios de Kimsufi antes de saber a lo que te enfrentas. Recuerdo un servidor hispano que abrió dos o tres meses antes de que yo abriese el mío, dos años ha. Era bueno aunque tenía algo de lag casi imperceptible, cosa muy rara si el servidor está en Francia y tanto a un amigo catalán (¡saludos) como a mí desde Andalucía nos daba el mismo tipo de lag, con aproximadamente el mismo tiempo de retraso (y yo estoy conectado desde Wi-Fi, que añade cerca de +20 ms de retardo adicional). Como el dinero siempre es un factor que debe tenerse muy en cuenta, y en esos instantes ese servidor valía 30€/mes (+ IVA), muy barato para todo lo demás que encontré por Internet (ese lag casi imperceptible a fin de cuentas no era en absoluto incómodo, había gente que llevaba del orden de 6 años más que yo jugando y no se daba cuenta, por lo que estaba correcto para un servidor decentito), decidí preguntar al admin por PM y me confirmó que ese era el modelo que estaban usando. Eso sí, estaban alojando la web y la base de datos y todo en esa máquina, por lo que todo iba relativamente bien. Al mes y medio aproximadamente su disco duro se rompió y tenía la mayoría de sus backups guardadas localmente, por lo que cuando decidieron cambiárselo restauró una copia de una semana anterior y claro, ese servidor no duró mucho más. ¿Por qué es debido? Muy sencillo: tras indagar (no recuerdo la fuente, aunque creo que era en la misma web francesa de Kimsufi, que ahora mismo no está), encontré que se decía que esos servidores eran de calidad, pero viejos. Y no dudo que un disco duro nuevo se pueda romper sin problemas, pero el hardware viejo es un punto de riesgo considerable. Y bueno, podría seguir contándote mis batallitas y por qué me decidí por un VPS de un revendedor inglés situado en Hetzner (Alemania, datacenter de gran prestigio, es donde están alojados Hercules, rAthena y demás ahora mismo) en que duré menos de 3 meses porque de los 2 núcleos a 1.66 GHz que me prometían recibía 1.4 GHz de proceso útil total (¿el juego? ¡Un desastre en horas punta!) y de cómo acabé hospedado en una pequeña empresa catalana emergente de alojamiento con centro de datos propio (eso dicen), en que he tenido simples problemas menores y sigo teniendo mi VPS (actualmente en desuso) con ellos. A fin de cuentas querías opinión sobre la máquina de Kimsufi. En resumen: yo de ti, si tienes algún fondo de maniobra, haría una prueba de ese servidor aunque tengas que pagar un mes por probar unos cuantos días: se puede instalar un eAthena/rAthena/Hercules en cuestión de minutos y usar el cliente de Judas apuntando a esa máquina. Prueba a usar características pesadas en proceso e intenta usar algún NPC con amplio consumo de proceso, etcétera. Si aguantáis como 50 sin signos evidentes de freeze del servidor, adelante. Eso sí, como veis en la crítica estaréis limitados en soporte técnico. Si no hay fondo de maniobra alguno buscaros cosas mejores y más baratas, o mejores pero a un precio que pueda competirle bien, que puedo asegurar que las hay si sabes buscar.

Whops, that habit was a bit old, didn't know that. For the .init var, I forgot to add it on the quick mockup, my bad.

This mockup script can help you do what you want. Just remember it's not an actual script but a mockup: <map>,<x>,<y> script randomwarp 45,1,1{OnTouch: if (!.init) { donpcevent strnpcinfo(3)+"OnInit"; sleep2 10; // This way the OnInit event has time to load completely } /* HERE COMES YOUR DECISION ALGORITHM set .@pos, M; // .@pos is the decided position on the array, let's say you decided position M */ warp .maps$[.@pos],.x[.@pos],.y[.@pos]; end;OnInit: // Fill your possible destinations on this arrays. Warning: arrays have up to 128 positions, don't use more than 128 places // Arrays have positions ranged from 0 to 127. This means 0 is the first position of an array. // Change "mapN" to actual map names, xN to actual X positions on mapN, yN to actual Y positions on mapN setarray .maps$[0],"map1","map2","map3"; setarray .x[0],x1,x2,x3; setarray .y[0],y1,y2,y3; end;} Hope this helps you making your script

As of today that's not possible without changing almost entirely the scripting engine. You can't use any variables when defining any of the following: A mapflag A monster spawn A warp point Any NPC object When you are defining any of these you're using what in the documentation (/doc/script_commands.txt) is called a top-level command, and as it's said there (pay special attention to the bolded text): So, sadly, I think that won't work. Edit: That other way you just proposed will work for sure.

Hi nanakiwurtz! I have bad news regarding your questions, sorry! As far as I know, getting Hercules as a ZIP file just downloads the last snapshot of the project (with UNIX line endings) without any capabilities of using it with Git. As I said, that's just the snapshot. Sadly, I don't know any other means of cloning a project other dan issuing a Git clone.Git clone clones the repository and its whole history so you have it all on your computer; that's why it's so slow. No, it doesn't, and there's an easy reason for this: forks are either meant to work on them and make pull requests, or independently working on them for your purposes. If an update was automatically applied when you're working on your fork, strange things would happen, isn't it? For updating your fork, you can refer to this post, second FAQ question provided you use TortoiseGit. If you mean moving the local repo folder as changing its location on your PC, no problem as far as I know. I've moved them myself on my PC without any problem. I don't know any other means of doing this. Hope I helped, despite the bad news!

As I said previously, what you have to remove is in line 7 of npc/scripts_guild.txt: npc: npc/guild/agit_controller.txt What you have to do is just puting a double slash (//) at the start of that line (sorry for my mistake before when I wrote dash).

Problem isn't in the script you provided, but that you have default agit_controller.txt enabled, which starts WoE Tuesdays and Thursdays from 21:00 to 23:00 and Saturdays from 16:00 to 18:00. You can disable this NPC commenting its appearance in npc/scripts_guild.txt, line 7: npc: npc/guild/agit_controller.txt Just put a double dash (//) at the start of this line.

Para un server en renewal te da igual ragexe que ragexeRE, siempre y cuando los clientes sean suficientemente recientes. Aunque parece cierto que los ragexe van más avanzados en características que los ragexeRE. Y sobre lo de comentar esa línea: sería una informalidad por parte de los programadores ponernos eso como una trampa. Si está ahí es porque se le dará uso en el código, ¿no? Además, creo recordar haber leído por ahí arriba (en otros foros) que esta configuración está ahí porque algunos paquetes no coinciden entre ragexe y ragexeRE, por lo que es necesario hacer esta distinción.

2-3x .. that is just sad Then just wait for Ind's commit, wich will cut in half that 256 MB mark and you'll see that's more sad.

Eso parece problema del servidor. ¿Te acordaste de modificar /src/common/mmo.h para poner tu fecha? /src/common/mmo.h: #ifndef PACKETVER#define PACKETVER 20120418#endif // Comment the following line if your client is NOT ragexeRE (required because of conflicting packets in ragexe vs ragexeRE).#define PACKETVER_RERecuerda que #PACKETVER debe estar definido a la fecha aaaammdd de tu cliente, si no es muy probable recibir errores de este tipo. Al usar el cliente de Judas no tienes que cambiar nada porque esa es la fecha que viene por defecto (que como puedes ver en el código original es la del 18 de abril de 2012). Espero haber sido de ayuda.

Sí, ese es un inicio correcto. Lo que necesitamos saber es lo que aparece en la consola del servicio que no inicia correctamente.

Here you go. Haven't tested so errors may arise, don't kill me for them! http://upaste.me/e77d5998dcb0f645

You can file a bug report on this if you haven't done it yet. According ro RateMyServer:

first 4 values are other things, the rest are, as the document says: Chance+1:Bonus+1,Chance+2:Bonus+2,Chance+3:Bonus+3,... Just fill the DB accordingly until you get 104 values (4 + the 100 refine values), a pair Chance+X:Bonus+X are considered as one only value.

Did you remember to change these settings in /src/common/mmo.h? #ifndef PACKETVER#define PACKETVER 20120418#endif// Comment the following line if your client is NOT ragexeRE (required because of conflicting packets in ragexe vs ragexeRE).#define PACKETVER_RE Remember you should set PACKETVER to the aaaammdd date of your client and comment (put a // before any text) the line which defines PACKETVER_RE if you're not using ragexeRE clients. Then you have to recompile for this changes to take effect.

Sobre guías tuyas, no hay ningún problema (salvo que sean demasiado viejas y no tengan utilidad práctica real); sobre guías de otros autores es ya un poco más complicado: Generalmente las guías son tomadas de fuentes cuyo acceso es público y (legalmente) pueden ser copiadas sin ningún tipo de miramientos (es más, como son implícitamente cedidas al dominio público sin que lo sepan puedes hacer prácticamente lo que quieras con ellas, salvo licenciarlas), a menos que haya una política de copyright o licencia que las cubra por completo en el foro/web del que provengan o que la propia guía esté licenciada (por ejemplo con una licencia Creative Commons, que se están haciendo populares) por su autor. Eso sí, tomar obras del dominio público sin dar crédito alguno es como usar la máquina de vapor de Watt y atribuirte su invención, salvo que no sonará tan increíblemente disparatado. Queda feo. Por tanto, si publicas guías de otros, hazlo con cabeza. Cumple la licencia que haya vigente o, al menos, cita a su autor original y publica un enlace a la fuente, aunque la obra no tenga licencia.

En el lado del cliente no soy tan bueno, a decir verdad (los sprites, mapas y casi cualquier apartado gráfico es parte del cliente). Mientras se cumplan las normas es posible colocar prácticamente cualquier cosa, pero no recomiendo robar trabajo original de ningún servidor. Se sabe que hay muchos sprites y demás custom, que viajan de servidor en servidor y no pasa nada si se obtienen a partir del GRF de uno de esos servidores cualesquiera. Es más, dichos recursos fueron concebidos para su distribución. El problema son las creaciones únicas: no hay ningún tipo de copyright sobre ellas pero queda muy feo tomarlas sin permiso. En conclusión: aunque no puedo hacer ningún esfuerzo por cuidar que las publicaciones de sprites que se hacen, tratad de que lo que se publique sea algo que se haya cedido para su distribución libre. P.D.: Moviendo los temas publicados a su sitio, las cosas que se publican con respecto al apartado gráfico de un servidor va relacionado con el cliente.

Comencemos a aclararnos un poco. Las preguntas en este hilo se acumulan y tienen distintas temáticas, por ello es mejor hacer cada pregunta por separado ya que mejora su legibilidad, los hace más localizables para el resto del público (lo agradecerán mucho) y requiere menos tiempo contestarlos (lo cual agradeceremos mucho los que contestemos ). Voy a ir respondiéndolas todas a la vez: Sobre el item que te da las monturas oficiales "de pago": como bien dice M45T3R se trata del item Reins of Mount, que se encuentra solamente en /db/re/item_db.txt, con ID 12622: 12622,Reins_Of_Mount,Reins Of Mount,11,0,,10,,,,,0xFFFFFFFF,7,2,,,,,,{ setmounting(); },{},{} Como puedes comprobar, también puedes dar o quitar estas monturas con el script command setmounting();, que puedes encontrar (en inglés) dentro de /doc/script_commands.txt, entre las líneas 3606 y 3616. Según tengo entendido y tal como apuntó M45T3R, puedes copiar el item del item_db renewal al pre-renewal sin problemas dado que funciona igual. ______________________________ Sobre la implementación de mapas: Esto da por sí solo para un tema entero o una guía de proporciones razonables. Suponiendo que tienes hecha la parte de clientside hecha, (que así es para los mapas oficiales, salvo que quieras duplicar un mapa que tienes que modificar resnametable.txt dentro del GRF). Básicamente lo que tienes que hacer es añadir el nombre de los mapas a /conf/maps.conf y rehacer tu mapcache. ¿Cómo se rehace el mapcache? Hercules ofrece una herramienta para ello, pero no se me antoja nada fácil de usar. ¿Qué es lo que hago yo? Yo uso una herramienta reciente para hacer Mapcaches llamada WeeMapCache, de Shinryo (lo puedes descargar desde su repo oficial y abandonado, aún funciona). Simplemente lo abro, le paso el antiguo mapcache (lo tomas del servidor, está en /db/{pre-re o re}/mapcache.dat) y los nuevos mapas (se importan desde archivo, carpeta o GRF que lo contenga, o el recién editado resnametable.txt si el nuevo mapa es un duplicado de otro anterior) y simplemente exporto un nuevo mapcache.dat con lo nuevo. Ahora toca hacer una copia de seguridad del mapcache.dat antiguo (por si acaso), reemplazar el mapcache del servidor por el nuevo y probarlo en el servidor. Si funciona, enhorabuena. _____________________________ Sobre el script de las elemental wars, al parecer se trata de una implementación exclusiva de dicho servidor hecha por ellos, por lo que en caso de que no quieran cederlo (como suele ocurrir con una frecuencia relativa muy alta en el muy celoso panorama del servidor privado hispanohablante de Ragnarök Online, aunque están en su derecho) tu única alternativa razonable es creando dicho script o buscando a alguien que lo haga por ti. La dificultad propia del script no parece muy elevada (un scripter medio suele haberse enfrentado a cosas más complejas), pero está salpicado de mobs e items customs. Para obtener tales mapas, items y monstruos sería necesario disponer de su GRF; si no habría que reformular todo lo que se vaya a reutilizar en el nuevo script para que tenga comportamiento similar ya que no se dispone de tales mobs, items y mapas custom. Haría falta también alguien que haya jugado dicho evento y pueda describir con claridad lo que hay para poder disponer de una copia filedigna del script. No hay nada que impida hacer retroingeniería a dicho script si no se tiene delante pero, aunque no sé si tales items, mapas y mobs custom, son propios de ellos*, no es buena idea (es más, desaconsejo) cogerlos y robarlos de un servidor porque para eso han invertido un esfuerzo y puede incluso costaros un disgusto legal. Robar está feo, reinventar no (aunque se reinvente algo que funcione igual o mejor que el original). * Por lo menos los sprites de los cristales y las imágenes de los items ya están en el GRF básico que provee Gravity así que no son propios de ellos. Desconozco qué pasa con el resto. _______________________________ ¡Espero haber sido de ayuda!

It's in here: /conf/help.txt. Check line 40 onwards: go: "Params: <city name|number>n" "Warps you to a city.n"" -3: (Memo point 2) 14: louyang 31: moran"" -2: (Memo point 1) 15: start point 32: dewatan"" -1: (Memo point 0) 16: prison/jail 33: malangdo islandn"" 0: prontera 17: jawaii 34: malaya portn"" 1: morocc 18: ayothaya 35: eclagen"" 2: geffen 19: einbrochn"" 3: payon 20: lighthalzenn"" 4: alberta 21: einbechn"" 5: izlude 22: hugeln"" 6: aldebaran 23: racheln"" 7: xmas (lutie) 24: veinsn"" 8: comodo 25: moscovian"" 9: yuno 26: midgard campn"" 10: amatsu 27: manukn"" 11: gonryun 28: splendiden"" 12: umbala 29: brasilisn"" 13: niflheim 30: el dicastesn" P.D.: I've just realized I mis-moved this topic. In order not to make a big mess, this topic will stay here until solved if you don't mind. Sorry for the inconvenience.

What Phenomena said should work. Just don't forget to recompile your server after performing the source edits. P.S.: Moving to correct section.

Sí, falta soporte para algunos clientes bien porque no han caído en manos de quienes saben extraer sus paquetes (el juego envía los mismos paquetes de datos que un servidor oficial, porque el cliente es una modificación del oficial) o porque los desarrolladores no han podido añadir ese juego de paquetes, aunque una vasta mayoría de los clientes están soportados, a menos que quieras buscar los raros.

Also don't know if it works, but I'll suggest small improvements for your script here and there: Line 25: add a map check before: if (@whispervar0$ == "ADDMAP") { if (getmapusers(@whispervar2$) < 0) dispbottom "Not adding. Invalid map."; else query_sql "INSERT INTO `map_mob_week` (`mapname`) VALUES ('"+@whispervar1$+"')"; // If map proven to exist no need to escape} Line 28: better check if monster exists with getmonsterinfo() or strmobinfo(). I'll use getmonsterinfo since it returns -1 on invalid mob_id: else if (@whispervar0$ == "ADDMOB") { if (getmonsterinfo(atoi(@whispervar1$),1) != -1){query_sql "INSERT INTO `map_mob_week` (`mobid`) VALUES ("+atoi(@whispervar1$)+")";} else{dispbottom "Cannot Add, Invalid ID";}} Same checks for deleting mob and/or maps. In line 85 there's a debug line I forgot to remove and not much more. And thanks for the idea of ordering query results by rand(), didn't think about it!

For BG maps, you should check for mf_battleground instead of mf_gvg_castle

This issue has been answered and resolved in the Spanish Section of the forums. Basically it worked when I asked him again to set up his server again without changing anything since Judas' small client package works right out of the box and it worked.

Para ser sinceros, aún así sigo sin saber cuál fue el problema exacto que causó tu error ni qué detalle tonto pudo haberlo provocado, aunque me alegro de que el problema se haya solucionado. Por el momento, para el tamaño que tiene la sección hispana, hay suficiente de momento con los que somos (M45T3R, y yo de forma no oficial). Si la actividad se dispara es cuando podemos pensar en añadir más gente, aunque por el momento vamos bien. ¡Un saludo!