Sobre los mapas y save_map

[darío]

Buenas, vayamos por partes:

Veo que redacte mal el texto o lo leiste muy por encima...

No, lo leí detenidamente (de todos modos he vuelto a hacerlo). No creo que lo hayas redactado mal tampoco porque entiendo perfectamente lo que dices y lo que decías, solo creo que no nos entendemos del todo.

Yo dije "nunca se graba CODIGOS mayores a 999"...

Bueno, por algún extraño motivo yo guardé un mapa desde bennu y en el fichero map se había guardado con código 1000, eso fue el origen de mi pregunta.
Ahora tengo la última WIP (13) de bennu y he cargado pngs y los he guardado como maps y efectivamente se guardan con código 0, no se si es porque toqué algo o porque la WIP 11 tenía algo distinto pero el caso es que no he podido reproducirlo.

No tiene sentido un parametro para modificar el valor que ya es propio del grafico (propiedad del mismo), solo para guardarlo, en ese caso, lo logico es que modifiques esa propiedad haciendo un FPG_ADD con el codigo que quieras y luego guardarlo...

Para mí sí tiene sentido poder guardar mapas asignando el código que me plazca porque luego desde otros programas (i.e. FBMX, FPG.EXE) se podría usar como el "código por defecto" donde quieres que se meta. NO OBSTANTE se que no es algo imprescindible, solo fue una "feature request". Si tienes suficientes razones para no añadir un parámetro más a la función save_map, no es problema, en tal caso me parece razonable lo que está (que se guarde el código 0).

Los puntos de control son propios tambien del graficos, no tienen que ver con el codigo, no entiendo por que decis que tiene ventaja sobre el otro metodo?

No entiendo muy bien lo que quieres decir con esto pero yo a lo único que me refería es a que a mí el uso de archivos MAPs independientes (es decir, que no estrán dentro de un FPG) sí me parece útil (frente a los PNG) por el hecho de que puede almacenar los puntos de control (que los puedo modificar con herramientas externas como FBMX o MAP.exe)

Con el cambio que hice, se logra lo que Uds. dicen de que se puede modificar el grafico en otro contexto (programa) y cuando lo "arrastres" o lo incorpores nuevamente en el FPG, lo inserta en el mismo lugar que ocupaba antes... en estos casos en vez de ser la X, es el CODIGO quien marca el lugar...

Corrígeme si me equivoco pero entiendo lo siguiente:
Sea un archivo map 'm.map' que en disco ha sido guardado con el código N desde una aplicación A.
Hago load_map("m.map"), entonces el primer fpg cargado en bennu se verá afectado. Este comportamiento no me parece correcto pues a mi juicio es confuso: puede que tengas archivos map cuya procedencia desconoces y puede que éstos tengan un código distinto de 0 por lo que al cargarlos modificarían tu fpg sin tu quererlo.

- el codigo de un map no puede ser modificado por el usuario, salvo usando fpg_add...

El código del usuario puede ser modificado desde programas como MAP.exe o Flamebird.

Resumen:
- Generé un map desde bennu wip 11 a partir de un png y se guardó con el código 1000. No he podido reproducir este comportamiento (trabajo con bennu wip 13 ahora y no he probado con la 11) por lo que puede ser que hiciese yo mal algo.
- Yo solo quería save_map(librería, gráfico, archivo [, código]). Siendo consciente que de cara a Bennu no era útil pues load_map no tenía en cuenta el código del archivo MAP en disco. Sí es útil, no obstante, para herramientas externas (insisto mucho en FPG.exe porque es oficial pero también otras como FBMX)
- El cambio realizado no me parece el adecuado (ya expuse los motivos), creo que es preferible como estaba.

Espero que nos entendamos por fin!
Saludos, Darío

[SplinterGU]

Buenas, vayamos por partes:

Veo que redacte mal el texto o lo leiste muy por encima...

No, lo leí detenidamente (de todos modos he vuelto a hacerlo). No creo que lo hayas redactado mal tampoco porque entiendo perfectamente lo que dices y lo que decías, solo creo que no nos entendemos del todo.

Yo dije "nunca se graba CODIGOS mayores a 999"...

Bueno, por algún extraño motivo yo guardé un mapa desde bennu y en el fichero map se había guardado con código 1000, eso fue el origen de mi pregunta.
Ahora tengo la última WIP (13) de bennu y he cargado pngs y los he guardado como maps y efectivamente se guardan con código 0, no se si es porque toqué algo o porque la WIP 11 tenía algo distinto pero el caso es que no he podido reproducirlo.

No tiene sentido un parametro para modificar el valor que ya es propio del grafico (propiedad del mismo), solo para guardarlo, en ese caso, lo logico es que modifiques esa propiedad haciendo un FPG_ADD con el codigo que quieras y luego guardarlo...

Para mí sí tiene sentido poder guardar mapas asignando el código que me plazca porque luego desde otros programas (i.e. FBMX, FPG.EXE) se podría usar como el "código por defecto" donde quieres que se meta. NO OBSTANTE se que no es algo imprescindible, solo fue una "feature request". Si tienes suficientes razones para no añadir un parámetro más a la función save_map, no es problema, en tal caso me parece razonable lo que está (que se guarde el código 0).

Los puntos de control son propios tambien del graficos, no tienen que ver con el codigo, no entiendo por que decis que tiene ventaja sobre el otro metodo?

No entiendo muy bien lo que quieres decir con esto pero yo a lo único que me refería es a que a mí el uso de archivos MAPs independientes (es decir, que no estrán dentro de un FPG) sí me parece útil (frente a los PNG) por el hecho de que puede almacenar los puntos de control (que los puedo modificar con herramientas externas como FBMX o MAP.exe)

Con el cambio que hice, se logra lo que Uds. dicen de que se puede modificar el grafico en otro contexto (programa) y cuando lo "arrastres" o lo incorpores nuevamente en el FPG, lo inserta en el mismo lugar que ocupaba antes... en estos casos en vez de ser la X, es el CODIGO quien marca el lugar...

Corrígeme si me equivoco pero entiendo lo siguiente:
Sea un archivo map 'm.map' que en disco ha sido guardado con el código N desde una aplicación A.
Hago load_map("m.map"), entonces el primer fpg cargado en bennu se verá afectado. Este comportamiento no me parece correcto pues a mi juicio es confuso: puede que tengas archivos map cuya procedencia desconoces y puede que éstos tengan un código distinto de 0 por lo que al cargarlos modificarían tu fpg sin tu quererlo.

- el codigo de un map no puede ser modificado por el usuario, salvo usando fpg_add...

El código del usuario puede ser modificado desde programas como MAP.exe o Flamebird.

Resumen:
- Generé un map desde bennu wip 11 a partir de un png y se guardó con el código 1000. No he podido reproducir este comportamiento (trabajo con bennu wip 13 ahora y no he probado con la 11) por lo que puede ser que hiciese yo mal algo.
- Yo solo quería save_map(librería, gráfico, archivo [, código]). Siendo consciente que de cara a Bennu no era útil pues load_map no tenía en cuenta el código del archivo MAP en disco. Sí es útil, no obstante, para herramientas externas (insisto mucho en FPG.exe porque es oficial pero también otras como FBMX)
- El cambio realizado no me parece el adecuado (ya expuse los motivos), creo que es preferible como estaba.

Espero que nos entendamos por fin!
Saludos, Darío

Claro, antes guardaba el codigo si era mayor a 999, pero ahora lo cambie para que no lo haga, igualmente no importa si tenes mapas con codigo por encima de 999, ya que al cargarlos con la wip13 los ignora... y con la vieja ignoraba todos... asi que no hay problema...

Me refiero a que puedes editar puntos de control tanto de un grafico como de los graficos de un fpg... dentro de un fpg, cada grafico tiene sus puntos de control, al igual que un mapa guardado como tal (.map)... por eso no veo la limitacion... los puntos de control estan asociados al mapa, no al fpg...

No, si tu tienes un archivo "m.map" con la propiedad codigo "345" (asi como tiene propiedad ancho, alto, profundidad) y luego desde otra aplicacion haces un load_map("m.map"), ese grafico tendra el codigo "345" (ya que es parte de sus propiedades)... si no quieres ese comportamiento, entonces no debes guardarlo como tal, pero se supone que los graficos metidos en un fpg, fuero metidos ahi intencionalmente... y deben preservar sus propiedades... pero vamos que es la unica forma (automaticamente) de hacer lo que querian hacer, de que si arrastro un grafico que edito por fuera al meterlo tenga el mismo codigo dentro del fpg de donde lo saque... no han dicho que asi se comportaba DIV? por otro lado, veo que la funcionalidad es asi, porque estaba metido en el codigo original de fenix, de toda la vida, pero estaba a medias...

Cuando digo que no se puede modificar me refiero desde codigo fenix/bennu... tambien lo puedo modificar con un editor hexadecimal, pero no hablamos de eso...

A ver si no quieres que bennu cargue el mapa con el codigo del file, entonces cual fue el sentido del planteamiento original? si el codigo del mapa siempre fue guardado en el file... si te refieres a fpgedit o flamebird, bennu no tiene nada que ver con eso... entonces sigo sin entender el planteamiento original... si es solo para decirle, que en vez de guardarlo con el codigo que tenia, lo guarde con un codigo especifico, sigo sin verle la utilidad para bennu, ya que nunca seria tomado por el... hacer de bennu un producto con funcionalidad para otros productos externos y que para el no tenga sentido o utilidad alguna, no me parece algo muy correcto...

Pregunto, DIV no se comportaba asi?

[SplinterGU]

caramba que lio trajo esto...
estoy pensando en algun tipo de flag o algo que permitas switchear funcionalidad... pero me parece que es correcta la nueva funcionalidad... me parece incorrecta la vieja funcionalidad...

izubiaurre tiro la piedra con lo del DIV y ahora escondio la mano... habla muchacho, no nos dejes hablando como 2 locos... :)

[izubiaurre]

caramba que lio trajo esto...
estoy pensando en algun tipo de flag o algo que permitas switchear funcionalidad... pero me parece que es correcta la nueva funcionalidad... me parece incorrecta la vieja funcionalidad...

izubiaurre tiro la piedra con lo del DIV y ahora escondio la mano... habla muchacho, no nos dejes hablando como 2 locos... :)

Yo no metería nada nuevo que no sea necesario.

Yo decía que si sacabas un map de una fpg:

• se creaba en el escritorio con el nombre
• y el código

Lo modificabas.

Lo arrastrabas otra vez al fpg:

• Se sobrescribía sobre sí mismo
• Todos contentos porque era eso lo que buscábamos

Pero si tiene nombre o nº diferente, no se sobrescribe, como es lógico. Nos preguntará dónde queremos meter (nº).

Los nºs de mapas en una fpg, van desde el 0 hasta 999. Si hacemos una load_map, el nº de ese map será 1000 (999+1), si agregamos uno nuevo, 1001, ... Pero eso es al cargarlo durante la ejecución; no tiene nada que ver con el código (nº) interno que tiene el archivo.

No me lieis más que estoy corrigiendo exámenes de matemática...

[SplinterGU]

0 no, 1...

pero no entiendo entonces el cuestionamiento de que en DIV se podia hacer? eso del nombre del archivo y meterlo segun este, es externo a bennu y se podia hacer tranquilamente, sin plantearlo a Bennu...

Por otro lado, el codigo estaba incompleto, ahora se completo...

Si se guarda el codigo debe darsele utilidad en el core de bennu, si el codigo no se le da utilidad debe eliminarse el seteo de este...

[SplinterGU]

a ver... voy a justificar por que creo que esta bien la modificacion actual...

Todo el sistema de mapa internamente espera el codigo contenido en el .map para crear el mapa (no solo lo espera, sino que lo usa)... incluso las funciones de creacion de mapas tienen como parametro "code"...
Bien, cuando un mapa es cargado en memoria, el campo "code" de dicho archivo es usado para crear el mapa en memoria, y de hecho el mapa es creado con ese codigo... ahora la misma funcion es usada para mapas que no tienen codigo... bien... ahora todo el sistema usa ese codigo... pero cuando la funcion de carga retorna a un nivel superior (funcion invocadora) el codigo del mapa es pisado por un pedido de proximo id libre... y luego asignado al fpg (siempre se asigna al fpg, sin importar si es mayor o no que 999)... sin chequear al hacer esto si el mapa tenia un codigo asignado (y por ende haber hecho todo el tratamiento que hizo previamente con el codigo)...
ahora viendo todo esto, yo quiero suponer que el bug esta en la falta de ese chequeo y no en todo el sistema... pensar lo contrario seria pensar muy mal de la programacion anterior de fenix... cosa que no me parece logico viendo un sistema de tratamiento del codigo del mapa coherente, salvo por la falta de este chequeo...

[Drumpi]

Jajaja, al final voy a tener razón al hacerme mi propio código de save_map y save_fpg :D:D:D
(Está publicado por el foro, con el código del programa cambia_color o ccolor, por si alguien lo quiere usar, modificar o lo que sea :P)

[SplinterGU]

Jajaja, al final voy a tener razón al hacerme mi propio código de save_map y save_fpg :D:D:D
(Está publicado por el foro, con el código del programa cambia_color o ccolor, por si alguien lo quiere usar, modificar o lo que sea :P)

Por que? si funciona bien...

[SplinterGU]

Bien, maldicion, en DIV no le da bola al campo code (testeado, guarda todo mapa con codigo 1)... y tampoco se pueden agregar mapas a un fpg desde codigo (por lo menos no figura en el help)...

Bueno, retirare parcialmente el cambio, y pondre una aclaracion bien grande en el codigo, lo de agregar un parametro para modificar el codigo me parece sin sentido e ilogico a nivel Bennu si no se tiene en cuenta... no me cuesta nada poner el parametro, pero ese parametro traera luego confusion...

Estoy abierto a explicaciones logica de porque meterlo que no sea solo para suministrar funcionalidad a una aplicacion externa... no es logico que el producto (BennuGD) se integre a una aplicacion externa, deberia ser a la inversa... pero tratemos de buscarle una solucion al problema...

EDIT: Ya subi al site el fix que vuelve atras esto...

[DCelso]

A ver, por lo que comentais un archivo .map es como cualquier otro formato de imagen (bmp o png) al que además se le han añadido algunas propiedades más como la de nombre, código y puntos de control.
Esto debe de tenerlo encuenta bennu y (aplicando lógica de objetos bean) debe poder encapsularse, es decir, poder permitir cambiar todas sus propiedades. Sino, como bien dice Splinter, si una propiedad no se usa, pues entonces para que ponerla en la estructura de datos del map. Por tanto yo creo que deben existir:
Funciones para cargar el archivo .map en la estructura (load_map).
Funciones para modificar la estructura [set_map_name, set_map_code, set_control_point, .. o incluso una que haga todo a la vez set_properties(idmap,"nombre",codigo,{{1,2},{2,4}}) ]
Funciones que usen la estructura para hacer cosas ( procesamiento interno de dibujo de bennu)
Funciones para guardar la estructura en disco (save_map)
Así se trabajaría de forma transparente tal y como manda la teoría de beans. Al igual que Spliter veo un poco chapucero poner save_map(idmap,codigo) puesto que ya se supone que el código está dentro de la estructura a la que apunta idmap y el hacer este tipo de cosas crearía confusión entre dos códigos(el almacenado en la estuctura y el pasado como parámetro). Más correcto sería hacer un set_map_code antes de un save_map.
El problema parece es que actualmente fenix/bennu no ha ofrecido forma de cambiar esto directamente sobre el map, solo lo hace al añadirlo a un fpg.
No recuerdo como lo hace DIV, pero lo lógico es pensar que el valor code  solo lo usa para que cuando insertemos los .map en un .fpg  pueda saber si es una imagen nueva o es una retocada para cambiar siempre y cuando esté entre 1 y 999.
En el caso de no estar en un .fpg y usarse el .map solo, está como de adorno puesto que le va a dar igual al motor para dibujarlo.
Por eso en el código original de fenix no hace nada con ese valor y siempre pone el mismo, quizas lo que pasa es que nunca se pensó en que al guardarlo desde el engine se perdería el valor. A lo mejor habría que distinguir entre el valor que se leyó del .map y el valor que necesita tener en la estructura en memoria el map,que es a lo que haceis referencia para valores mayores a 999

No obstante, la solucion sería poder cambiar el valor del código de la estructura .map, antes de guardarlo. Ya que si necesitamos hacer aplicaciones de retoque y ajustes de fpgs, maps no podríamos usar como lenguaje de programación a bennu mismo al no ofrecer la posibilidad de cambiar todos los valores de la estructura map donde guarda los datos, y tal y como dice darío, no podríamos extraer un .map de un .fpg con una aplicación no fenix/bennu, abrir ese map con una aplicacion de retoque de imagenes programada en bennu, guardar el .map resultado y volver a insertar con una aplicacion no fenix/bennu el .map resultado ya que bennu perdió el valor del código del map o no te permitió cambiarlo.

Desde mi punto de vista estais los todos en lo cierto pero no llegais a entenderos mutuamente .D.

[SplinterGU]

quizas es necesario explicar que el code de la propiedad define al objeto en memoria, el objeto en memoria "es" por su code, y solo se referencia por este... para cambiarle el code existe fpg_add... si uno cambia el codigo de un archivo todo lo que se este usando que haga referencia a este (graph, por ejemplo) queda apuntando a la nada o a algo inexistente...
querer cambiar el code de un grafico cargado es como querer cambiar el id a un proceso (Bennu o sistema operativo) o el FILE (handle) a un archivo abierto, no deberia permitirse nunca, por algo fue asignado en su creacion...
No existe el concepto "code del archivo" y "code en memoria", es uno solo, tener 2 provocara mas confusion...
En fenix graba siempre el de memoria, pero nunca lo utiliza, al cargarlo lo reasigna...
DIV nunca graba el codigo, siempre le pone 1 al codigo  (probado en DIV2), o sea, que creo que era una funcionalidad que nunca completaron o les quedo obsoleto el formato...
Para mi la solucion no esta en el elemento code dentro del archivo... para mi la solucion esta en como se exporta y como se importa el mapa, con esto quiero decir, (como dijo izubiaurre), si uno quiere modificar un grafico y que este se vuelva a colocar en la misma posicion, entonces la solucion deberia estar en el nombre del archivo... incluir o guardar el grafico con el codigo de mapa dentro del fpg como parte del nombre del archivo, y al levantarlo nuevamente buscar en ese mismo nombre el codigo donde debe ser ubicado, esto tiene que ser algo que maneje el programador, no el lenguaje... un ejemplo de eso, es el png2fpg que hay en la carpeta de samples en el site de betas...

[Drumpi]

Que yo recuerde, la única funcionalidad del campo se usó en el IDE de DIV, para sacar un gráfico, retocarlo y volver a meterlo en su sitio. Creo recordar que, cuando se intenta volver a meter, el valor que sale por defecto para la posición en el cuadro de diálogo, es la posición que tenía antes, y que es la que se almacenó en ese campo al hacer la copia fuera del fpg.
Pero el valor ese es para lo dicho: recordar donde estaba para poner el valor por defecto al volverlo a meter (o por si alguien lo quiere usar para su propio editor). No creo que haya que darle más importancia.

[SplinterGU]

En DIV yo lo probe, y siempre setea en 1 a todo mapa que graba a disco.