Legacy GM Buffer saving in wrong language. (Solved but no explanation)

M

Misty

Guest
I can no longer save or open buffers properly.
When I try to save a string, it puts the characters in Japanese.


And when I try to open it, it says "Cannot load buffer file."

Solved by restarting my pc.
 
Last edited:
P

Paolo Mazzon

Guest
What are the contents of this file? (Preferably a screenshot of a hex editor.) Maybe even the code that creates this file?
 
M

Misty

Guest
My code is just the basic buffer creation code. It was working fine yesterday.
buff=buffer_create(1024,buffer_grow,2)
buffer_write_string(buff,buffer_string,"headeru")
buffer_write_real(buff,buffer_u16...)
//inserting buffer_tells does not help
Here is a screenshot
upload_2016-7-14_22-2-59.png

Here is the text from the corrupt buffer in notepad: 敨摡牥u Ϩ@ɓʣɵʁȩȵȏȲɍȢɌȰȽɁȉȖǷǁdžǁƘşŬŤ¦Ú½¾ÎÒáĢķʠˍʺʷʺʖɢɎɓɺʕʠɺȱɕɈȦǐǠǦNjſƖĺ·¥ìÝĀÝĄĐġ̘ͷ̮̿ʿʖɝɡʥʘˆˬ˟ɱʒɪțɋǘȄǩƳŰůÇɾĘéïőĸğιЏξά̮ͨˀ丠 Ƙϖﮅٽ ￿▓▓刈Ϩſȓクڀ✐✐￿⬫⬫丠ϨNjЂﲋپ ✐￿⍳⍳刈 şư獵ٻ ￿ⳮⳮ嗰 Ŭᅨﳒٻ✐ ￿ⱚⱚ嗰ϨƖʯﲱڀ✐✐￿ㅁㅁ刈 şư獵ٻ ￿ⳮⳮ嗰ϨƖʯﲱڀ✐✐￿ㅁㅁ刈Ϩſȓクڀ ✐￿⬫⬫嗰 Ŭᅨﳒٻ ￿ⱚⱚ姘 Ť޳ﯯٷ✐ ￿☸☸姘Ϩĺ࢟ﷅٷ✐✐￿⯐⯐嗰 Ŭᅨﳒٻ ￿ⱚⱚ姘Ϩĺ࢟ﷅٷ✐✐￿⯐⯐嗰ϨƖʯﲱڀ ✐￿ㅁㅁ姘 Ť޳ﯯٷ ￿☸☸巀 ¦Քﯲٳ✐ ￿⃏⃏巀Ϩ·׌9ټ✐✐￿✯✯姘 Ť޳ﯯٷ ￿☸☸巀Ϩ·׌9ټ✐✐￿✯✯姘Ϩĺ࢟ﷅٷ ✐￿⯐⯐巀 ¦Քﯲٳ ￿⃏⃏憨 Ú4゙ځ✐ ￿ᲈᲈ憨Ϩ¥ﷱĚځ✐✐￿⎮⎮巀 ¦Քﯲٳ ￿⃏⃏憨Ϩ¥ﷱĚځ✐✐￿⎮⎮巀Ϩ·׌9ټ ✐￿✯✯憨 Ú4゙ځ ￿ᲈᲈ斐 ½Ġﺌڂ✐ ￿ᣤᣤ斐Ϩì﷍ᅩٿ✐✐￿ἕἕ憨 Ú4゙ځ ￿ᲈᲈ斐Ϩì﷍ᅩٿ✐✐￿ἕἕ憨Ϩ¥ﷱĚځ ✐￿⎮⎮斐 ½Ġﺌڂ ￿ᣤᣤ楸 ¾yʧٻ✐ ￿ᑨᑨ楸ϨÝ_0ځ✐✐￿ᮟᮟ斐 ½Ġﺌڂ ￿ᣤᣤ楸ϨÝ_0ځ✐✐￿ᮟᮟ斐Ϩì﷍ᅩٿ ✐￿ἕἕ楸 ¾yʧٻ ￿ᑨᑨ浠 ÎY(ڂ✐ ￿ቑቑ浠ϨĀ︕ڂ✐✐￿᨝᨝楸 ¾yʧٻ ￿ᑨᑨ浠ϨĀ︕ڂ✐✐￿᨝᨝楸ϨÝ_0ځ ✐￿ᮟᮟ浠 ÎY(ڂ ￿ቑቑ煈 Òĥټ✐ ￿፧፧煈ϨÝᅲ﬐ٿ✐✐￿᫤᫤浠 ÎY(ڂ ￿ቑቑ煈ϨÝᅲ﬐ٿ✐✐￿᫤᫤浠ϨĀ︕ڂ ✐￿᨝᨝煈 Òĥټ ￿፧፧田 áﳚΖپ✐ ￿᜻᜻田ϨĄ︃︃ځ✐✐￿᷅᷅煈 Òĥټ ￿፧፧田ϨĄ︃︃ځ✐✐￿᷅᷅煈ϨÝᅲ﬐ٿ ✐￿᫤᫤田 áﳚΖپ ￿᜻᜻礘 Ģﲞ£ڀ✐ ￿ᲸᲸ礘ϨĐﻝﺱځ✐✐￿∺∺田 áﳚΖپ ￿᜻᜻礘ϨĐﻝﺱځ✐✐￿∺∺田ϨĄ︃︃ځ ✐￿᷅᷅礘 Ģﲞ£ڀ ￿ᲸᲸ紀 ķﺯマڂ✐ ￿⌚⌚紀Ϩġﺊᆰځ✐✐￿∵∵礘 Ģﲞ£ڀ ￿ᲸᲸ紀Ϩġﺊᆰځ✐✐￿∵∵礘ϨĐﻝﺱځ ✐￿∺∺ Ϩʠ᦯ר ￿൹൹ϨϨˍﻺٺ✐ ￿ႩႩϨߐͷKٴ✐✐￿୲୲ Ϩʠ᦯ר ￿൹൹ϨߐͷKٴ✐✐￿୲୲

Compare this to a healthy buffer from yesterday (example of a healthy buffer): (Notice how the string is actually in english and the same string as I put in game maker yesterday)
2u32u1000u64 S£u)52M"L0=A ÷ÁÆÁ...
%ý€ 'ÿÿéé )÷eú| ÿÿ•'•'ˆ 5" ~' ÿÿa.a.ˆè–ešúx''ÿÿc+c+ )÷eú| ÿÿ•'•'ˆè–ešúx''ÿÿc+c+ èºMâý 'ÿÿ$$ˆ 5"û~ ÿÿa.a.p Ný' ÿÿ<-<-pèbÈ„û}''ÿÿH0H0ˆ 5"û~ ÿÿa.a.pèbÈ„û}''ÿÿH0H0ˆè–ešúx 'ÿÿc+c+p Ný ÿÿ<-<-X 2–ýd ' ÿÿ¦+¦+XèN— ’ù|''ÿÿk3k3p Ný ÿÿ<-<-XèN— ’ù|''ÿÿk3k3pèbÈ„û} 'ÿÿH0H0X 2–ýd  ÿÿ¦+¦+@ M› lïN' ÿÿo+o+@èSHþ¼ý''ÿÿ;3;3X 2–ýd  ÿÿ¦+¦+@èSHþ¼ý''ÿÿ;3;3XèN— ’ù| 'ÿÿk3k3@ M› lïN ÿÿo+o+(# " áí>' ÿÿš,š,(#èzjýÛý€''ÿÿ[3[3@ M› lïN ÿÿo+o+(#èzjýÛý€''ÿÿ[3[3@èSHþ¼ý 'ÿÿ;3;3(# " áí> ÿÿš,š,' Lwÿ¶ð\' ÿÿY-Y-'è•‹þ–ù|''ÿÿ›+›+(# " áí> ÿÿš,š,'è•‹þ–ù|''ÿÿ›+›+(#èzjýÛý€ 'ÿÿ[3[3' Lwÿ¶ð\ ÿÿY-Y-ø* 0” ¢ïI' ÿÿü%ü%ø*è 8ù|''ÿÿâ#â#' Lwÿ¶ð\ ÿÿY-Y-ø*è 8ù|''ÿÿâ#â#'è•‹þ–ù| 'ÿÿ›+›+ø* 0” ¢ïI ÿÿü%ü%à. =VÿÿóU' ÿÿ××à.èzR)ùy''ÿÿ66ø* 0” ¢ïI ÿÿü%ü%à.èzR)ùy''ÿÿ66ø*è 8ù| 'ÿÿâ#â#à
 
I

icuurd12b42

Guest
try saving with buffer_save_ext, from 0 to buffer_tell() (after the last write) you should end up with a smaller size. and why are you still using the 2 padding... as stated in other thread it's useless...

BTW
buffer_f16 A 16bit float. This can be a positive or negative value within the same range as a 16 bit signed integer. (Not currently supported!)

NOT SUPPORTED!!!

Notepad may be confused with the presence of binary values and assume the content is in non ascii so that would explain the japanese characters with it trying to convert those. as you can see in the hex editor your headeru is there.
 
M

Misty

Guest
I used u16s not f16s.

Notepad converted the healthy buffer with the original string, so the fault is not notepad, something is wrong with the buffer and gm can't load it.

I am using the 2 padding because I deleted the buffer_tells because I thought they had glitched it. I was wrong, but didn't feel like adding them back anyway so I just put 2 padding. Also its probably faster without the buffer tells and everything is a u16 or s16 so I dont need buffer tells.

buffer_save_ext still exports corrupted unreadable buffers, but they are smaller size.
 
Last edited:
M

Misty

Guest
The hex editor shows that what you are doing is correct.

It is probably the rest of the uninitialised crap that is confusing notepad into thinking you are writing something in another language.

Reset the whole buffer to zero, rewrite your text, and it should look normal.
Please clarify this. What do you mean by unitialized crap? What do I have to initialize?

And what do you mean by reset the whole buffer to zero and rewrite the text? Please clarify.
 
I

icuurd12b42

Guest
Sorry I read your buffer_write_real() and half the other thing, saw the 16 and the write real and it stuck.

I don't really understand your response about why you need the padding either and that stuff about the buffer tell... that is not needed in any other place than determine how big a chunk to write to file

create buffer, grow, size 0 padding 1
write string
write integer 16
write buffer ext, from 0 size of buffer tell()

All this has been mentioned in your other topic... aside writeing with save_ext
 
I

icuurd12b42

Guest
>Please clarify this. What do you mean by unitialized crap? What do I have to initialize?
writing the extra uninitialised 1024 bytes. if you allocate 1024 and save 20 bytes the rest of the 1004 bytes will have garbage in it.

Just use save_ext as I mentioned

NOTE if you dont save_ext and you content is 1025 in size it will save 2048... then 4096 and so on. that is the way the buffer grows
 
M

Misty

Guest
I have like 64 calls to buffer_write(buffer_real) I dont feel like readding 64 buffer tells for no reason.

PS: I already tried it and it didn't fix it.

PS: You can't create a buffer with size 0.
 
I

icuurd12b42

Guest
I'm sorry but I'm about to have a psychosis... wt heck are you reambling on about the re-adding 64 buffer_tells()

Code:
buff = buffer_create(1,buffer_grow,1);
buffer_write(buff,buffer_string,"headeru");
var i = 0;
repeat(64)
{
buffer_write(buff,buffer_u16,i++);
}
buffer_save_ext(buff,"test.bin",0,buffer_tell(buff));
buffer_delete(buff);
buff = buffer_load("test.bin")
show_debug_message(buffer_read(buff,buffer_string));
repeat(64)
{
show_debug_message(buffer_read(buff,buffer_u16));
}
buffer_delete(buff);
headeru
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
 
M

Misty

Guest
No I have manual custom vertex data and I can't use a repeat loop.
So i have to litterally add 64 buffer_tells.
Completely pointless since I already tried it and got junk buffers like before.
 

Roa

Member
double post, sue me.
I want to make sure you don't miss this.

This works perfectly fine. Idk what the problem is. You should only be using allignments of 2 if your buffers only contain values that can be stored in groups of 2. Your buffers dont because you are using strings. That's the extent of the situation.


create:
Code:
first_list=ds_list_create();
second_list=ds_list_create();
buff=buffer_create(1024,buffer_grow,1);


///save values to buffer and list
buffer_write(buff,buffer_string,"header")
ds_list_add(first_list,"header")
var val=0;
    repeat(64)
    {
    val=irandom(10000);
    buffer_write(buff,buffer_u16,val)
    ds_list_add(first_list,val)
    }
buffer_save(buff,working_directory+"/saved_buffer.buf")
buffer_delete(buff)




//load the values back in and compare.
buff2=buffer_load(working_directory+"/saved_buffer.buf");
buffer_seek(buff2,buffer_seek_start,0)
ds_list_add(second_list, buffer_read(buff2,buffer_string));

repeat(64)
        {
        ds_list_add(second_list, buffer_read(buff2,buffer_u16))
        }
Draw:
Code:
var n=0, val="";
for( n=0; n<ds_list_size(first_list)-1; n+=1)
        {
        val=string(ds_list_find_value(first_list,n));
        draw_text(x,y+(n*20),val )
        }


n=0; val="";
for( n=0; n<ds_list_size(second_list)-1; n+=1)
        {
        val=string(ds_list_find_value(second_list,n));
        draw_text(x+100,y+(n*20),val )
        }
 
Last edited:
M

Misty

Guest
No dude I've tried it every which way.

At first the buffer only had u16s and s16s so I put the alignment of 2. It exported a corrupted buffer, so I thought maybe it needed a string header in it or something. Added a string header and no dice.
Then I set the alignment to 1 and tediously put 64 buffer tells between everything, and still no dice.

I restarted my computer and let's see if that fixes it....
 

Roa

Member
No dude I've tried it every which way.

At first the buffer only had u16s and s16s so I put the alignment of 2. It exported a corrupted buffer, so I thought maybe it needed a string header in it or something. Added a string header and no dice.
Then I set the alignment to 1 and tediously put 64 buffer tells between everything, and still no dice.

I restarted my computer and let's see if that fixes it....
You're missing the point. Set the allignment to one. You can't mix data types in the buffer with the alignmentoptoins, expecially strings. Copy and paste that code I wrote in and watch it work.

And if you trully are only writing u16 and s16(I dont know why you need them both) then you are not setting the seek properly. use buffer_seek
 
H

HammerOn

Guest
The main issue here (like the other thread OP created about buffers) is that Misty is misunderstanding half of the reply and insisting the other half is wrong.
We should fix this first to then get to the buffer problem.
 
Last edited by a moderator:
M

Misty

Guest
You're missing the point. Set the allignment to one. You can't mix data types in the buffer with the alignmentoptoins, expecially strings. Copy and paste that code I wrote in and watch it work.

And if you trully are only writing u16 and s16(I dont know why you need them both) then you are not setting the seek properly. use buffer_seek
Your missing the point that I already said I tried it with no strings attached, just u16s and s16s. Your also missing the point that I mixed data types before, and it worked just fine, yet today, when I don't even mix data types anymore, it still doesn't work.

Buffer seek is for reading buffers correct? I can't do that because it won't even load the buffer in order to read from it it gives me an error.
 
M

Misty

Guest
Didn't try it, just used the same code I had from yesterday and now it works.

My guess is something to do with the memory got bunkered, and by restarting my computer it fixed the problem somehow.
 
Top