[KANBAN] Stats Datos de misión desde el reporte

[corp-0]

Capturar desde el RPT los datos de misión para poblar los campos de la misión en la base de datos.

Dichos datos son:

1. Nombre de misión (variable vanilla onLoadName)
2. Nombre de autor (variable vanilla author)
3. Nombre de campaña (variable KDM NOMBRE_CAMPA)
4. Tipo de misión (variable KDM TIPO_MISION)

Requiere modificar el KDM

[cyberpunx]

NOMBRE_CAMPA Va a ser case insensitive, pero tiene que estar escrita tal cual una ya existente si queremos que se asigne a una existente. En caso de no existir, segun el TIPO_MISION se va a crear una con ese nombre o asignarla a una campaña generica mensual.

Posibles valores de TIPO_MISION

'CAMPANA'  
'ENTRENAMIENTO' 
'GALA'
'IMPROVISADA'
'CURSO' // Aspirantes entran en curso
'COOPERATIVA'
'OTRO'

Otros datos que deben estar en el rpt:

es_oficial: True / False si es misión de martes y jueves. Tipicamente si el TIPO_MISION es CAMPANA, ENTRENAMIENTO, GALA se podría tomar como oficial. exito: True / False (si la misión fue exito o fallo) mapa: nombre del mapa donde se jugó

Extras/Opcionales

imagen: en principio la misma imagen de la pantalla de carga (Si no esta, poner una default) descripcion: sinopis en no más de 140 caracteres

[corp-0]

Ahora mismo KDM consulta qué tipo de misión es y da algunas opciones, las que son:

1. Misión Oficial
2. Entrenamiento
3. Improvisada
4. Gala
5. Instrucción
6. Otro

Esos valores están basados en lo que vi en los models de zrstats, con acentos y mayúsculas como mismo aparecen ahí.

============================================================

Sobre las campañas, yo creo que tenemos que usar un nombre visible que vendría tal cual está escrito y una ID que armamos con el nombre, pasando todo a mayúscula y quitando carácteres especiales... Para prevenir problemas con eso.

============================================================

es_oficial es necesario? Yo creo que tomas el tipo de misión y si es "Misión Oficial" o "Entrenamiento", ya está. No sería necesario que eso venga en el RPT.

============================================================= descripcion puedo agregar igual, tomando la descripción de misión vanilla pero es relativamente corta (la que aparece cuando estás cargando). Es más una frase que una descripción de la misión.

[cyberpunx]

Los valores de TIPO_MISION son tal cual los que puse recién arriba. Los valores con tildes etc, son para mostrar, pero no se guardan así en la DB.

El es_oficial se puede obviar en el reporte por el momento, en pos de mantener la info requerida al mínimo. El día que juguemos campañas o entrenamientos no oficiales habrá que destildar a mano esa información.

El nombre de la campaña, como digo, es case insensitive, pero igualmente tiene que estar escrito tal cual para asignarla a una campaña existente. Si la campaña se llama "Tormenta del Desierto" y en el rpt el editor pone "La Tormenta del Desierto". El sistema toma como que son 2 campañas distintas. Se puede intentar utilizar una sentencia similar al "like" del SQL, pero igualmente no es ni de lejos infalible.

la frase corta como descripcionde la misión sirve perfecto, es para poner un pequeño subtitulo al nombre de la misión.

[corp-0]

No me fijé que cambiaste los tipos, ahora cambio a los tipos actuales.

Te propongo otra forma de hacer las campañas, por defecto TODAS las misiones son de la campaña "--", que es lo mismo que no tener campaña. Luego, si alguien cambia el nombre de campaña al crear la misión, pues ese nombre pasa a crear una nueva campaña. Así Mantenemos los tipos que teníamos antes, que son más generales encuentro yo, porque pueden haber misiones oficiales que no son de campaña.

[cyberpunx]

En principio campaña y tipo_mision son 2 cosas independientes. Salvo para ciertos mecanismos automatizados que hacen depender el uno de otro.

Ten en cuenta que la campaña dentro de la misión ahora es un objeto propio. Es decir en la base de datos pasó de ser un atributo string dentro de MISION para pasar a ser una fk a la tabla CAMPAÑA donde esa campaña tiene su propia fila. Por lo tanto cuando el rpt trae un nombre_campaña yo tengo que realizar una busqueda en la tabla Campaña y elegir una. Es por eso que hay que tener cuidado de que el editor escriba BIEN (más allá de los mecanismos que implementemos, pasar a mayus, sacar tildes, etc).

En un futuro, podemos hacer una GUI para el KDM que traiga las capañas de la DB, entonces en lugar de escribir el nombre, seleccionas y solo escribirías si es una nueva. Ahí se reducen las chances de pifiarla

Y luego decidir que hacer cuando te llega un nombre campaña y no coincide con ninguna existente de la tabla... Si se asume que es una nueva y se crea una nueva. Si se deja nulo el campo (el campo campaña es nulleable), etc..

[cyberpunx]

En cuanto a TIPO_MISION, creo que como está ahora describe mejor la situación de una misión. Antes se estaban mezclando dos conceptos en uno: la "oficialidad" de la misión y el "tipo" propiamente dicho.

El caracter Oficial de la mision solo se decide por el dia en que es jugada (Martes y Jueves), independientemente del TIPO_MISIONque sea... Es por eso que apareció el booleano es_oficial.

De este modo, ahora se puede tener una impro y hacerla oficial (como fue el caso de ayer), podes tener un entrenamiento y hacerlo oficial... etc.. De caso contrario, también podés hacer campañas no oficiales (si alguien decide encadenar una serie de impros los domingos por ejemplo)

De la forma anterior no se podía hacer que un ENTRENAMIENTO sea oficial, ya que para eso habia que escoger "Misón Oficial", ¿y como distingo si ese dia oficial fue campaña o fue entrenamiento? ¿me sigues?

[cyberpunx]

De hecho, escribiendo el post anterior me doy cuenta que el campo es_oficial ni siquiera tiene que venir en el rpt... (igual ya me lo olía). Simplemente es cuestión de mirar la fecha de la misión y ver si ese día cae martes o jueves. (Se puede incluso mirar un rango horario, para permitir que existan improvisadas no oficiales los martes por la tarde por ejemplo)

[cyberpunx]

Resumiendo mis ultimos 3 post.

TIPO_MISION: Adaptarse a los tipos nuevos. es_oficial: no viene en el rpt, lo manejo del lado de django, nombre_campaña: Puede ser null, pero si no es null, atento a escribirla bien para asignarla a una existente. O escribir cualquier cosa inexistente para generar una nueva con ese nombre.

[corp-0]

Paso esta tarjeta a Ready, puesto que ya se cumplen las tareas dispuestas. Con tu confirmación, puedo cerrar el issue.

[cyberpunx]

¿ya está arreglado el campo que venía incorrectamente con el nombre? creo que era TIPO_MISION?

si es asi lo cerramos nomas

[corp-0]

Sip, está resuelto eso. Cerrado entonces 💃