CAAD

Saludos queridos aventureros.
Espero que todo vaya bien.

De nuevo a las andanzas... XD.
Ya cuento con nueva portátil.

Uto escribió:

El modelo de un proceso por localidad es muy cómodo para analizar el código posteriormente. Ya se ha aplicado de alguna manera en inPAWS, e incluso recuerdo
que en los 90 Jose Luis Cebrián ya llegó a presentar algunos ejemplos en NMP usando ese modelo

¿Quieres decir que si tenemos 20 localidades, podemos crear 20 procesos?

¿Quieres decir que en cada uno de los procesos podemos introducir absolutamente todos los comandos y eventos que vayan a suceder en una localidad?

ABRIR PUERTA
COGER LLAVE
DISPARAR A GUARDIA
MIRAR
ETC ETC ETC
Además de los diálogos con PSI y las escenas de presentación.

Me despido esperando que tengan buen día tarde noche.

Uto responde:

El testigo escribió:
¿Quieres decir que si tenemos 20 localidades, podemos crear 20 procesos?

¿Quieres decir que en cada uno de los procesos podemos introducir absolutamente todos los comandos y eventos que vayan a suceder en una localidad?

ABRIR PUERTA
COGER LLAVE
DISPARAR A GUARDIA
MIRAR
ETC ETC ETC
Además de los diálogos con PSI y las escenas de presentación.

Sí, es otro modo de organizar el código. En definitiva es efectivamente lo que tu dices, tener un proceso para cada localidad, y tener así separado lo
que ocurre en cada sitio. ¿Recomendable? Depende de gustos, yo tiendo también a agrupar por localidades, pero en lugar de hacer un proceso simplemente
le hago un "apartado" en la propia tabla de respuestas que empiece por un comentario así:

Código:
; #################################### JUNTO AL RIO ##############################

<--- aquí va el código de la localidad junto al río --->

; #################################### PUENTE LEVADIZO ##############################

<--- aquí va el código de la localidad del puente levadizo --->

Es suficientemente visible para verlo buscando visualmente, y suficientemente sencilla de buscar usando el buscador del IDE. Hago lo mismo en el proceso
1 y 2.

En cualquier caso, es cuestión de gustos.

¡OOO! Que fino está eso.

Lo que si me pregunto, ¿cómo se puede aplicar eso de un proceso para cada localidad si el modo de movilización entre ellas se efectúa a base de GOTO?

Es decir, yo utilizo mis propios movimientos direccionales arreglados y no los movimientos por defecto para poder así dar la sensación de que se está moviendo el personaje.

Código:

N _
AT locSala
WRITENL “(DESCRIPCIÓN DEL MOVIMIENTO) Con cuidado caminas hacia el norte (DESCRIPCIÓN DE LOCALIDAD) y entras a un abandonado solar que se encuentra (...).”
GOTO locPatio
DESC
; DESC por si acaso hay alguna descripción en PRO1 de puertas o algo más los objetos y PSI si es que los hay.

Y así para cada localidad con su respectiva salida (N _, S _, E _, O _, U _, D _,) todas en la tabla de respuestas.

Como puedes ver, es más trabajo que simplemente dejar que el código te mueva con la rutina extendida de no ir por ahí.

Pero eso, ¿se puede desviar el comando de movimiento a un proceso determinado de determinada localidad?
¿O eso si se debe dejar tal cual en tabla de respuestas como lo estoy haciendo?

El comando de movimiento GOTO es un comando como otro cualquiera, por lo que si tienes separado por procesos cada localidad, puedes poner las entradas de movimiento al final del proceso de cada localidad. Si ya te funciona en "formato normal" te debería funcionar de la otra manera. Otra cosa es que sea necesario hacerlo, es cuestión de gustos.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com

Viene de: viewtopic.php?f=6&t=6025#p74257

Bueno pues el problema que comentaba en el hilo que menciono, a la hora de seguir repasando la aventura he visto que me provoca otros problemas en otros puntos de la aventura, ya que hacía uso del condacto "DESC" en otros puntos y para otras situaciones. He conseguido recrearlo en una mini-aventura, de tal forma que el problema me ocurre cuando separo todas las localidades en un proceso aparte.

En un punto del código al ver que la tabla de respuestas me estaba creciendo de forma considerable, separé todas las localidades y objetos en procesos diferentes, de tal forma que la tabla de respuestas quedó:



Y es cuando hago esto que me sale el "error" que cometó en el hilo mencionado arriba.

En una mini-aventura ( la propia aventura de inicio que crea ngPaws cuando se crea una nueva ) en la tabla de respuestas con las entrada:



Funciona sin problemas,



Pero en cambio si creo un proceso a parte para la localidad, quedando:



Es cuando me da el mensaje "No le ves sentido a examinar eso":



Creo que estoy haciendo un mal uso de "isdone" + "done"... creo.

_________________
Te quiero... lo siento Yoda sólo tenemos café.

Bueno, no se si lo haces mal o es que el ISDONE está mal. El caso es que ISDONE es un condacto que se me escapa un poco, así que tengo que mirar como lo hace DAAD o SINTAC que creo que lo tenían.

Desde luego con la definición actual de ISDONE, lo que te pasa es normal.



Como puedes ver ISDONE se cumple si el último proceso acabó con un DONE, y si pones un DESC, pues no acaba con un DONE , y como consecuencia no se cumple por lo que sigue ejecutando la tabla de procesos, llegando al punto donde se pone lo de "No veo sentido a examinar eso". Sin embargo cuando termina la tabla de respuestas, como se ha marcado que se quiere un DESC, se pinta la localidad.

La cuestión es si ISDONE debería cumplirse también con un DESC, que yo creo que sí, pero tendré que mira a ver.

Además de eso, al usar DESC dentro de un proceso has provocado una acción no prevista por mi, porque DESC lo que hace es "marcar el flag que dice que hay que redescribir la localidad, y finalizar el proceso actual". Esto en la tabla de respuestas es perfecto, pero dentro de un proceso solo finaliza el proceso. A esto le tengo que dar una vuelta también,porque no va ser fácil y creo que para hacer que funcione como debería me va a tocar cambiar el compilador incluso.


Por ahora, aunque es una ñapa extraña, es posible que tu código funcione si pones un DONE detrás de los DESC que hay en los procesos que no sean las respuestas.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com

Saludos.

Ese hermanaso, no te sucede solo con el EXAMINAR
Prueba y da a coger, tocar, ETC.
Al apuntar al proceso en busca de alguna respuesta, tal cual con el EXAMINAR, saldrá del proceso y regresará a la tabla respuestas y lanzará las respuestas por defecto.

Es bastante curro colocar cada localidad en un proceso puesto que se debe hacer que diga una respuesta para cada proceso y no salte a las de la tabla de respuesta.

COGER _
AT locSala
PROCESS 3
DONE

EXAMINAR _
AT locSala
PROCESS 3
DONE

TOCAR _
AT locSala
PROCESS 3
DONE

Colocando dicha respuesta para cada acción en el proceso si lo que se trata es examinar, coger, tocar algo que no está definido en el proceso. ETC...

Ya intenté esta solución porque me imaginaba por donde iban los tiros, pero igualmente no resulta, supongo por que el condacto DESC corta a saco la ejecución del proceso y no llega al DONE.

Me planteé como solución copiar de nuevo el proceso de las localidades a la tabla de respuestas, pero como estoy en la fase aún de repaso, me vuelvo loco con la rueda de ratón pa'arriba pa'aabajo. Así que me he creado un proceso, (la verdad no me gusta crear un proceso para tan pocas líneas ) en el cual:



Que llamo cada vez que sea necesario y con esto solucionado.

_________________
Te quiero... lo siento Yoda sólo tenemos café.