Csabo

Hi guys, It seems I lost my password/connection settings to the doomworld.com/xwe page, so I'll just post a note here. I promised here http://www.doomworld.com/vb/xwe/34191-source-code/#post570481 that I'd release the XWE source code once I decide to stop maintaining it. It's available for download at the usual place here: http://ca.geocities.com/xwe@rogers.com/. This wasn't really a "decision", more like a realization - I don't have time for it anymore. Nevertheless, someone may find something useful in there. I'd be happy to see new and/or bugfixed versions of it. It's written in Delphi 5 (I know, ancient). One quick note: if PNGImage/CodeMax/Zip handlers give you trouble, you're probably better off commenting out anything that deals with those parts. I don't think those are essential to WAD editing, and could be replaced with other libraries. Finally, big thanks to Martin Howe, the only person who ever sent me a donation. It was appreciated :-)

I see your point. This change is probably a necessary one, I think if I can nail it, XWE will be a much more solid app. I think what it should do is, when a WAD is opened, copy it to a temp file (e.g. add ".XWE" to the filename), and work on that. If Save is selected, the original is renamed to a backup name and the temp file is renamed to the original name. I'll have to think about it a bit more, and I'll try to add this soon.

I'm not quite sure about your first request. Why would you think Doombuilder is the only tool that has extension-based shell integration? You mean if you right-click a WAD file, there's a command that's associated with it? XWE had that since the beginning. (Has it really been 6 1/2 years? But that's besides the point.) It doesn't set the "Edit with XWE" command as the default (which would probably be a bit intrusive). Originally, XWE defaulted to associating itself with every extension it could handle, but quite a few users complained about this behavior. Now it's optional. I personally have a ton of commands associated with WAD files (the default one launches it in ZDooM), I was under the assumption that most doomers do the same. Anyway, if you could clarify what you're looking for maybe I can add it. The second suggestion is a good one, I added this (grab the latest beta). If the last opened WAD was gone, XWE didn't behave very nicely. Now it doesn't complain, just displays that it could not open the file in the status bar.

Upload the WAD file somewhere so I (or someone else who's good at WAD editing and has time) can take a look at it.

I added a new option which is turned on by default: "Automatically create a backup file when a WAD file is opened". It basically performs a "clean-up" when you open a WAD (which leaves the original file as a backup). Pro: with this option enabled, I'm confident that there will be no data loss of any kind using XWE. Cons: 1) it will create more files, which take up disk space (those can be deleted). 2) If you open very large files, this may take a while (so you can consider turning this off).

I'm sorry you ran into this problem. It may sound weird, but this behavior is by design. Here's what happens: You open a WAD and delete some lumps. There is no BAK file at this point! It's a final change written straight to the WAD. Give it a try and check it - no BAK file. (Note: there is an undo file however, in the temp folder, so at this point, your delete is easily undoable.) When you close XWE, there's an option which is turned on by default called "Perform Clean Up on exit". The Clean Up function rewrites whole WAD file to reclaim wasted space. Wasted space is produced for a lot of operations, this is normal for most WAD editing programs (it's not feasible to keep rewriting the whole WAD all the time - especially for very large files). Before clean up occurs, a BAK is created. But that BAK - as you pointed out - already has your files deleted (again, as you pointed out - deleted from the lump list, but not from the actual file). Then the new cleaned up file is written. Technically it's possible to recreate those lumps, but it's manual work, hacking around with HEX editors. If I recall correctly, DeepSea had some tools for this, you could look into that if getting the lost data is vital.

Thanks, fixed it in the latest beta.

Xaechireon: the warning that was added is specifically for the situation you mention, that is, opening the WAD file with another editor while it's open in XWE. I think I may have explained the details before but here it is again. Assume you have a WAD with two lumps. Lump A is at position 1000 and lump B is at position 2000 within the file. XWE reads this info once, when the file is opened. Now you modify the WAD with another program, let's say you make lump A bigger, so now lump B starts from 2500. If you now modify lump B in XWE, that lump will be saved back to 2000, overwriting and corrupting lump A. People used to complain about lumps and WADs being corrupted in XWE. This is just a safeguard that this doesn't happen. It's just a simple message... You can even ignore it if you want to. It really shouldn't be popping up all the time. If it does, try to re-create the steps you've taken. Perhaps I missed something, but I'd need to be able to see what.

If it functions just fine then it's probably not screwed at all. What could be happening is XWE mis-recognizing the lump as an image. If you could upload that WAD somewhere and give me the link, or email it to me, I'll take a look, this may be something that's very easy to correct.

XWE doesn't really copy the selected entries to the Windows clipboard. It has it's own clipboard. The main reason for it is to have the ability of adding multiple entries, e.g. you can select one or more entries, click COPY, then select some other entries, click COPY again, and the first batch will not be lost. Until recently (1.16+) XWE did not even have the capability of running multiple instances. The undo feature would mess up if you tried that. That is now working, you can safely run multiple instances. However I don't have a good solution for copying between instances yet. I guess the existing way of copy/pasting is still a good "workaround".

Sorry, I'm not clear on what you mean by any lump/entry/object. You can do that with copy/paste. Select any number of lumps (use CTRL+click and/or SHIFT+click to select multiple entries, just like in an explorer window), then copy. Open the destination WAD, then paste. Is this not what you are looking for?

You mean the X_### ones? Those are 64x128 floors, specific to Hexen. I added support for those in the latest beta, grab it and give it a try.

Hi Rex, Sorry for the delay. XWE cannot do what you're looking for yet. I understand your request perfectly, but this functionality is a bit weird... When PNGs are imported, the whole approach is "import as Raw". But if we're going to auto align them, then it's not just raw data anymore, the PNG will actually be modified. I've been thinking about this for a while, but haven't figured all the details yet. I'll try to add it as soon as I can.

I so have to do something about this one :-)

The same problem would never come up. The "fix" in this case was to delete that test code permanently.

First of all thanks for the above, now that is a nice reproducible step by step list. Otherwise ouch times a million. I dread even saying this, but I guess I gotta own up to it, so here comes the full disclosure. There was a piece of test code left in the global keypress handler, which straight up corrupted the WAD when X was pressed. So it happened if you quick searched for the TEXTURE# lump, or if you just pressed X from a whole lot of places. (But it wasn't the quick search itself, like I said, that doesn't modify anything.) I'm really sorry if you guys lost valuable work over this stupid bug. Fixed in the latest beta of course. I'm certain that piece of code was the only one of its kind. There still might be other minor issues here or there, but hopefully nothing fatal.

Any chance of step-by-step reproducible instructions from either one of you guys? I looked at it last time, but couldn't see anything wrong. I'll look at this tonight regardless.

I could not reproduce this, cut/paste immediately modifies the WAD and the lump directory. If you have the time, please make a copy of your WAD, open it up with the latest, and cut/paste it. However, I did find a related bug, which might be the cause of all the warning messages: after cut, XWE modifies the WAD file, but I forgot to put in the call to get the updated file date. (Since at this point we DO know that the file is modified.) So for ANY operation after the CUT you would get the warning. This is now fixed, grab the latest from the usual place.

Good point, I guess FMod would be an option. But as far as I know it still won't support everything though, such as IMF files (weird midi like music entries from old Apogee games). I did get requests for playing those as well. Winamp does play those through a plugin. So the consensus is that you guys would rather have "built in" support for OGG etc, rather than the generic solution? I looked at FMod very briefly, but could not get the Delphi examples to work (died with "the procedure entry point FMUSIC_GetRow could not be located in the dynamic link library fmod.dll"). If I could manage getting this to work and it integrated nicely (e.g. the dll still wouldn't be required), I wouldn't be against it.

Sorry guys, I was very busy last week, and still I'm still currently very busy. I was surprised to see a locked thread (the first one in our humble little forum I think). Anyway, the issue is playing music and sound files that cannot be played by the built in media player. This includes MP3, OGG, S3M, IT, XM, etc. Not sure how common each of those are, but I do remember seeing them in various WADs. To actually implement players for these formats is definitely outside of the scope of XWE. It would be very complex and time consuming, and it would be re-inventing the wheel. However, I would like to add support for these through "external editors". This particular issue (i.e. external editors) came up lots of times already, and it is definitely on the to-do list: what XWE needs is for the user to be able to assign an executable to different lump types. I think XMPlay plays all of the above, or I'm sure you guys have your own preferred players for these. XWE would extract the given lump to a temporary location and launch the given program. This will also allow the user to edit images in PhotoShop or some other graphics editor. I'll work on it when I have time. I really think this is the proper solution for the issue. Thanks for bringing it up, now I know it's a priority.

The quickfind box just locates the first matching lump and sets the focus to it. It definitely does not modify the WAD in any way. However, when a lump is clicked on (or selected through the quickfind), that's the first time XWE checks for the file modified date. So chances are, the file is already modified at that point. To better prove this (and to further help file corruption), maybe I should add a timer that would perform this check every one second or so in the background. I tried to do all of the stuff you described but could not get the file modified warning to come up. I did find a few smaller bugs though that gave I/O Error 6. (That means invalid file handle btw, the most common cause is trying to work on a file that's not open.) For example, if you closed a WAD in XWE, you could still double-click the filter buttons, and it tried to import stuff. I fixed these and uploaded the latest beta. For the last issue you described: in this case too, it really looks like the file was actually modified. XWE right now just gives you a warning and lets you continue, but maybe it shouldn't. You see, what happens is this: XWE reads the WAD file. The WAD file has a directory that specifies where the lumps are within the file. Let's say your DECORATE lump is at file position $1000. At some point XWE detects that the modified date of this WAD is newer than it should be, so it gives the warning. In the "new" file, DECORATE could be at $2000, or anywhere else. So when you clicked OK twice, and saw empty lumps, that's why it happened: XWE still looked for your lump at $1000, but the file was modified and now something else (or nothing) was at that position. So thanks for your continued feedback, I really hope we can nail this. For now just grab the new one and see if you get it again. For everyone else: could you guys please try to reproduce the file-gets-corrupted-on-quickfind-if-textures-lump-is-open issue? It doesn't happen to me, regardless of what I search for, or if I modify the textures lump or not.

I know it's a bit weird that it does that. But the event is triggered just the same as if the user clicked on that lump. I guess it would be possible to avoid this with some flags, but it would be such an ugly hack. Just don't put sounds as the first lump :-)

Yes, this was a bug that prevented XWE from displaying those two lumps correctly. (They got mis-identified as another graphics format.) I fixed it in the latest beta, grab it from the usual place. Thanks for pointing it out!

1) is fixed in the latest beta. I can't believe no-one has noticed this before. Thanks for pointing it out! 2) can be turned off under Options|Entry List|Auto play sounds. If auto play sounds is on (which is the default), what you said is expected behavior. As for export, I'd rather keep the existing dialog, I prefer that one.

This was a very easy fix, grab the last beta. Doom images don't have any header, it's just a bunch of bytes. Because XWE supports so many different formats, it's trying to be really careful in determining what's a valid Doom image. That particular one was right on the boundary of how many bytes a DGF lump can be for the given dimensions. Anyway, thanks for pointing it out.