Me ha surgido una dudilla: ¿hay alguna forma de indicar el código de un map a la hora de guardarlo? Es decir, el formato map guarda el código del mapa y es intersante esto precisamente a la hora de añadir los mapas a los fpgs. Por ende, si no hay forma de indicar dicho código creo que debería existir (quizá un parámetro más a la función save_map)
La duda me ha surgido al guardar un mapa con fenix, se le ha asignado el código 1000. Me suena que leí que es porque ahora Bennu asigna automáticamente códigos del 1000 en adelante. Sin embargo, esto no es coherente con el límite de los fpgs, ya que creo recordar era hasta el 999. Yo creo que si el map tiene un código del 1000 en adelante, al hacer el save_map se debería asignar el código 0.
Un saludo,
Darío (danko)
Esto no es de "ahora en Bennu"... siempre los mapas cargados individualmente tuvieron codigo por encima de 999... los mapas en si, no tienen codigo, el codigo es para las librerias (fpg)... pero vos podes asignarles el codigo y agregarlos a una lib, usando fpg_add o add_fpg... siempre fue asi en Fenix... es coherente que asi sea...
Quote from: darío on October 12, 2008, 02:10:23 AM
Me ha surgido una dudilla: ¿hay alguna forma de indicar el código de un map a la hora de guardarlo? Es decir, el formato map guarda el código del mapa y es intersante esto precisamente a la hora de añadir los mapas a los fpgs. Por ende, si no hay forma de indicar dicho código creo que debería existir (quizá un parámetro más a la función save_map)
La duda me ha surgido al guardar un mapa con fenix, se le ha asignado el código 1000. Me suena que leí que es porque ahora Bennu asigna automáticamente códigos del 1000 en adelante. Sin embargo, esto no es coherente con el límite de los fpgs, ya que creo recordar era hasta el 999. Yo creo que si el map tiene un código del 1000 en adelante, al hacer el save_map se debería asignar el código 0.
Un saludo,
Darío (danko)
No estoy seguro al 100%, pero, me suena que en DIV2 cuando sacabas un mapa de una fpg, el mapa resultante tenía un número. Me explico, arrstrabas un mapa desde una fpg al escritorio de DIV2 y se creaba como un mapa aparte. Pero, ese mapa tenía un número, el que tenía en la fpg. Entonces, cuando modificabas la imágen (pintar, retocar un poco), cuando volvías a arrastrar al fpg, se guardaba en la posición anterior.
QuoteEsto no es de "ahora en Bennu"... siempre los mapas cargados individualmente tuvieron codigo por encima de 999... los mapas en si, no tienen codigo, el codigo es para las librerias (fpg)... pero vos podes asignarles el codigo y agregarlos a una lib, usando fpg_add o add_fpg... siempre fue asi en Fenix... es coherente que asi sea...
El formato MAP sí que guarda el código del gráfico. Fíjate en el funcionamiento de la herramienta MAP.EXE, el código del gráfico se lo asignas con MAP.EXE, no a la hora de añadirlo al FPG.
En mi opinión, el formato MAP existe por si solo y puesto que uno de los valores que guarda es el código del gráfico y creo que se debería poder asignar a la hora de guardarlos. Supuesto el caso de que usamos FPG.EXE para crear FPGS, uno puede generar un montón de gráficos desde bennu y no tendría que ir haciendo MAP.EXE +id=# ... Bastaría con añadir los fpgs. Además, si estamos generando MAPS cuyo código es 1000 o superior, se supone que no podríamos añadirlos al FPG...
En fin, no se si me he explicado bien. Simplemente no me parece que tenga sentido que una propiedad inherente de los MAPS no se pueda especificar al guardar...
Lo que dice Izubiaurre es cierto y por eso le veo aún más sentido a lo que yo propongo.
A todo esto, ¿se puede asignar el nombre del mapa?
Gracias, un saludo,
Darío
bueno, vamos por parte... lo que decis parece ser cierto... ya que el codigo desde la 0.74 (fenix, no tengo una version mas vieja a mano) hasta la actual 0.93 (Bennu), cargan (y crean en memoria) el mapa con el codigo dentro del archivo .map, pero... la funcionalidad esta incompleta, porque luego de eso, al retornar de la funcion de carga, lo pisan con un nuevo codigo... tampoco liberan, al momento de cargar, el mapa anterior cargado con ese mismo codigo... o sea, que si bien parece ser cierto, nunca funciono... puedo corregir eso, pero no se que afecta... tengo que revisar todo...
edit: que el codigo vaya mas alla de 1000 no significa que no se pueda asignar a un fpg... por otro lado, con estos cambios solo estamos asignando al fpg 0, default... quizas deberiamos tener una forma de poder hacerlo mas generico, y poder meter mapas en cualquier fpg...
pero bien, vamos a un paso por vez...
Según creo yo, es normal que dentro de fenix la propiedad Código se pise cuando cargas el gráfico individualmente, ya que al no estar dentro de un FPG uno prescinde del código y trabaja con el identificador que da la función load_map.
Sin embargo, si hablamos de Archivos MAP escritos en disco, me parece interesante que dicha propiedad se pueda especificar (solo a efectos del archivo en disco) porque de ese modo se puede simular el comportamiento tipo DIV. Generar maps y luego poder meterlos en FPGs rápidamente, ya sea con FPG.exe, con flamebird o con cualquier otro editor de FPGs.
Lo que yo pido es un cambio minúsculo (un parámetro más a la función save_map, quizá opcional, y que se escriba ese valor en disco).
kim-elet-o: Creo recordar que a la hora de añadir el map al fpg te pedía que ingresases el código del gráfico, pero por defecto te mostraba el que contenía el fichero map. Esta "característica del IDE" está íntimamente ligada a la característica de los maps debido a que podían guardar ese valor.
El valor se escribe siempre en disco... el cambio parece no afectar (si lo hago bien, cosa que no siempre es asi... en un "100%" de los casos fallo... pero bueno, hay limites, todo no se puede pedir... :P), yo digo de que el codigo se grabe a disco solo si es menor a 1000, o sea, pertenece a un fpg...
que te parece eso?
PD: Estoy en el messenger...
Quote from: darío on October 12, 2008, 11:31:00 AM
A todo esto, ¿se puede asignar el nombre del mapa?
Por supuesto, MAP_NAME(fpg,code) y MAP_SET_NAME(fpg,code,name)
done! ahora el load_map al cargar un grafico si su codigo es > 0 y < 1000 lo inserta en su lugar, descargando el anterior... no fue tan simple como se supone, no por el cambio en si de este comportamiento, eso tardo menos de 1 minuto (bueno, 5 minutos, habia que abrir varios archivos y tocar unas cuantas funciones...), pero el problema estaba en las funciones nuevas de optimizacion de busquedas/reserva de bitmaps...
pero ya esta...
bueno, en menos de 1 hora no estare disponible durante casi todo el dia... hoy estoy de anfitrion en casa...
saludos...
No era a eso a lo que me refería. A ver si te veo por el messenger y podemos hablar más tranquilamente, no se si estoy explicándome bien. No he estado en casa porque vinieron a visitarme a estolmo y he estado haciendo de guía turístico...
Un saludo,
Darío
1) tu has pedido que si el map tiene codigo, al cargarlo, lo ubique en el fpg con el codigo que tiene el map en su archivo... y eso es lo que hice... pero un fpg solo tiene codigos de 1-999, entonces codigos diferentes a este valor no se guarda el codigo en el archivo y si el archivo lo llegara a tener, no se toma ese codigo...
2) preguntaste si se podia asignar el nombre a un map... si, se puede, MAP_SET_NAME(fpg,code,name)... adicionalmente como un bonus te di el nombre tambien de la funcion que sirve para obtener el nombre del mapa...
no se que no entendi... me podrias explicar?
No se, pero lo de los códigos y los nombres en los maps me parecen una característica que queda obsoleta, o como mucho, poco útil. Eso estaba bien cuando en DIV tenían su entorno y, para simplificar un poco las cosas, se usaban esos identificadores para recuperar su posición.
Corregidme si me equivoco, pero al meter un map en un fpg por código ¿no había que especificar su posición? es más, creo que es un error forzar un lugar automáticamente pisando alguno que anteriormente estuviera ahí si, por algun error, el map se crea con un número que no hemos tenido control directo de poner. Quiero decir que prefiero mil veces que el mapa se ponga como nuevo en la última posición (salvo que se especifique lo contrario) a que pisotee a los demás.
- es un tema, yo no se el cambio que impactara, supongo que pocos usan map como tales... por lo general se cargan fpg, png, y otras cosas...
- bien, lo de los codigos y nombres puede que sea obsoleto, es cierto, pero es mas que nada por compatibilidad...
- en el caso de los cargados por fpg esta bien que asi sea, pero en el caso de los creados en runtime, yo pondria en vez de codigo, el area de memoria que ocupan como id de codigo, esto seria mucho mas rapido, pero bueno, por compatibilidad y por otros motivos internos tiene que quedar asi... (por favor no me pregunten que motivos internos...)
- el codigo es el orden del mapa dentro del fpg... el codigo es el slot que usa...
- cuando un mapa se crea con code 0, pero antes de retornar del modulo de mapas, se le asigna uno libre por encima de 1000...
- solo en el caso que el mapa tenga codigo, al cargarlo y solo al cargarlo desde un fichero este se ubica en el lugar indicado por el fichero (solo codigos 1-999)
- el codigo de un map no puede ser modificado por el usuario, salvo usando fpg_add...
Perdón por tardar en contestar, ayer estuve algo ocupado.
Quote1) tu has pedido que si el map tiene codigo, al cargarlo, lo ubique en el fpg con el codigo que tiene el map en su archivo... y eso es lo que hice... pero un fpg solo tiene codigos de 1-999, entonces codigos diferentes a este valor no se guarda el codigo en el archivo y si el archivo lo llegara a tener, no se toma ese codigo...
No, yo no he pedido eso. Yo he pedido que podamos especificar el código del mapa AL GUARDARLO (al hacer save_map). Es bien distinto. ¿Por qué? Porque si el máximo código es 999 no le veo sentido a que se guarde en disco con un número mayor a ese (imagina que usamos FPG.EXE para añadir un mapa creado con save_map, no debería funcionar bien ya que estaríamos por encima de 999).
El comportamiento de Carga creo que debería mantenerse como estaba. Es cierto que no mucha gente usa los maps individualmente pero si alguien los usa (yo lo hago, por ejemplo) el cambio que has realizado puede dar lugar a errores difícil de localizar, ya que obliga a que modifiquemos los maps que tengamos con un código superior a mil, algo que no se puede hacer con ningún herramienta actual (ni si quiera con bennu ya que save_map no incluye el parámetro adicional que yo propongo).
El uso de maps como tales tiene la ventaja de poder especificar los puntos de control.
Quote2) preguntaste si se podia asignar el nombre a un map... si, se puede, MAP_SET_NAME(fpg,code,name)... adicionalmente como un bonus te di el nombre tambien de la funcion que sirve para obtener el nombre del mapa..
Sí, olvidé decir gracias :). Las busqué en el bennuwiki y no las encontraba, por eso pregunté.
Bueno, en cualquier caso, gracias por las molestias y espero haberme hecho entender ahora.
Un saludo,
Danko
Quote from: darío on October 13, 2008, 11:35:46 AM
Perdón por tardar en contestar, ayer estuve algo ocupado.
Quote1) tu has pedido que si el map tiene codigo, al cargarlo, lo ubique en el fpg con el codigo que tiene el map en su archivo... y eso es lo que hice... pero un fpg solo tiene codigos de 1-999, entonces codigos diferentes a este valor no se guarda el codigo en el archivo y si el archivo lo llegara a tener, no se toma ese codigo...
No, yo no he pedido eso. Yo he pedido que podamos especificar el código del mapa AL GUARDARLO (al hacer save_map). Es bien distinto. ¿Por qué? Porque si el máximo código es 999 no le veo sentido a que se guarde en disco con un número mayor a ese (imagina que usamos FPG.EXE para añadir un mapa creado con save_map, no debería funcionar bien ya que estaríamos por encima de 999).
El comportamiento de Carga creo que debería mantenerse como estaba. Es cierto que no mucha gente usa los maps individualmente pero si alguien los usa (yo lo hago, por ejemplo) el cambio que has realizado puede dar lugar a errores difícil de localizar, ya que obliga a que modifiquemos los maps que tengamos con un código superior a mil, algo que no se puede hacer con ningún herramienta actual (ni si quiera con bennu ya que save_map no incluye el parámetro adicional que yo propongo).
El uso de maps como tales tiene la ventaja de poder especificar los puntos de control.
Quote2) preguntaste si se podia asignar el nombre a un map... si, se puede, MAP_SET_NAME(fpg,code,name)... adicionalmente como un bonus te di el nombre tambien de la funcion que sirve para obtener el nombre del mapa..
Sí, olvidé decir gracias :). Las busqué en el bennuwiki y no las encontraba, por eso pregunté.
Bueno, en cualquier caso, gracias por las molestias y espero haberme hecho entender ahora.
Un saludo,
Danko
Veo que redacte mal el texto o lo leiste muy por encima...
Yo dije "nunca se graba CODIGOS mayores a 999"...
Cual es el sentido de grabar el codigo si luego la carga sera igual como siempre?
Los CODIGOS por encima de 999 "EN MEMORIA" no se graban a disco (se graban con CODIGO 0)... para que se grabe a disco con un codigo especifico hay que INCLUIRLO en un FPG... entonces toma el CODIGO que tiene en el FPG en MEMORIA...
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...
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?
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... :P
Todo grafico con codigo mayor a 999 en memoria, al grabarlo se graba con codigo 0, y al cargarlo se le asigna automaticamente un nuevo CODIGO... o sea, se comporta como lo hacian TODOS los mapas hasta ahora... solo los que tienen codigo de 1-999 se ubican en su posicion ya asignada por su CODIGO dentro del FPG 0...
Buenas, vayamos por partes:
QuoteVeo 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.
QuoteYo 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.
QuoteNo 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).
QuoteLos 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)
QuoteCon 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.
Quote- 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
Quote from: darío on October 13, 2008, 07:04:19 PM
Buenas, vayamos por partes:
QuoteVeo 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.
QuoteYo 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.
QuoteNo 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).
QuoteLos 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)
QuoteCon 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.
Quote- 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?
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... :)
Quote from: SplinterGU on October 13, 2008, 07:51:38 PM
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...
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...
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...
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)
Quote from: Drumpi on October 15, 2008, 10:48:48 AM
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...
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...
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.
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...
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.
En DIV yo lo probe, y siempre setea en 1 a todo mapa que graba a disco.