More Lumpy Goodness

[sirjuddington]

Well I've finally gotten the next version of Lumpy to a relatively workable state. I went back to VB because VC likes to make it really hard to do simple Dialog-based applications. So yeah, the new Tree view idea is implemented and works fairly well. I'm not sure I like it much, but others might

I'll add the option to use a normal list view for the next version maybe. Oh and the import folder function won't work at the moment either.

Anyway here's the main changes:

- Changed lump list to tree, for easy organisation of lumps
- Rewrote gfx preview, should be much faster and bugfree
- New lump, LUMPINFO, is written to the wad to tell Lumpy what lumps are of what type
- Numerous other minor changes/fixes

I'm not completely sure it's bugfree at the moment, so yeah, test away (I'm just glad to get it out finally)...

[randomlag]

New lump, LUMPINFO, is written to the wad to tell Lumpy what lumps are of what type

Not sure what that means. I hope you don't mean it literally writes a new lump to the PWAD? That might be a sure way to make many people avoid using it.

FYI: You can figure out 99% of the lump types just by inspecting their headers and doing a little bit of extra checking. IOW, no need for this.

[GameArena]

I went back to VB because VC likes to make it really hard to do simple Dialog-based applications.

You can always use MFC with VC++, I haven't tried VB but MFC is really easy when it comes to dialog based applications.

[sirjuddington]

I was using MFC

And yeah, it does write a new lump to the PWAD, but I don't see how that is so bad, since it's not exactly a huge lump or anything (just a short integer for each lump, should probably change it to a byte, since there is hardly gonna be any more than 255 types...)

[Chris]

One of the things I hated most about Deutex/Wintex was that it put in a lump when you saved the WAD. It's a very bad idea IMO, especially if some port decides to use the LUMPINFO name for its own purposes(at least Wintex used a fairly obscure name but still, writing a lump without the user's consent = bad).

[sirjuddington]

Heh, well I'll add an option to not write the lumpinfo lump then, as well as an option to remove the lump if it exists. Without it people will just have to use the 'detect type by lump name' option. The reason I used this method rather than automatically detecting from names/lump content is because any type of file can be imported as any lump type, and so sometimes it could have trouble detecting types.

[Lumpy]

Lumpy version 8!
I guess I'm old and obsolete.

[Bio Hazard]

i think lumpinfo is a great thing!and if it sticks then no port will use it because lumpy already does right?

[wildweasel]

You can always use MFC with VC++, I haven't tried VB but MFC is really easy when it comes to dialog based applications.

And if he goes MIA, then we'll all be put on KP...

[SargeBaldy]

Almost missed this thread, because you decided to post it on Thanksgiving :P Anyway, things are definitely coming along :)

[Biff]

Almost missed this thread, because you decided to post it on Thanksgiving Anyway, things are definitely coming along

Ahh, I love it when someone spells "definitely" correctly!

[cccp_leha]

I definatly agree with you, Biff.

[Enjay]

And I deaf in eight leigh agree with you Leha

[Zell]

And I deaf in eight leigh agree with you Leha

uhhhhhh.....
ummm....
ooh ok I get it now XD

BTW, great tool slayer

[Cyb]

heh, wintex not only shoves a lump called _DEUTEX_ in there when it merges wads (which I believe is used for restoring merged wads to their prior state) but it also wastes like 18 (or so) bytes in the header flagging each wad with the name of the app and the author name and all sorts of crap that nobody ever ever sees. Granted it's a small amount of space in the wad, but that sort of thing annoys me, especially since wintex is a sub-par lump tool as a whole