Reply to Re: i need a skeleton map
If you don't have an account, just leave the password field blank.
Seems I was confused with an older WinDinkEdit. It could open any .dat file (and it saw data, so it displayed red squares). The newest one automatically opens the map.dat, and gives an error when it doesn't exist.
DE with map.dat: here
DE without map.dat: here.
As you see, in both cases the minimap rendered correctly, and the now visible maps were red squares: No map.dat still gives red squares, because it gets that information from the dink.dat.
I also tried to run dinkedit on a read-only map.dat and dink.dat:
None read-only: DE behaves normally. (the so-called null-test)
Only map.dat read-only: Didn't crash when creating minimap; didn't crash when opening a screen; crashed when closing a screen; crashed when trying to create a new screen.
Only dink.dat read-only: Didn't crash when creating minimap; didn't crash when opening a screen; didn't crash when closing a screen; crashed when trying to create a new screen.
Both read-only: Didn't crash when creating minimap; didn't crash when opening a screen; crashed when closing a screen; crashed when trying to create a new screen.
What the conclusion is? I don't know. If the program did crash when creating a minimap; it isn't the writability of either the map.dat or the dink.dat. I leave the case to other professionals.
To answer your earlier question "But then how can DinkEdit read the MAP.DAT when it opened the DINK.DAT?" in this case:
I think DinkEdit reads the dink.dat, and for each map square it detect, it reads map.dat for additional information (Like looking up words in a dictionary).
WinDinkEdit reads the information in the map.dat and uses dink.dat to determine where it should belong (Like when you sort things).
I'd really like it when Dink only used one map file instead of map.dat, dink.dat. Not to speak of hard.dat, which might be included into it as well.
DE with map.dat: here
DE without map.dat: here.
As you see, in both cases the minimap rendered correctly, and the now visible maps were red squares: No map.dat still gives red squares, because it gets that information from the dink.dat.
I also tried to run dinkedit on a read-only map.dat and dink.dat:
None read-only: DE behaves normally. (the so-called null-test)
Only map.dat read-only: Didn't crash when creating minimap; didn't crash when opening a screen; crashed when closing a screen; crashed when trying to create a new screen.
Only dink.dat read-only: Didn't crash when creating minimap; didn't crash when opening a screen; didn't crash when closing a screen; crashed when trying to create a new screen.
Both read-only: Didn't crash when creating minimap; didn't crash when opening a screen; crashed when closing a screen; crashed when trying to create a new screen.
What the conclusion is? I don't know. If the program did crash when creating a minimap; it isn't the writability of either the map.dat or the dink.dat. I leave the case to other professionals.
To answer your earlier question "But then how can DinkEdit read the MAP.DAT when it opened the DINK.DAT?" in this case:
I think DinkEdit reads the dink.dat, and for each map square it detect, it reads map.dat for additional information (Like looking up words in a dictionary).
WinDinkEdit reads the information in the map.dat and uses dink.dat to determine where it should belong (Like when you sort things).
I'd really like it when Dink only used one map file instead of map.dat, dink.dat. Not to speak of hard.dat, which might be included into it as well.
