ambar-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Minë-dev] cositas


From: Andres Moya
Subject: Re: [Minë-dev] cositas
Date: 18 Mar 2003 12:47:20 +0100

El lun, 17-03-2003 a las 17:18, Gabriel Pulido de Torres escribió:
> Hola gente, os planteo unas cuantas cuestiones que me he ido
> encontrando :) De algunas necesito una respuesta más o menos urgente
> para seguir con el cambio del parseado de la sala...

Vamo allá...


 
> 1)Los decorativos no están definidos en el dtd de la sala. Necesito
> saber como se definen en el fichero xml para saber como parsearla bien
> :) (no he encontrado ningún fichero de sala que tenga un ejemplo para
> poder saber como va...) Por ahora asumo que están definidos entre
> etiquetas 'item' al igual que las descripciones. Además los
> decorativos tampoco están declarados como variables con el propierty.
> ¿Que es lo que pasa con ellos?

:-? :-O :-P

Olvidate de esto... Me parece que es un resto de código obsoleto que
queda en sala.py. No me suena de nada, y además si te fijas, a la
función __parsear_decorativos no se la llama desde ningún sitio. Creo
que se puede borrar entera.


 
> 2)¿La descripción de un objeto varía dependiendo de en que sala esté?
> Lo digo pq ahora mismo cada objeto tiene la descripción que se le da
> cuando se asigna a una sala, descripción que curiosamente se IGNORA
> totalmente al parsear la sala, y la suya propia por existir en el
> mundo de minë (y que está en su propio xml). Es algo raro, ¿no creeis?
> Es decir si luego se ignora ¿para que poner la descripción del objeto
> en la sala? Se me ocurre que determinadas circunstancias variables de
> la sala (como la luz) puedan variar la descripción de un objeto, pero
> ahora mismo  no se está haciendo así (creo) Y además se utiliza al
> final la descripción propia del objeto pues la que aparece en la sala
> como ya he dicho ni siquiera se parsea con ella...

Interesante cuestión. Creo que se planteó en su día pero se nos había
olvidado. Claro, en principio lo más lógico es que cuando un objeto haya
sido "generado" por una sala, si entras y miras veas la descripción que
aparece en el elemento <objeto> de la sala. Si luego alguien lo coge y
lo suelta en otra sala, entonces ya verías el nombre propio del objeto.

En realidad la descripción sí se está parseando, lo que pasa es que
luego no se guarda en el atributo self.__objetos de la clase Sala.
Cuando la reescribas haz que sí se guarde, como un elemento más del
mapa, con clave "descripcion". Luego yo haré que el programa la use.

Acuerdate de que cada vez que se cambia la estructura de una sala hay
que incrementar VERSION_SALA (ahora iría 1.2.2), y añadir en
__setstate__ el código para que si se carga un fichero de sala guardado
con pickle, con una versión anterior, le añada el atributo que le falta.

Lo de que la descripción cambie según la luz, y eso, se podrá hacer muy
fácilmente con el nuevo sistema de requisitos.


>  
> 3)¿El volumen de una sala tiene que ser un float o un entero?

Un float. Piensa en un agujero estrecho, que quepa un hobbit pero no un
humano. Si el volumen de un humano típico es 1, el agujero tiene que
tener un volumen menor que 1.



> Y siguiendo con los volúmenes, repasando la guia del colaborador, se
> sugiere que se dividan en varias "salas" las salas grandes, pero con
> esto se consigue que un dragón de u.vol 200 nunca pueda estar en
> ningún sitio pq nunca tendrá suficiente volumen pues hasta los
> espacios abiertos se dividen con lo que ¡no puede volar en cachitos de
> espacios abiertos de 50 u.vol! Es sólo un comentario sobre algo que me
> ha llamado la atención :) .

Ups. Pues no se nos había ocurrido :-P

Sinceramente, ¡no se me ocurre cómo resolverlo! Habrá que darle una
buena pensada...

De todas formas, aún falta tiempo para que queramos crear personajes de
ese tipo. Creo que puede esperar.



> 4)Duda chorra, ¿en Python no hay que indentar siempre?, es decir
> cuando pones un def ¿todo lo que abarca el def no tiene que estar
> indentado por narices? lo mismo con los try y los if, es que me
> encuentro con cosas en el código que obviamente van dentro de cosas
> pero no están indentadas... ¿cual es el motivo? (y creo que al boa no
> le hacen mucha gracia en general y me paso el rato indentando y
> colocando todo de nuevo...)

¡¡¡OJO!!!

¡¡Los ficheros están todos bien indentados!! Yo soy bastante pijo con
eso. En realidad es un fallo del Boa, o más que un fallo un error de
concepto.

Resulta que el boa interpreta los tabuladores como de 4 espacios, en
lugar de los 8 estándar. Por ejemplo, si encuentra una línea indentada
con 8 espacios, la muestra bien. Pero si la encuentra indentada con un
tabulador, te la enseña descolocada.

Casi todos los editores pueden configurar esto. En la versión de Boa que
yo tengo no he encontrado ninguna opción de menú para ello (a lo mejor
en la última ya la han añadido), pero se puede cambiar editando el
fichero prefs.rc.py, y donde pone STCTabWidth pones 8 en vez de 4.

Si lo haces verás como todos los ficheros se quedan bien indentados,
salvo los que te hayas cargado intentando corregirlos :-P

REGLA DE ORO DEL USO DEL EDITOR: **NUNCA** cambiar el ancho del
tabulador a nada distinto de 8 espacios. **JAMÁS**. Los que han hecho el
boa han metido la pata hasta el cuello ahí :)

También es buena idea no usar nunca tabuladores, pero es difícil, porque
casi todos los editores los meten al indentar automáticamente.



> 5)Por cierto Andrés, como diablos se hace referencia en el árbol de
> xml a cada uno de los elementos de un elemento: Me explico, por
> ejemplo cuando cogemos las <salidas> cada una de ellas tiene un nombre
> distinto (norte, sur...) con lo que no puedo hacer
> "getElementsbyTagName" dentro de salidas, pero necesito poder
> enumerarlas todas para coger luego sus nombres y propiedades, con las
> descripciones de la sala es fácil pues todas tienen el tag 'item' pero
> con las salidas... ¿? (seguro que es una chorrada...) 

En este caso puedes hacer dos cosas: una es no tener un bucle, sino
repetir el mismo código varias veces llamando a getElementsByTagName con
cada una de las direcciones (aunque esto no te lo recomiendo). Y la otra
es usar la propiedad childNodes sobre el nodo con las salidas, que te
devuelve una lista con todos los nodos hijos. Y luego usar nodeName para
averiguar la dirección. Vamos, tal como lo hace el sala.py de ahora.

Te recomiendo hacer una función extraer_nombre_xml(elem) en utils.py que
devuelva elem.nodeName.encode('ISO-8859-1').

Quedaría algo así como: 

  for elem_salida in elem_salidas.childNodes:
    direccion = extraer_nombre_xml(elem_salida)



> 6)Ahh, y si puedes (ya que tu te lo tuviste que mirar... si no te
> acuerdas lo buscaré yo) dime como se añaden cosas al árbol, por
> ejemplo si quiero "colgar" un item de descripción más a las
> descripciones, o modificar un atributo de algo (ya que en algunas
> cosas no estamos usando en el parseado a variables la orientación a
> objetos pues las propiedades de la sala, por ejemplo, son tipos
> básicos ).

Pues la verdad, esa parte no me la miré mucho y no la recuerdo... Me
fijé sólo en cómo leer el fichero, no en cómo cambiarlo. Pero recuerdo
que no era muy complicado. Míralo tú, y si tienes alguna duda me
preguntas, a ver si entre los dos lo sacamos.

Y es buena idea crear funciones en utils.py simétricas a las de
extraer_contenido_xml, etc. Acuérdate de comentarlas bien y de poner las
pre y post condiciones.


 
> 7)Sería interesante (a mi me vendría muy bien pq así no tengo que
> buscarme la vida de otra forma) que hubiese unas constantes globales,
> o unos métodos (pueden estar en utils por ejemplo) que
> devuelvan/almacenen la lista de tipos y de subtipos para cada tipo de
> una sala que están permitidos. Ahora que lo pienso eso tiene que estar
> en algún lugar no? (no me vale el .txt de las tablas de mine pues no
> está en un formato "utilizable".

Pues que yo sepa no existe ahora mismo en el código, pero sí que es
bastante conveniente que lo haya. Evidentemente, el lugar adecuado es la
propia clase Sala, en forma de una variable estática. Del estilo a
SECCIONES y NOMBRES_MES en FechaHoraMine.

Podría ser, por ejemplo, algo parecido a:

  TIPOS_SALA = { "Población" : [ "calle", "callejon", "plaza",
                                 "portal", "pasadizo", "arco",
                                 "puerto", "embarcadero", "balcón" ],

                 "Edificio" : [ "salón", "habitación", ... ]
               
               ..etc..
               }


>  
> Bueno por ahora nada más... gracias por vuestra paciencia :) Dentro de
> poco os mandaré una copia de pantalla del editor para que veais como
> va la cosa :) (y podais ponerme verde... constructivamente por
> supuesto ;) )
>
> Trotter (Gabi)

¡¡Ánimo y a seguir p'alante!!  Este proyecto va a ser algo grande :)


-- 
Andres Moya <address@hidden>

"No a la guerra - Otro mundo es posible"
"No queremos a Bush - Tampoco a Sadam"





reply via email to

[Prev in Thread] Current Thread [Next in Thread]