Boom-LMPC 2.0

[Opulent]

A new version of Boom-LMPC.

Limited usefulness, but that describes me as well.

http://www.mediafire.com/download/f6jmwxvwg26kuqx/boom-lmpc_20.zip
http://www.mediafire.com/download/f6jmwxvwg26kuqx/boom-lmpc_20.zip


My other released PrBoom-plus-assisted DOOM demo programs:
Single-player demo analyzer -- http://doomedsda.us/index.html
Deathmatch demo analyzer -- http://doomedsda.us/index.html
Multiple Deaths(FDA contest) demo parser -- http://www.mediafire.com/download/u2lr65kh56zf724/deaths-prboomplus2513-opulent-version2.zip

[Never_Again]

Duly noted, thank you, Ops.

I've been playing with the new version today and am impressed with the stdout.txt of the custom prb+ exec. Had some problems with the program itself, as well as with trying to automate the new "-i" feature with a batch file. In particular, neither of the following works:

boom-lmpc -i < boomlmpc_inputvalues.txt
type boomlmpc_inputvalues.txt | boom-lmpc -i

All I get is "Wrong number of arguments for -i parameter". Weird. Simple type displays the required numbers, shouldn't there be a way to pipe the file's contents into boom-lmpc as an argument?

Doing everything step-by-step the way the readme describes works fine. OTOH, I can't get "-l 1" and "-d x" to produce any meaningful results anymore.

Suggestion: to avoid confusion cut down "-l 1" to simply "-l", as per internal help list. The readme needs to be adjusted accordingly, currently it freely alternates between the two.

Could be it's just PEBKAC, I'll have another look at it tomorrow.

[Opulent]

Well, the person who codes a program shouldn't be the only one who tests it.

In Windows, it is painful to parse a logfile and sort the various values into a non-CR/LF appended string. That is, removing the /r and /n newline characters is more work than it should be and can cause a re-direct to fail.

boom-lmpc -i 214 418 5 104 2304 17 383 > output.log <-- this is the right syntax.
boom-lmpc -i214 418 5 104 2304 17 383 > output.log <-- this is wrong(obviously).
If there are "hidden" /r or /n characters in the 214 418 5 104 2304 17 383" string, boom-lmpc will only see the arguments before the /n or /r characters. (this is why it will work if you just type it in instead of re-directing the output.)

In both WindowsXP and Windows7, I was able to just cut and paste the boomlmp_inputvalues.txt contents into another pre-made boom-lmpc -i (c and p your stuff here) > output.log batchfile.

You can always write your own script to parse the stdout.txt to get the correct values if all else fails. (if you have cygwin or similar you can use the parse-stdout linux script which wouldn't have the issues the stupid Windows one does.)

-d and -l not working. Well, you win some, you lose some. You just have to shift them over farther... I think. boom-lmpc -l 1 -d 3 instead of -l 1 -d 2. Or force the header to a certain size with -f.(for example -f 14 instead of -f 13 for cndoom demos). If all else fails, you can use boom-lmpc1.0 for these actions.

-l incorrectly documented. I'm sure you're right. I only have so much time to write a tool that two or three people might use a couple of times.

I hope you tried the -q option... as you might find that the most useful(especially when paired against the stdout.txt).

I'm interested in seeing what a real software developer could do with this task...