Reorganize lump browsing

[jmickle66666666]

Currently just looking at a list of all the lumps in order is Not Cool, so I need to think of a new way of organising them.

Omgifol sorts lumps into separate categories; graphics, audio, data, and maps into groups of lumps. This is pretty ergonomic and will probably be the basis of my system.

I would like to revamp the way maps work too, possibly with integration from MAPINFO if present, letting the user edit data in a completely new and more intuitive way.

This also brings into question the possibility of some kind of metadata lump. who knows.

[Deleted user]

I've added a prototype, but there's some things to keep in mind. I replaced the logic where you were calculating the lump index with this:

 90                 $('#lumpUL li.item').on('click', function (e) {
 91                         $('#preview').html('');
 92                         $('#preview').show();
 93 
 94                         var li = $(this);
 95                         var i = li.attr("class").split(' ')[2];
 96 
 97                         lumptype = li.attr("class").split(' ')[1];

Important things:

• Replaced delegate with on and made the target li.item. Accordingly removed the logic to find the li that had the item class
• Added the index and lumptype as classes to the element itself, also removing the need to calculate the lump index. This is fairly important because they are no longer in order after I started grouping them
• The dropdown menu is a component of Bootstrap. Once you click on something the dropdown menu disappears. This can be configured to change until a more standalone dropdown implementation is created

[jmickle66666666]

I think the new lump menu should be a separate element to the lump list, so we can keep the lump list itself intact and shown separately.

While your solution for grouping the lumps by datatype is idiomatic for the library, I think a more user-friendly approach would be more 'curated' lists. I would create new UI elements like the preview panels for the sections of the grouped areas.

This would include for instance:

• Maps section: Opens an interface that lists all the maps present in the wad, and has an area to show the map preview image when one is selected, along with a section that lists any data that can be parsed from various MAPINFO lumps (when parsing those is added), and the assumed music file associated with the map.
• Textures section: This would mostly be based on Slade's Texture1/2 editor, having both a list of textures and patches, with a preview window and other data associated with the selected texture. This requires TextureX and PNAMES lump parsing to be completed. A much simpler section can be created for flats.
• Sprites section: List of all the unique sprites in the game, grouping according to the standard format for enemy sprites in Doom. The list would just include e.g ['POSS','SARG','PLAY',etc.] and selecting them would list all the frames associated with the sprite. Later on with DECORATE parsing this can be expanded into a more sophisticated animation previewer.

Of course, these are more in-depth interfaces that require some more work to implement, but would result in a clearer, easier to use system for users. Keeping the lump list and improving on it separately would be essential too, since most users are comfortable with them as a primary method for exploring wads. It would also be used as a fallback for anything not implemented in this Interface approach.

[Deleted user]

Agreed, however, the current API for getting lumps is not very maintenance friendly. The adding the information as class names I mentioned above is a bit of a hack to replace the indexing method you used. I think the way lumps are organized and referenced needs to be improved before work on the interface can be done.

For right now it is trivial to assign the elements to their respective areas like I did for the dropdowns. When you need information on a lump just grab the index li.attr("class").split(' ')[2]. A separate issue should be created for creating an improved data structure/API to manage lumps.

[jmickle66666666]

Could you expand on what you mean by improving the way lumps are organised and referenced? I'd love to hear some ideas on improvements here.

[Deleted user]

After working on your project for some time this is how I've come to understand it (although please correct me if I'm wrong):

• The lumps are stored in the order they are referenced
• Accessing them by index is this.lumps[index]
• The old interface accessed the lumps by counting the amount of previous siblings. The invariant here is that the lumps must be sorted

My patch moves the list elements out of order so that counting method no longer works. My workaround is to add the index to the element itself, that is you can think of it as a unique identifier. However, this is is pretty hacky code.

Rather than have the lumps as an array, maybe it can be implemented as a dictionary or hashtable. I'm not entirely sure.

[jmickle66666666]

Oh so you mean in the ui. Yeah, when I was implementing the lump list, the quickest solution for me at the time was to count previous elements to get the index of the lump. It was one of the biggest symptoms of the tool originally just being used to test wad.js, and only more recently being intended to be developed into a proper tool.

Using index as a unique identifier I think is fine personally, since lump order is very important in the wad file. We'd just need to be careful with the position of new lumps and how we reorder them when editing capabilities get added.

[Deleted user]

By the way I just now realized you did the music for the Adventures of Square. Awesome soundtrack.

Anyways I figured it was the case that order was important in a WAD. I don't actually have any prior experience with WAD formats and assumed that there was some metadata (like an index table) to tie the lumps together, although having a strict order in the WAD file makes perfect sense for an old game. In that case the API doesn't actually need to be change because there really isn't much that can be done.

I'm guessing this would be the approach of organizing music/mapdata with maps:

1. Read map. Next 10 lumps are mapdata for that map.
2. Music is just D_ + mapname. Can use getLumpByName.

[jmickle66666666]

The mapdata.js API can help get the lumps specific for the selected map, and this will be necessary when Hexen and UDMF map formats are supported, as they have different lumps than the Doom format maps.

Most of the music was done by Jimmy, I just wrote some extra tracks and did PR stuff for them haha, thanks though!