Csabo

Members
  • Content count

    556
  • Joined

  • Last visited

3 Followers

About Csabo

  • Rank
    Member
  1. 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 :-)
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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.
  7. Thanks, fixed it in the latest beta.
  8. 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.
  9. 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.
  10. 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".
  11. 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?
  12. 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.
  13. 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.
  14. I so have to do something about this one :-)
  15. The same problem would never come up. The "fix" in this case was to delete that test code permanently.