Suggestions for XWE

1. Could XWE be modified to allow music in different formats to be previewed from within the program? Currently when I select Music and Play, I get an error message that says 'Could not play song - probably not MIDI format'. Yet, in-game the music plays fine. (Medium importance)
2. Automatic overwriting of existing files can sometimes be a problem. A File/Save As feature would eliminate this problem. (For example, I copied some entries from one file to another, and realized later that I didn't want them. Too late, as they had already been permanently written to the file.) An Undo feature could have helped, but it's not a true solution to a File/Save As feature. Also, I realize that I could delete the modified file and renamed the .bak file to recover the original file. But this would not bring back any changes that I intended to keep. (High importance)
3. I could not find a Snap To Grid option. When moving sectors, XWE appears to reposition them based on where in the sector the mouse was clicked. This often leads to the sector being moved off the grid. If the Snap to Grid option is there please let me know how to access it. If not, consider this a feature request. (I realize that a sector can be re-positioned by first selecting it then positioning the cursor near a linedef, and moving the sector to the desired location (which then uses a snap-to-grid function for the nearest vertex on the linedef selected. But this is not obvious.) (Medium importance)
4. A texture browser would be nice, particularly for those new to editing. For experienced mappers, the list of names is probably adequate. (Low to medium importance)
5. In the menu of texture names, it would be nice to be able to double-click a name and have it be inserted into the appropriate sidedef that is selected. Currently, the user must start typing the texture name, after which XWE prompts with the full name corresponding to the letters typed. This is certainly adequate, but the double-click method adds a little convenience. (Low importance)

Also, some time ago I opened up one wad, selected all its entries, selected Copy, opened up another wad, but could not select Paste as it was not enabled. I tried to replicate the problem, but it seems to work just fine now. I wonder if there is an issue with number of entries, although I just managed to copy and paste more than a hundred entries totalling 8 MB without any problem. More likely, I probably just goofed the first time.

Why does it turn flats 90 degrees (I think XWE flips them as well) when you add them to your wad? I realised this when I made a set of 6 interconnecting flats made up of grass and gravel. It ended up being quite the mess. I wish this would be fixed.

Doom Dude said:

Why does it turn flats 90 degrees (I think XWE flips them as well) when you add them to your wad?

I believe this is a function of DooM/2, rather than something that an editor does. IOW, I'm not sure that an editor could actually fix this problem. (Yes, it can be quite annoying.)

1. XWE uses the Windows Media Player to play music lumps. That can only play MIDIs. The .MUS is a doom specific format, so it plays in the game, but the media player can't play it. I could do what WinTEX does, which is temporarily convert the .MUS to .MID with the MUS2MID utility, and then play the resulting MID. I'll see what I can do... ;-)

2. You mean a File|Save As... which saves the whole WAD into a new file? That can be added easily.

3. This is tricky. Actually right now XWE always snaps to grid, you have no choice. At least it takes the current grid size into consideration. When you drag a sector, it takes the position of the click, snaps that to the grid, and you drag from there. I have to see what WadAuthor chooses as the dragging point.

4. This one is already in, but I'm having problems with it. On WinXP it runs fine, but on Win98 it crashes before I'm able to reach the end of the list... XWE tries to cache the textures, because it loads the sooo slowly. Damn WadAuthor and it's lightning fast C++ code, I wish I could be that fast in Delphi.

So I'm thinking I have to take the texture caching out, but then it's going to be a little slow (on older machines).

5. Okay, but to which texture? Above, Main, Below on front or back? The layout of the properties box for the linedefs came from Espi. However, in his design he had little buttons with arrows on them next to each of the 6 texture boxes. I guess what he was thinking was once you select a texture from the list, you click those buttons to copy the selected texture name to the appropriate box. Maybe I should add those?

Csabo said:

2. You mean a File|Save As... which saves the whole WAD into a new file? That can be added easily.

Yes, but I think it's just as important to disable automatically over-writing an existing wad. If the File|Save As will prevent the automatic over-writing, then that'll work.

3. Actually right now XWE always snaps to grid, you have no choice. At least it takes the current grid size into consideration. When you drag a sector, it takes the position of the click, snaps that to the grid, and you drag from there.

The problem occurs in dragging from there. Invariably, a square sector is re-positioned off the grid (unless the user does what I said in terms of positioning the cursor near a linedef as a reference). Bringing it back to the grid is very tricky unless, again, a linedef is used as the reference. It's not that things don't work; it's just that it's not intuitive. That's why I figured it only rated a medium importance.

4. XWE tries to cache the textures, because it loads the sooo slowly.

If not a texture browser, then perhaps at least an image of a selected texture. (Perhaps this would also essentially require caching the textures?) Alternatively, to load each texture faster when called up could you reduce the image size and/or resolution? I'm just grasping at straws here.

5. Okay, but to which texture? Above, Main, Below on front or back? The layout of the properties box for the linedefs came from Espi. However, in his design he had little buttons with arrows on them next to each of the 6 texture boxes. I guess what he was thinking was once you select a texture from the list, you click those buttons to copy the selected texture name to the appropriate box. Maybe I should add those?

For some reason I assumed that if the user clicked on the appropriate box, that was the selected field. That's why I was surprised when double clicking a texture name did nothing. The button thing would work too. Again, I consider this to have low importance from my standpoint.

ReX said:

I believe this is a function of DooM/2, rather than something that an editor does. IOW, I'm not sure that an editor could actually fix this problem. (Yes, it can be quite annoying.)

It's a function of what an editor does. IOW, it's fixable:)

Csabo said:

I wish I could be that fast in Delphi.

Since you brought it up:) It's insanely slow even in map scrolling, zooming and texture conversion. Even slower than P-code basic (see DoomCad for comparison). I'm amazed that Delphi/Pascal is so slow.

deep said:

It's a function of what an editor does. IOW, it's fixable:)

Cool. I did not know that.

Another suggestion for XWE would be better lump editing. For example if you open a wad and select the Decorate lump you can edit it right inside XWE but if you open say MapInfo as soon as you view something else it does not save your changes. Very annoying.

Cyrez: You are absolutely right. On the MAPINFO (and other text lumps) change event I forgot to set the modified flag. Fixed.

Rex:
For some reason I assumed that if the user clicked on the appropriate box, that was the selected field.

I like that idea. When you click on a box, it's 'selected' because the keyboard focus is there, but once you click on the list, the focus is gone. However, XWE can internally keep track of the last clicked box (I will even highlight it), and that's will be the list double-click destination.

Also, could you give me an example of the automatic file overwrite you mentioned? I'm not sure what you mean.

Deep:
I'm amazed that Delphi/Pascal is so slow.

It's not really Delphi's fault, but mine. You can even compile ASM straight into Delphi, so if you know what you are doing, you can make things as fast as an in C++. But I didn't optimize things yet, and I'm just not good enough. I'm not too worried about the conversions being slow, but the map refresh is definitely slow if you have too many things on the screen. (BTW, I already managed to cut the speed of loading and display textures in half, but I'm sure it could still be much faster.)

Csabo said:

Also, could you give me an example of the automatic file overwrite you mentioned? I'm not sure what you mean.

Say I have a map that has been saved to a wad file. I open the wad and insert a lump. When I close the file (or exit XWE) the file is automatically overwritten with the new information. IOW, without the File|Save As option (or a prompt to save the file before exiting), XWE is overwriting the file as a default. If I want to recover the version of the file before it was over-written I can either rename the .bak file (the drawbacks of which I have already mentioned) or re-open the file and manually remove the changes. This is not a big deal if we're talking about one or two lumps. But if there are wholesale additions or removals of lumps this can be somewhat troublesome. Particularly, if I deleted one or more lumps that I want to restore.

Of course with lumps I could delete any unnecessary ones that I had added, then close the file. (This assumes that I would realize that I don't want those lumps before I quit the file or XWE.) That would prevent the creation of an unwanted version of the wad. But I would still prefer to have the option of writing to a completely new file.

When editing the map itself, there is a prompt to save any changes, and this is very useful. The same type of prompt when exiting a file or XWE would be great. This would also prevent undesired over-writes if the file or XWE are closed accidentally.

Let me know if I haven't satisfactorily explained what I mean.

It's a function of what an editor does. IOW, it's fixable:)

Why is it a function of what an editor does to take a flat and turn it 90 degrees? Also does Wintex do the same thing because I was told that it doesn't but I never used Wintex enough to find out.

Okay, grab this test.wad. I created a flat with an arrow pointing up in Photoshop. Loaded the image into XWE between FF_START and FF_END. Saved the image as Doom Flat. Made a map where the floor is using the flat.

Now, when you look at the flat itself, the arrow is pointing upwards (which I think of as north). When you run the game, the arrow on the flat on the floor is also pointing to the north.

So what's the problem?

ReX: Okay, now I see what you mean. You do know that there's Undo though? If you deleted some lumps, just Undo it. I guess that still doesn't help if you close the file by mistake. Okay, I will probably make this change.

Csabo said:

You do know that there's Undo though?

I was using an older version of XWE, which doesn't have Undo. I downloaded this version from your site on Feb 21, 2003, but I believe it's the same as the old version. (Please check your download links, as the DooM Heaven one is pointing to the old version. I'm currently in the queue for the new version (v1.11) from 3DDownloads. EDIT: I just got the file, and I'll give it a shot when I have a moment.)

You are mistaken, the Doom Heaven file was updated the same time the 3D Downloads was. It's V1.11. Big thanks to Alastair Montgomery once again for this! The Undo actually has been in XWE since 2001 april... It's for any and all entry operations (deleting, merging, adding, replacing entries, etc).

Okay I downloaded your test wad and made a arrow flat myself and it turned 90 degrees. Then I clued in and checked my version of XWE and it was an older version. I downloaded the lastest off Doom Heaven and everything is fine now. Sorry about that. Guess I missed the update last Feb.

Csabo said:

You are mistaken, the Doom Heaven file was updated the same time the 3D Downloads was. It's V1.11.

You're quite correct. (I just downloaded the file from there, and it's fine.) The reason for the confusion is that I went into DooM Heaven's utils folder, and saw that the XWE file was dated June 6, 2002. The date on my latest XWE.zip was Feb 23, 2003 (which must be when I last downloaded it, and probably from somewhere else), but the latest files in that zip are dated June 6, 2002. Therefore I assumed that the DooM Heaven file is outdated. Sorry for the confusion.

Btw, how did you bring the .exe file size down from more than 1MB to less than 0.5 MB?

Here's some of my suggestions

1. Apogee Music to MIDI converter to be done (or maybe Apogee Music to MUS? I have seen a utility that converts MUS to Apogee Music files, maybe try that)

2. Support for sound extraction from Wolf3D games to WAV format.

Howabout mus to midi without distortion. (Ie drums play drums, not guitars)

MUS music format....

According to WinAmp, MUS is just a subformat of MIDI.

For example, I can use say NWT to extract say d_runnin in RAW format, save it as d_runnin.mus. Double click on d_runnin.mus and WinAmp loads and plays it just fine. If not, open WinAmp, select Preferences/Setup/File Types and select MUS. Unfortunately though, Windows Media Player doesn't recognise MUS format :(

Still, I'd much rather use WinAmp than say MUSplay.