NVGT

que onda. acá les vengo a ahcer mi primer aporte. es una clase de traducción que creó un compa gringo y modificada por mi.
la clase originalmente usaba dics. y se preguntarán: ¿asmodeus porqué cambiaste los diccionarios por arraes? pues en la práctica descubrí que era lentíisima la función de búsqueda. entonces me decidí por usar arraes y subió muchísimo el rendimiento.
nota: la función t_ funciona perfecto... pero find y find_split son pequeñas variaciones/caprichos que le hice para no cambiar tan radicalmente el sistema de traducción de uno de mis juegos.

algo que nunca entendí, quizás por mi falta de conocimiento lol, qué diferencia hay entre m.run y m.monitor? por lo que vi los dos funcionan bien, m.monitor supongo que sería por si quieres manejar teclas en el menú a parte de las básicas o... qué se yo.

erlking escribió:
algo que nunca entendí, quizás por mi falta de conocimiento lol, qué diferencia hay entre m.run y m...

no me acuerdo yo porq hace rato q no uso el menu (si hablas de ese) pero yo supondria q si va por ese lado, tipo el monitor para loop no bloqueante y run para el contrario, yo que se

erlking escribió:
algo que nunca entendí, quizás por mi falta de conocimiento lol, qué diferencia hay entre m.run y m...

run es una función que ejecuta un bucle en lo que elijes una opción y al selexionarla devuelve su posición en la lista.
monitor es para crear tu propio bucle y monitorear el menú. mira, te dejo un egemplo que siento que no me expliqué bien :D

```
void main_menu()

creo que ya entendí. a la larga siento que conviene mejor el run

para cosas simples si es mejor el run. ya si es algo más abanzado el monitor

Yo igual aquí dejo un aporte, es una clase q maneja archivos y carpetas en pack_files (archivos .dat), permite cargar el dat en memoria para poder añadir o eliminar carpetas y archivos a ese pack en tiempo de ejecución sin necesidad de eliminar y estar creando dats a cada rato. o sea sí lo hace pero es de manera interna, por lo que si por ejemplo se están añadiendo archivos o modificando el contenido de los mismos dentro de un programa o juego una vez hechos todos los cambios se puede guardar ese archivo con los cambios hechos y ya entonces se guarda todo de una y se evita estar guardando a cada ratito. que se puede, pero no es lo recomendable.
así mismo si esto deja voy a meter el encriptador y el desencriptador para los q gusten usarlos, funcionan de manera recursiva por lo q si se elige una carpeta se mete automáticamente cada subcarpeta con sus respectivos archivos.
Added: Nomás se me adjuntó el packer JAJASJAJJAJA yo pensé que esto permitía varios archivos pero me reemplazó los otros, en cuanto tenga chance o alguien postee voy poniendo los otros.

posteo para que mande los otros

aquí adjunto un zip con los 3 archivos juntos, el packer, extracter y el principal

muy buena. yo ando viendo como manipular data así para guardar por ejemplo una partida o al menos cosas simples como el nombre o algo así, no renta hacerlo en un txt nomá

erlking escribió:
muy buena. yo ando viendo como manipular data así para guardar por ejemplo una partida o al menos c...

hazlo con el objeto settings, ese justamente es para eso

hola, esto no es exclusivamente de nvgt pero igual lo pongo aquí para no crear un hilo aparte, alguno tiene mas o menos una idea de hacer un tipo parser básico para bloques? o sea maso se me ocurre q podría usar una verificación simple de si se detecta una apertura de bloque en x línea y luego instanciar alguna clase q use todas las líneas desde donde se detectó la apertura hacia adelante hasta que detecte una llave de cierre si es así, esto almacenando por ejemplo el nivel del bloque para tema de bloques anidados y así tener el control de cada apertura y cierre, o en su defecto inicializar desde un principio la clase con el contenido general para que ya vaya teniendo ahí y solo usarlo para consultar en dado caso, y por ejemplo guardar como elementos hijos bloques de su mismo nivel y su bloque padre.
o sea recapitulando el flujo porq siento q no lo expresé del todo bien:

• se haría una clase code_block_parser.
• la clase tendría un método para recibir datos de entrada ya sea q se queden guardados como tal en crudo o no, así como una lista de objetos code_block (children) esto para los bloques detectados en el nivel raíz.
• este método inicializaría una variable contador de nivel q empezaría en 0 (el nivel actual donde estaría el contenido general), para luego llamar a otro método interno el cual recorrería cada línea del contenido y q tomaría como parámetro tmbn la variable de nivel pero pasada por referencia.
• este otro método si detecta en una de las líneas por ejemplo la apertura de una llave aumentaría en 1 la variable de nivel y seguiría buscando recursivamente, aumentando la variable de nivel por cada bloque abierto esto para bloques anidados.
• Al estar leyendo las aperturas, también estaría leyendo los cierres, y por ejemplo si detecta una llave de cierre entonces se crea un objeto code_block, se guarda el contenido q esté entre esas dos llaves y se inserta al nivel actual, restando a su vez la variable de nivel pasada por referencia por tema de control. En el caso del nivel 1 se guardaría en el children del code_block_parser como primeros bloques hijos, y ya conforme vayan avanzando se irían guardando internamente en su respectiva lista children (la correspondiente a cada code_block).
• Si detecta ya al final de la ejecución q la variable de nivel no está en 0 significaría q hubo un bloque sin cerrar, por lo q ya sea q se lance una excepción o q se anule toda la operación y se guarde la advertencia en un log por control.

No sé si estoy bien, esto es lo q se me ocurre muy superficialmente, ya si lo leen los q saben mas pues seria cosa de q me corrijan en lo q esté mal JAJAJA.
salu2

Angel_R05 escribió:
hola, esto no es exclusivamente de nvgt pero igual lo pongo aquí para no crear un hilo aparte, algu...

Pues la neta tu idea va bien. Para algo básico no necesitas hacer gran cosa más complicada. Con que leas línea por línea, vayas checando dónde se abre un bloque, subas el nivel, y cuando veas la llave de cierre vuelvas a bajarlo, ya con eso puedes ir armando la estructura sin pedos.
Lo de crear un objeto cada vez que cierras un bloque también está bien, y ya según el nivel en el que estés decides si ese bloque es hijo del parser o hijo de otro bloque. Eso es justo lo que hacen casi todos los parsers simples: mientras más profundo estás, más anidado queda el bloque.
La idea de manejarlo con una función que se llame a sí misma también funciona, y es común para este tipo de cosas. Igual podrías hacerlo con una pila, pero para lo que quieres no hace falta complicarlo (por ahora, al menos).
Y sí, es buena idea que al final revises si el nivel quedó en cero. Si no, pues algo se quedó sin cerrar y ya tú decides si avientas error o solo lo avisas lo que sea.

Rayosaurio escribió:
Pues la neta tu idea va bien. Para algo básico no necesitas hacer gran cosa más complicada. Con que...

justo, lo quiero para algo realmente básico como guardar cierto contenido correspondiente a un formato tipo para no tener q repetir mil veces el formato y así facilitar las cosas pero también me gustaría dejarlo preparado por si lo llego a usar en un futuro.
el tema de la pila lo estuve checando con chatgpt y creo q entendí, es cosa de q si detecta la apertura de un bloque q cree un objeto nuevo y cheque si la pila ya tiene bloques insertados y ponga como padre el último de esa pila para luego insertar ese al final si es así, poniendo en los bloques raíz del parser en caso contrario y marcando la posición inicial desde donde empieza el bloque. ya para el tema del cierre sacaría el último bloque insertado en la pila, marca el idx de la posición final de las líneas/texto y entonces lo zumba de la stack, ahi si estoy mal me dices pero segun yo asi era como me lo decia esa madre

Angel_R05 escribió:
justo, lo quiero para algo realmente básico como guardar cierto contenido correspondiente a un form...

smn así mero es