Elimina tus quest correctamente

[caanmasu 439]

Hola!

 

¡Al grano!

 

Crear un archivo llamado borrar.sh y agregar este contenido.

#!/bin/sh
echo Por favor, introduce nombre archivos quest a borrar sin .quest
read NOMBRE
find . -type f -name "$NOMBRE*"
echo borrar S/N
read borrar
if [ $borrar = "s" ]; then
find . -type f -name "$NOMBRE*" -exec rm -v {} \;
fi

Después meterlo en la carpeta quest/object

Para ejecutarlo debes ir a la consola y poner:

cd ruta/quest/object && sh borrar.sh

o si ya estás en object solo pones:

sh borrar.sh

 

 

Nota: ese archivo me lo encontré en los files Ethernia, creo. No es mío.

 

Explicación:

Si pensabas que eliminar una quest era borrar el archivo de quest pues ¡It's wrong!

Si eliminabas la quest desde la carpeta object buscando cada when tal vez se te hacía fácil pero imagínate una quest bien compleja... buscando cada when.

 

Para que tenga sentido los comandos que te doy, voy a explicarte cómo funciona bien el árbol de las quest compiladas

Cuando haces ./qc nombre_quest, se crean ciertos archivos en la carpeta quest/object.

Míralo de esta forma, quest es un bloque que en jerarquía es el mayor de todos y se almacena en quest/object en varios archivos que mencionaré a continuación.

quest nombre_quest begin

end

Luego el siguiente nivel de jerarquía es state y un archivo se almacena en quest/object/state/nombre_quest

quest nombre_quest begin
	state start begin

	end
end

Ese archivo describe los id de cada state (el state start es obligatorio y siempre entra a ese state primero antes que a otro, por lo tanto el id siempre será 0) y cada función. Así para el ejemplo de la quest de arriba:

nombre_quest={["start"]=0}

Si la quest tiene otro state, se agrega separado por coma y se le asigna un id aleatorio, así:

nombre_quest={["start"]=0, ["state_dos"]=12434543, ["state_tres"]=3453434}

Si la quest tiene funciones, se agregan así.

nombre_quest={["start"]=0, ["state_dos"]=12434543, ["state_tres"]=3453434,nombre_funcion= function() todo_el_contenido_aquí}

Después el siguiente nivel de jerarquía es when y cada when se almacena en un archivo diferente en quest/object/

Si el when está llamando a un objeto, entonces se crea una carpeta. Por ejemplo:

quest nombre_quest begin
	state start begin
		when 101.kill begin
	
		end

		when 20095.chat("Hola") begin

		end

		when mi_timer.timer begin

		end

		when kill begin

		end
	end
end

Voy a explicar cada caso por cada when en orden

Caso 1: se crea el archivo quest/object/101/kill/nombre_quest.start. El kill está llamando al objeto 101 que es el perro salvaje.

Caso 2: se crea el archivo quest/object/20095/chat/nombre_quest.start. El chat está llamando al objeto 20095, obviamente chat solo está configurado para mob tipo NPC.

Caso 3: se crea el archivo quest/object/mi_timer/timer/nombre_quest.start. El timer está llamando a mi_timer que fue un timer creado en un when así:

timer("mi_timer", tiempo_en_segundos)

Estos tres casos tienen algo en común y es que cuando el when llama a un objeto se crea una carpeta con el nombre del objeto o el id, luego adentro crea otra carpeta con la acción (kill, chat, timer, loop_timer, server_timer o server_loop_timer)

 

¿Qué sucede si la acción no llama a un objeto?

Se crea el archivo en una carpeta llamada notarget en quest/object.

Caso 4: se crea el archivo quest/object/notarget/kill/nombre_quest.start

 

Como ya se han dado cuenta, el archivo que se crea es de extensión .state

El árbol de archivos y carpetas tienen una estructura específica para describir las quest una vez se compilan.

¿Qué contenido traen los archivos nombre_quest.state?

Adivinaste. El mismo contenido del when que pertenecen a ese state.

 

El árbol queda así para la quest de ejemplo:

 

Debes iniciar sesión para ver el contenido del archivo adjunto en esta publicación.

 

Puede ser más complejo meter más state, complicar el when poniendo muchos or combinando acciones llamando a objetos y otras no, pero no es el objetivo profundizar esto.

La conclusión es simple, todos los archivos creados tienen algo en común: el nombre

Por eso el archivo en bash (líneas de comandos para la consola) borra lo que digites sin el .quest para que se borre también el state.

Si has llegado hasta aquí no has perdido el tiempo. Ahora entiendes un poco más cómo está estructurado esto. 

Si te preguntas por qué hay un perro que dropea barras de oro y no encuentras el archivo en quest, puede que no esté allí pero sí esté compilado en object.

 

Anexo:

Si al hacer una acción implica dos when, siempre hará el primero e ignorará a los demás, ejemplo:

when 101.kill begin
	chat("Rojo")
end

when kill begin
	chat("Negro")
end

Si matas un perro te va a decir Rojo

Si cambiamos el orden de los when, pasará esto:

when kill begin
	chat("Negro")
end

when 101.kill begin
	chat("Rojo")
end

Al matar un perro va a decir Negro

 

Saludos!

[TheZurka 2]

hmm ahora entiendo un poco más sobre las quest pero es más lioso de lo que imaginaba xD

entonces, por la misma regla de tres, si modifico algún archivo, con que haga un ./qc nombre_quest sería suficiente para modificar la quest?

 

[caanmasu 439]

Emm... sí y no xD depende

Hay casos en que hay que borrar la quest y compilar de nuevo.

Por ejemplo este caso:

Creas un when

quest drop_espada begin
	state start begin
		when 101.kill begin
			pc.give_item2(19)
		end
	end
end

compilas y haces rel q. Al matar al perro te va a botar Espada +9. Todo normal.

Pero si quitas el when y creas otro  (o sea, modificas la quest)

quest drop_espada begin
	state start begin
		when 102.kill begin
			pc.give_item2(19)
		end
	end
end

compilas y haces rel q. Ahora un lobo también va a botar Espada +9.

Tanto el perro como el lobo va a dropear la espada. Sencillamente porque al eliminar el when no se va a borrar el archivo ya creado en el árbol.

En este tipo de casos es mejor eliminar desde raíz la quest compilada con el archivo borrar.sh.

Y hay casos en que no tengo ni idea qué ocurre. Hago cambios en una quest y no se refleja en el juego. No le echo más cabeza y la elimino por completo y la vuelvo a compilar.

[Dilong 2,955]

En 13/3/2020 a las 6:40, TheZurka dijo:

pero es más lioso de lo que imaginaba xD

No es que sea lioso, si no que cada uno tiene su forma de hacer las cosas xd

En mi caso en un sv pruebas, pongo dos locale_quest

Uno con las quest normales y otro con las quest que son de pruebas, por ejemplo una misión o dungeon

Si quiero cargar las quest normales pongo directamente cd /quest && rm rf object

./make_quest o ./make_test para cargar las de prueba

Lo mismo para la tabla del mysql donde va los qf y states, creo una copia para lo normal y otro para pruebas, así no pierdo los datos

Ya depende de como te es mas cómodo xd

[caanmasu 439]

hace 1 hora, Dilong dijo:

No es que sea lioso, si no que cada uno tiene su forma de hacer las cosas xd

En mi caso en un sv pruebas, pongo dos locale_quest

Uno con las quest normales y otro con las quest que son de pruebas, por ejemplo una misión o dungeon

Si quiero cargar las quest normales pongo directamente cd /quest && rm rf object

./make_quest o ./make_test para cargar las de prueba

Lo mismo para la tabla del mysql donde va los qf y states, creo una copia para lo normal y otro para pruebas, así no pierdo los datos

Ya depende de como te es mas cómodo xd

Es una alternativa muy buena