Re: [Minë-dev] cositas

[Gabriel Pulido de Torres]

Respondiendo...

> 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.
>
Ok, ya me lo he cargado.

>
>
> > 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.

Ok, lo añado como descripción al objeto y se podrá editar con el editor
dentro de la sala (válgame la rebuznancia)

>
> 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.

Bueno, esto me lo tendrás que explicar con más detenimiento, de todas formas
hasta que no acabe de retocar todo no daré de alta la "versión" nueva.

>
> 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.
>

Ya me contareis, ahora yo estoy con lo mío

>
> >
> > 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.
>
Ya, si si me lo imaginaba :) Está puesto com float :)

> >
> > 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.

Yo tengo alguna que otra idea al respecto, aprovechando los tipos de las
salas, o añadiendo información que digan si la sala es "extensible" (o
haciendo Grupos de salas como un todo... bueno ya te lo explicaré en otro
momento ;) )
>
>
> > 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.
>

A buenas horas, mangas verdes.... He cambiado el STCTabWidth y ahora me sale
todo perfesto (hasta las que tuve que cambiar enteras para que el boa se
enterase ;) ) Y yo tb soy muy estricto con la pinta del código y que sea
legible...

>
> > 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)

Ok, básicamente estaba haciendo eso pero sin la función, que la crearé ahora
y la añadiré al utils.

> > 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.

Como ya he dicho antes, por ahora no modifico el árbol directamente sino las
variables en las que se ha almacenado al parsear la sala. El problema me lo
crea al pasarlo a xml pues tengo que hacerlo por las bravas dándole yo el
formato, pero con un poco de orden y paciencia no queda tan feo el código...


> > 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..
>                }
>
Ok, lo añado a la clase sala.py y así ya lo tenemos y lo podemos modificar
cuando se necesite.
Creo que es interesante hacerlo también con los tipos de cierre, aunque por
otros motivos por ahora no lo voy a hacer con ellos.

> >
> > 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 :)
>
No, si yo seguir sigo :) Cuando cojo algo lo hago con ganas :) Además pude
quedar muy bien en el CV ;)
Venga hasta la próxima
Trotter (Gabi)