PROGRAMMARE CON PYTHON

Rhayom non riesco a capire perchè non mi funziona nel mio programma la conversione da testo a binario... ho usato i "print" per vedere i valori che hanno le variabili o le stringhe e funziona tutto ma il fila convertito dopo il 4 ciclo di miniblock mi sbaglia completamente di inserire i valori, ho trovato numero con esponente -42 cioè sotto il massimo di -38, come è possibile che mi scriva numeri fuori dal formato.
Prova a convertire il testo in binary e poi di nuovo in testo...
ho fatto una comparazione con "010 Editor portable" e ho visto molti byte aggiunti e molti floating cambiati completamente

che intendi per binario??? suppongo il formato dei file di m2tw..
cioè i primi 4 miniblock vengono scritti correttamente?

hai provato il programma?? (usa cmd.exe cosi vedi anche i print)
I file modelreferencepoint o anche tanti altri file sono tutti scritti in binario, quindi .dat o .medelrefpoint è la stessa cosa...
Nell'allegato ho il file.dat che viene convertito in file_exported.txt in maniera corretta ma l'operazione inversa cioè da file_exported.txt a file_exported_modified.dat mi fà un casino nei miniblock...
Questo lo vedi con un edito esadecimale con la capacità di fare paragoni tra due file oppure semplicemente riconverti in testo il file file_exported_modified.dat così vedi il casino che non riesco a capire.

Se riesci a trovare dove ho sbagliato bene, altrimenti amen.

cioè se vedi dopo il 4 ciclo mi scrive:

Testo nascosto - clicca qui

17 Artillery BackPFX 
1.0	0.0	0.0	1.0
0.0	1.0	0.0	5.0
0.0	0.0	1.0	0.0
0.0	0.0	0.0	1.0
6 exit01

17 Artillery BackPFX 
1.0	0.0	0.0	2.0
0.0	1.0	0.0	5.0
0.0	0.0	1.0	-3.66108610619e-023
8.82818032525e-044	0.0	0.0	0.0
1599 XXXXXXXXXXXXXXXX - nchar too long in getstring

1769497856 XXXXXXXXXXXXXXXX - nchar too long in getstring 
1.39777687943e-028	8.0	1.12891845364e+027	7.86620574861e+034
4.15528222499e+021	8.72194779382e+014	1.0	0.0
0.0	-2.0	0.0	1.0
0.0	4.0	0.0	0.0
1065353216 XXXXXXXXXXXXXXXX - nchar too long in getstring

cioè penso mi salti un byte quando legge il 12 float e cioè il numero -3.66108610619e-023 perchè ovviamente dopo i numeri che legge non corrispondono più quindi, la lettura è sfasata... dopo una ventina di cicli infatti torna a leggere correttamente.

per me binario significa anche 010101010000010.
adesso non posso provare perchè sul pc a lavoro non ho python installato.
cmq forse l'errore è dovuto al fatto che python non supporta la singola precisione, cioè 32 bit, ma supporta solo la precisione a 64 bit, e quindi ecco il motivo dei byte aggiuntivi.
Adesso bisogna capire come scrivere un numero decimale su 32 bit e non su 64.

Knoight Errant aveva scritto una funzione tipo questa:

Testo nascosto - clicca qui

# -----------------------------------------------------------------------------------
# Format float into a string with nfield.ndecimal fixed output. |
# -----------------------------------------------------------------------------------
def formatfloat( x, nfield, ndecimal ) :

formatstring = '%+' + str( nfield ) + '.' + str( ndecimal ) + 'f'

xstr = formatstring % x
return xstr

pensi sia una correzione del numero?? solo che non capisco cosa ha fatto, o meglio, mi sembra di aver visto nei tui link una funzione from.hex() che dava quel tipo di formatstring...

ma tu riesci a leggere correttamente come float un numero del tipo 2.35098870164e-038 ?

quella funzione di ke converte un numero float in una stringa con nfield cifre prima della virgola e ndecimal cifre dopo la virgola.

rhaymo, 21/01/2010 15.17:

---

ma tu riesci a leggere correttamente come float un numero del tipo 2.35098870164e-038 ?

---

non lo sò ma non funziona anche se sostituisco quei numeri con 0.0

e cosa legge?? fatti stampare ogni cosa che leggi dal file e vedi cosa ti legge quando arriva lì.

infatti, con i print non riesco a capire, me li scrive giusti...
E' proprio un rompicapo da cui non riesco a venirne fuori.
Vabbè adesso devo fare altre cose, proverò domani

quindi questo numero lo riesci a leggere 2.35098870164e-038??

---

def miniblockdata ( filein, fileout):
    for i in range(4):
        valore = getline(filein)
        for j in range(4):
            putfloat( float(valore[j]), fileout )
            print ("_%f_" % (float(valore[j])))

---

getline(filein) mi legge una riga alla volta, passa oltre quando sono vuote e mi fà lo split, inoltre ho messo dei print per vedere se i valori sono giusti. Inoltre ho impostato che numeri (negativi e positivi)< 0.0000001 diventano 0.0 così da evitare numeri troppo piccoli.
Le linee sono 4 con 4 float ciascuno, quindi mi scrive 16 float di fila ma quando analizzo con un editor esadecimale esattamente dopo l'undicesimo float mi aggiunge un byte di non so che cosa e poi scrive gli altri float, per quello che è tutto sfalsato:

allora, inizi ad avere problemi dal 3 blocco in poi, quindi suppongo che il problema siano i numeri scritti in questa maniera 2.35098870164e-038.
ps: anzi no....

è una cosa insensata, adesso ho adirittura scritto così quei 16 byte:

---

def miniblockdata ( filein, fileout):
    valore = getline(filein)
    putfloat( float(valore[0]), fileout )
    putfloat( float(valore[1]), fileout )
    putfloat( float(valore[2]), fileout )
    putfloat( float(valore[3]), fileout )
    valore = getline(filein)
    putfloat( float(valore[0]), fileout )
    putfloat( float(valore[1]), fileout )
    putfloat( float(valore[2]), fileout )
    putfloat( float(valore[3]), fileout )
    valore = getline(filein)
    putfloat( float(valore[0]), fileout )
    putfloat( float(valore[1]), fileout )
    putfloat( float(valore[2]), fileout )
    putfloat( float(valore[3]), fileout )
    valore = getline(filein)
    putfloat( 0, fileout )
    putfloat( 0, fileout )
    putfloat( 0, fileout )
    putfloat( 1, fileout )

---

Ho provato a cancellare esempio un putfloat alla volta così mi mettava solo gli altri ma niente, al 13 magicamente mi aggiunge un 0D=13.
Cioè non è possibile che l'errore provenga da altre funzioni perchè in quel momento funziona solo quella !!!
Proverò a chiedere a Wildog che è esperto (anche se mi aveva detto che non aveva tempo)

fra l'altro quel 13 è un ritorno a capo...

però è strano perchè io ho tolto tutte le linee vuote per evitare questo problema quindi ogni linea me la deve leggere, deve ritornarmi una stringa e me la deve fare splittare, però vedi che ho messo l'arrey valore[x] con x da 0 a 1 ??? anche se ci fosse il carattere /n non lo dovrebbe scivere

non è un problema di righe vuote, perchè quel 13 viene stampato fra due numeri successivi sulla stessa riga

ma io faccio anche un print dell'arrey line.split() e mi scrive
['0.0', '0.0', '0.0', '1.0'] quindi non c'è in mezzo un '\n' o qualcosaltro.
Provo a vedere la lunghezza della stringa per vedere se è maggiore di 4...

infatti la 4 riga/stringa è pulita cioè la lunghezza è 4, questo è un pezzo dei print che ho messo:

ho provato a sostituire quei numeri con molte cifre decimali con numeri con meno cifre decimali e il problema sembra sparito....

sembra perchè me li scrive negli ultimi tre adesso... no, qua c'è qualcosa di subdolo e perverso. Io ho provato a chiedere a wildog, altrimenti amen, non mi va di perdere troppo tempo per questo errore, dirò a quello di twcenter di farlo a mano anche se poteva servire a qualcun'altro

ma non era per te?

anche, ma poi me lo hanno chiesto altri...
docs.python.it/html/tut/node15.html
qui dice che in realtà python non scive il vero numero ma un arrotondamento, però non capisco, se scrive un float a 32 bit mica si inventa altri bit...provo a metter tutto a 0 perchè anche in binario (0101010) lo zero si rappresenta con 0
--------------------------------------------
Che bello, non serve ad un cavolo....

in 10 anni non ho mai visto niente del genere, magari chissà che cazzata che sarà. Mi arrendo. prova su qualche forum.

La cosa è alquanto imbarazzante,Willdog ha trovato l'errore, era così stupito che manco ci avevo dato un'occhiata:
Ho messo 'w' invece di 'wb' e adesso va perfettamente

---

def txt2bin() :
...
fileoutput = open(shortname + '_modified.dat', 'wb')

---

la doc lo diceva pure:

Python on Windows makes a distinction between text and binary files; the end-of-line characters in text files are automatically altered slightly when data is read or written. This behind-the-scenes modification to file data is fine for ASCII text files, but it’ll corrupt binary data like that in JPEG or EXE files. Be very careful to use binary mode when reading and writing such files.

dove è scritto ?
comunque è un errore così banale che non mi ero accorto...

nella documentazione ufficiale

docs.python.org/tutorial/inputoutput.html

era l'ultima cosa che avrei pensato potesse causare l'errore, ero convinto di non poter aver sbagliato in quel punto dato che è uguale al linguaggio C...
Comunque io lo messo nella discussione corrisposndente, se qualcuno troverà dei bug li correggerò immediatamente.
Adesso proverò a fare anche qualche test con i file .modeltraversablenetwork utilizzati solo per le torri d'assedio mentre per gli altri sono vuoti, praticamente servono a descrivere le zone calpesabili come scale, pianerottoli ecc... chissà, forse servirà a qualcuno.

Comunque adesso si può già creare i file per le nostre armi d'assedio e dare i giusti punti degli addetti, dovrebbe risolvere quel crash che mi dicevi tu a proposito della catapulta.
Nel descr_engine.txt ci sarebbero queste cose da correggere:
engine_radius 4.5
engine_visual_radius 6.5
engine_length 9
engine_width 5
engine_height 5.3
engine_mass 15
engine_dock_dist 5
engine_mob_dist 10.5

specialmente length width e height, mi sembra che se troppo grandi creano conflitto con i punti degli addetti alle armi, dovrebbe essere quell'effetto di spostamento degli addetti che a volte vedi quando caricano, sembra che scivolino all'esterno a volte.