Slade messing up the root lumps in my pk3

[Knas]

I have this problem there Slade v311 is messing up the root lumps in my pk3. It's like it's trying to create map markers from an regular wad or something. When I save and load the top lumps gets messed up like in the pic, and the lumps bellow gets filled with some other kind of data. For each time I save and load random lumps gets messed up
and I don't know why.
The pk3 is created empty in Slade and was then filled with the stuff from my wad. Help please.

http://imgur.com/VIQvwAv

[Kappes Buur]

Maybe your Slade3.pk3 got mangled somehow.
Open slade_3110.7z in 7zip and just extract Slade3.pk3 into the folder where you installed SLADE v3.1.1.

[Gez]

The support data shouldn't have any influence on how zips are saved. It looks like it's botching up the association between entries and their content.

[sirjuddington]

Are you sure you aren't modifying the pk3 outside of SLADE while it's still open in SLADE? I just tried doing this and ended up with something similar to what you are getting.

[Knas]

This is pure speculation but from testing some more it seems to happen when I click the save icon. The program freezes for a few seconds and when I load it, it's messed up in a random way. However, if I use save as, the corruption have yet to happen.

Edit: No, it can still happen when using save as, just it's way less likely. I'm now afraid I will lose my work if this will continue to happen.

Are you sure you aren't modifying the pk3 outside of SLADE while it's still open in SLADE? I just tried doing this and ended up with something similar to what you are getting.

Very sure. I've made that mistake before but it has never corrupted the wad like this, unless there is something else that's causing it. Wouldn't know what though.

[Gez]

There have been similar reports before.

The whole ZipArchive class needs to be rewritten anyway if we want to be able to support protocols other than 0 and 8.

[sirjuddington]

Gez said:

There have been similar reports before.

The whole ZipArchive class needs to be rewritten anyway if we want to be able to support protocols other than 0 and 8.

Yeah, I actually managed to get stuff working using libarchive a while ago, the main problem being it doesn't seem to support writing pre-compressed data like the wx zip stuff does, so each time you save a zip it has to recompress everything. I think with LZMA/7z this is required anyway, but yeah it can be very annoying if you save a large archive often. The other problem with libarchive is that it is a massive pain to build in Windows with 7z support enabled (which is typical of these linux-centric libs)

Perhaps I'll revisit it and use the libarchive stuff for everything except the currently supported zip stuff.

FYI I have changed how zip saving works for 3.1.1.1, which might solve this issue. I might also add some kind of option to force re-compression of everything when saving a zip, just in case it isn't fixed.

For now, it might be an idea to not use a pk3 but use a directory instead.

[Graf Zahl]

sirjuddington said:

Yeah, I actually managed to get stuff working using libarchive

Ugh... Just looking at that thing makes me think 'What were they thinking?'
I'd say the problem is not that this is Unix/Linux-centric but that it's a mess.


Once I was facing the same task - I didn't bother with such bloated crap, I just used the archive management from ZDoom and ZDoom's zipdir, which had everything I needed.

[sirjuddington]

Graf Zahl said:

Once I was facing the same task - I didn't bother with such bloated crap, I just used the archive management from ZDoom and ZDoom's zipdir, which had everything I needed.

Hmm, does that stuff handle writing/compressing as well?

[Gez]

sirjuddington said:

Hmm, does that stuff handle writing/compressing as well?

Yes, it's used to generate zdoom.pk3.