Exult Forum

I went to do some map-editing on my game just now, and I noticed that almost every chunk is displayed as the textured-blue null chunk instead of the chunk it should be when browsing through u7chunks. The only ones that don't seem to be affected are the ones that I've used in my map thus far.

If I drag one of the changed chunks to the map, it still shows-up as the null chunk, not as the original. When I look at my groups of chunks, I see the same thing: only those I've used on the map appear to be normal.

I'm using a copy of the u7chunks file from SI for my game for now, so my original is unharmed, but I've made a number of custom chunks already, so if it's possible to not lose what I've done so far, I'd greately appreciate it! Email me at the address above if you want to look at my u7chunks file.


-Karl

Could you zip it up and submit it with a bug report on our sourceforge site?

I'm not sure I completely understand the problem. If you look at 'u7chunks' in ExultStudio, are they all missing? Or is it just on the map?

I'll do that. The map is fine, but when I look at u7chunks in Studio, I see the same number of chunks that were there before, but all of them appear as the null chunk, except for the ones that I have already used on the map, which appear normal (and are in the correct positions).

I just zipped-up u7chunks, and it compressed from about 1.5 megs to about 3K. This would seems to indicate that all of the missing chunks really did get changed into the null chunk rather than ebing displayed incorrectly in Studio, since the extreme compression suggests lots of repeated info to me.

Okay, I submitted a bug report with the zipped file attached:

https://sourceforge.net/tracker/index.p ... tid=102335

Assuming that the other chunks are really gone, is there any way to export my custom chunks (which were not corrupted) to a new file, or will I have to recreate them?


-Karl

So you still have a 'u7chunks' file that has your chunks, but not the others? Fortunately, u7chunks is a 'flat' file, where each chunk is 512 bytes. So if one of your chunks is chunk #1, it will be bytes 512-1023, and you could use a utility like the Unix 'split' to break the file into 512-byte pieces to get at yours.

BTW: Any idea when the file got corrupted? It's a bug that would be nice to fix.

(Also, you should probably backup your 'patch' directory fairly often.)

I have no idea when/how it happened; wish I did. As I said in the bug report though, I haven't done any map-editing work for a week or two, and when I was about to do some yesterday, I noticed the problem. What probably happened is that whatever I did last with the chunks caused the problem, but it wasn't visible until the next time I looked at u7chunks in Studio because the display of chunks did not automatically refresh itself after the problem happened.

In case it helps, here's what I was doing last time I did map editing:

I wanted to create city wall chunks that were surrounded by grass on both sides of the wall (no city street), so I found a plain grass chunk made a copy of it, and moved the copy all the way to the bottom of the displayed chunks via the Move button. I then made a copy of this chunk and dragged it on the map, and created a custom chunk from it. I did this several more times until I had enough of these to form a complete city wall. There were also a couple of misc. chunks I created as I needed them. I kept all of these at the bottom of the file so I could tell which ones were my own vs the standard SI chunks.

I'll try to pay better attention next time, but it may be difficult to nail down since there may be several operations in a single editing session.


-Karl

In case anyone else would find this useful. here's a TCL script to extract a group of chunks from a chunk file:


#! /bin/sh
# -*- tcl -*- \
exec tclsh $0 $* >/dev/null

proc get_chunk { chunk_file chunk_num } \
{
set offset [ expr $chunk_num * 512 ]
seek $chunk_file $offset start
set outfile [ open ${chunk_num}.cnk w ]
fconfigure $outfile -translation binary
set chunk_data [ read $chunk_file 512 ]
puts -nonewline $outfile $chunk_data
close $outfile
}

if { [ llength $argv ] < 2 } \
{
puts "usage: getchunk chunkfile index1 [index2 ...]"
exit 1
}

set chunk_filename [ lindex $argv 0 ]
set chunks [ lreplace $argv 0 0 ]
set chunk_file [ open $chunk_filename ]
fconfigure $chunk_file -translation binary

foreach arg $chunks \
{
get_chunk $chunk_file $arg
}

No doubt now that I've posted this someone conversant in Perl will post a 1-line Perl script that does exactly the same thing, but contains nothing but punctuation characters. Seems to always happen when I do something in TCL.


-Karl

My chunks file got corrupted again, but fortunately this time I had a backup. For now, I'll just make a backup after every chunk I edit.

All I did this time was edit a single chunk, and when I tried to do a "save all" from Studio, Exult crashed, and when I brought Exult and Studio back up, the chunks file appeared the same way as I stated in my initial bug report.

Based on this, I now know the problem is unrelated to copying or moving chunks, since I did neither of these; I just tried to edit a specific chunk.

I'll add this info to my bug report.


-Karl

Btw, where does this particular chunk come from, anyway? I quickly browsed through the original SI u7chunks file, and couldn't find it anywhere. The real null chunk is plain blue, not textured blue like this one. Here's a small shot of the chunk in case it gives a clue as to where this is coming from:




-Karl

No idea where the blue chunk is from. But now we can guess that the corruption occurs during the save-all, probably from Exult crashing. Perhaps when it happened the first time, you were exiting, so didn't notice the crash?

What I can do is run Exult in gdb, edit chunks, and hope for a crash when I save so that the problem can be looked at.

Actually, the last time this happened, Exult DID crash when I did a "save all", but I figured this was a symptom of the corruption, not the cause. Sorry I didn't mention that before.


-Karl

Found it. Fixed now. Doesn't seem to have to do with crashing (I guess that's another bug:-(), but occurred if you edited a chunk and saved when you hadn't created or moved chunks. The fix was just checked in.

Thank goodness! I thought this one might be hard to nail down. Now I can get back to annoying all of you with various Usecode-related questions.


-Karl