Interactive boomref.txt

[fraggle]

Hey, so a few weeks ago I made this site which has an "interactive" version of the Boom editing guide (boomref.txt). This was the text file that was included with Boom and which explains all of the enhanced editing features that Boom supports (and by implication, all Boom-compatible source ports).

The general idea is to try to liven up the original text file in a way that makes it more accessible and less dry. So it includes:

• Numerous cross-references with a video of BOOMEDIT.WAD, one of the example WADs also included with Boom. The video also links back to the doc. So if you're reading about a feature you can see a video of it in action, and if you're watching the video you can click through to read about how it works.
  
  
• Pop-up calculators for calculating Boom generalized linedef types. Boom originally shipped with a DOS calculator program that would do the same thing, but it was kind of primitive and not very friendly. I guess most editors already have this built in nowadays, but in case you're using an old editor that doesn't support it then you might find it useful.
  
  
• There are a few screenshots in there too.
  
  
• All sections are hyperlinkable so if you want to link to a particular section of the doc you can just copy the link. There are also cross-references between sections and links to pages on the Doom Wiki.
  

I also did the same thing for mbfedit.txt.

This is probably all kind of pointless but I figure there might be a few people out there who find it useful or interesting. If you're interested in contributing, the code is all on GitHub.

[VGA]

Awesome! Love that pop up video!

[scifista42]

Good! It really could use a table of contents at the top, though. (linking to the respective parts of the document)

[axdoomer]

Thanks for doing this. This is going to be very useful.

[Linguica]

Interesting, but I really wish it had 1) a hyperlinked table of contents at the start and 2) a different typeface. Monospaced is unpleasant for reading extended lengths of text.

[fraggle]

scifista42 said:

Good! It really could use a table of contents at the top, though. (linking to the respective parts of the document)

Added, thanks for the suggestion.

Linguica said:

2) a different typeface. Monospaced is unpleasant for reading extended lengths of text.

Maybe you're right. I kept it in the monospace font to stay true to the original text file. There are a number of tables and ASCII art diagrams in the original doc.

EDIT: I switched it over to a proportional font. You can still change it back to monospace via some CSS magic if you want to be "authentic".

[kb1]

Wow! These are very good. Great job!

[jmickle66666666]

I still found that times new roman kinda hard to read, I just made a quick css with a much softer color palette, using Helvetica as the font. Personally this makes it a lot easier to read through http://pastebin.com/KcdxrG80

[fraggle]

Thanks. I considered using a Sans Serif font; however, a significant portion of the doc is in monospace format, and the standard monospace fonts are usually serifed. So I chose a Serif font to get a consistent look.

[Gez]

How about those?

[fabian]

The "Hack" font is good, I use it in my terminals:

http://sourcefoundry.org/hack/

[Jaxxoon R]

Whoa dude, this is really cool.

[kb1]

A very small bug report:
In the generalized calculators, if you use the keyboard instead of the mouse to change a dropdown's value, the calculation does not occur. I think you need an "OnChange" event handler to fix this, in addition to the "OnClick" event handler, which works. (I haven't looked at the code).

For example, open the Generalized Doors Calculator. Use the mouse to click inside the Trigger dropdown (which gives it focus). Then use your down arrow on the keyboard. At least in FireFox, the dropdown's value changes, but the code stays the same. But, use the mouse, and all is well.

With that said, I must reiterate: This is a very nice resource! Personally, I'd like to see port-specific additions to it: Legacy, Eternity, ZDoom, etc. But, I know it would be difficult to keep the page as clean as what you've accomplished here. Maybe the other port devs could use our pages as models for their own docs.

[fraggle]

kb1 said:

A very small bug report:
In the generalized calculators, if you use the keyboard instead of the mouse to change a dropdown's value, the calculation does not occur. I think you need an "OnChange" event handler to fix this, in addition to the "OnClick" event handler, which works. (I haven't looked at the code).

For example, open the Generalized Doors Calculator. Use the mouse to click inside the Trigger dropdown (which gives it focus). Then use your down arrow on the keyboard. At least in FireFox, the dropdown's value changes, but the code stays the same. But, use the mouse, and all is well.

Weird - it works for me, and I'm already using onchange rather than onclick for this. I just tried and it seems to work fine with the keyboard. I tried both Chrome and Firefox.

[VGA]

For me, when I use the keyboard up/down arrow to change a drop down value, it only updates the hex value after I press TAB to move focus to another control. Latest stable FF.

[kb1]

VGA said:

For me, when I use the keyboard up/down arrow to change a drop down value, it only updates the hex value after I press TAB to move focus to another control. Latest stable FF.

Yes, this is how it works for me as well.

@fraggle: I said 'try OnChange', but I'm pretty sure I got it backwards. Try both OnChange and OnClick, and I think it'll be fixed.

It's not that this is a normal usage case, but it does allow the screen to show an incorrect value at times. I tried it this way, simply cause I wanted to see how the value changed, based on the dropdown, to know which bits were being changed. In other words, it was a pure programmer/nerd moment, which would not normally occur for anyone else :)

EDIT: It happens for all dropdowns, but not checkboxes - they work immediately via spacebar. It's very cool how you made it look like an application window! I want to steal your code for some of my silly web apps!

[fraggle]

I figured it out - it's because of how HTML change events work - they are generated:

• When the user commits the change explicitly (e.g. by selecting a value from a select's dropdown with a mouse click, by selecting a date from a date picker for input type="date", by selecting a file in the file picker for input type="file", etc.);
  
  
• When the element loses focus after its value was changed, but not commited (e.g. after editing the value of textarea or input type="text").
  

In this case the change event is not generated because the new value has not been "committed" yet (by switching to another control).

I wasn't seeing the issue because I'm on a Mac and using the arrow keys on OS X pops up the dropdown list rather than cycling through values like it does on Windows or Linux.

There's a potential workaround using onkeydown.