Maes

And that's why, ladies and gentlemen, launchers were invented.

WTF, can't hack being a 1337 fux0r h4xx0r c0mp3t1t1v3 sp33drunn3r?! Shame on you.

I only recently found out that you can get tutti-frutti floor flats. Granted, this was in ZDaemon, playing SF 2013, MAP08 (sorry no screenie ATM), but in theory nothing prevents getting them in vanilla too. Only that I never actually saw them in even the shittiest 1994 PWAD.

Until the battery craps out on you, effectively turning it into a desktop :-)

The BFG edition.

UV pacifist has been a recognized COMPET-N category for years, and no enforcing mods were ever needed, other than the competitors' own drive. What I proposed is essentially a twist/variant on Pacifist (no monsters allowed to die/least monsters to die wins).

I think TVTropes can explain it better than me :-p

Exactly. Part of the challenge would be to move in such a way to avoid alerting monsters and/or minimizing the chance of infighting. Now, I realize that getting "0% kills" may be next to impossible(!) on some levels even if the player actively does nothing...so in that case the "challenge" could be relaxed to "Finish a level as quickly as possible AND with the least number of kills possible". This would encompass typical Pacifist style tactics and strategies, but could also be open to some variants, e.g. allowing the player to kill some monsters selectively, if that would result in less overall casualties.

There's already the Pacifist style of play that does that. There, you're not allowed to kill any monsters directly (by weapons). I'm not sure how traps such as crushers are handled...maybe you're not allowed to use them if they are player-controlled or something. Infighting is fair game. However, even more interesting would be a "Pro-Life" subcategory of Pacifist, where you must complete a level without ANY monster dying, no matter the cause. Think that's trivial?

Here's an old post I made on the subject.

The implementation from my side at least was kind of hacking: there was an interface ISyncLogger: public interface ISyncLogger { public void debugStart() throws IOException; public void debugEnd(); public void sync(String format, Object ... args); } which was however implemented by the "God-like" DoomStatus object: ///// SPECIAL DEMO TOOLING STUFF, INSPIRED BY kb1 ///// protected PrintWriter syncdebugfile; public final boolean DEBUG=true; public void debugStart() throws IOException { // [kb] open the sync debug file // [Maes] does it really have to be in append mode? syncdebugfile = new PrintWriter(new BufferedWriter(new FileWriter( "syncdbg.txt", false))); syncdebugfile.printf("*** Debugging started ***\n"); } public void debugEnd() { // [kb] be sure to close the file proper on program shutdown syncdebugfile.printf("*** Debugging stopped ***\n"); syncdebugfile.close(); } // [Maes] call this to dispatch arbitrary reports public void sync(String format, Object ... args){ if (sync_debug) syncdebugfile.printf(format, args); } private final boolean sync_debug=true; , and was passed as an ISyncLogger object to specific objects, e.g. the RNG. Thus, modified calls to P_Random were used that looked like this (notice the SLY object, which is actually now a field of the P_Random class): /** [Maes] I'd rather dispatch the call here, than making IRandom aware of * DoomStatus. Replace RND.P_Random calls with DM.P_Random(callerid) etc. * * Fixme: this could be made into a proper enum * * @param caller */ public int P_Random(int caller) { int value = P_Random(); SLY.sync("PR #%d [%d]=%d\n",caller,prndindex,value); return value; } public int P_Random(String message) { int value = P_Random(); SLY.sync("PR %s [%d]=%d\n", message, prndindex, value); return value; } public int P_Random(think_t caller, int sequence) { int value = P_Random(); SLY.sync("PR #%d %s_%d [%d]=%d\n", caller.ordinal(),caller,sequence, prndindex, value); return value; } public int P_Random(think_t caller, mobjtype_t type,int sequence) { int value = P_Random(); SLY.sync("PR #%d %s_%d %s [%d]=%d\n", caller.ordinal(),caller,sequence, type, prndindex, value); return value; } The various "flavours" of P_Random logged different amounts of information. Needless to say, the formatting and amount of info was more or less synced with what kb1 did on the other side. Needless to say, lots of room for improvement here...you can see all this for yourself at the "DemoTooling" branch on the old MochaDoom CVS.

Interesting, so now you output much more stuff (though we did get down to some pretty gory details too), in a much more structured manner (one of the main problems we had was that comparison relied on text output being exactly identical down to the last whitespace character, so that diff-like tools could be used, but a structured approach that can be parsed even without strict line-by-line equality would be way more flexible). In Java, this sort of "marking" variables and functions to be output could be done quite cleanly with annotations, instead of the traditional way of just "stuffing" the code with output directives. Of course, if one's feeling too lazy to port/engineer the system from the ground up, using JNA to a precompiled DLL of SyncDBG is always a possibility ;-)

Only by proxy, apparently. One of the reasons that debugging in this manner reached its limits is because the reference port itself (KBDoom, though we didn't really call it that) was not 100% accurate at the time.

We had developed a complex text output-based system that logged Information at certain critical points, such as all calls to P_Random, and compared per-tic outputs. This system requires a "donor" port to be used as a reference, and the logging must be implemented on both sides. It also required quite a bit of back and forth, so I wouldn't really recommend it for "debugging by proxy" as we did. I think remnants of this system exist in the "demosync" branch in the old repo. Surprisingly, the system worked well enough to allow us to narrow down desyncs to specific function calls and fix at discrepancies on my side. I even emulated an overflow at some point, which didn't work on kb1's port ;-) It would be awesome if all ports had such a logger built-in, or at least conditionally buildable.