Grazza

Try both software rendering and OpenGL. Unless your system is very old, one of them at least should work OK. And be sure to use the latest version of Prboom+ (2.5.0.8 or the 2.5.0.9 test version). Another thing that used to help was to set the screen resolution to be the same as your desktop, though that may not be an issue any more. Anyway, try it both ways, and if it's no good, then post about it in the prboom+ thread, describing the problem and posting your cfg file.

Sure, I know what you're referring to. But that was more a case of personal animosity involving a few players, and the grievance wasn't so much polishing (i.e. taking a second or two off a time that is thought to be fairly close to optimal), but rather uploading demos that took a little time off records that were very far (i.e. minutes) from optimal, and the feeling was that this was just being done to collect compet-n points. But that's a long long time ago, and let's leave it in the past. I just wanted to clarify what is meant by polishing in this context. The kind of polishing Radek was talking about was, say, taking Doom2 map03 Max down from 1:20 to 1:19. I agree completely about giving route credits in text-files, and said something along those lines in this thread:

Everyone who records has their own goals and interests, but there are, I think, two fairly clear paths that players find most natural.One is to be primarily interested in finding new ideas, routes and tricks (including new approaches to battles), or achieving previously undone tasks. The other is to be concerned with improving the technique of running, finding ways to run existing routes faster, including tweaking the way particular battles are handled.Most players are to some extent interested in both areas, but most display at least some bias towards one or the other. I would say that both approaches are equally important and necessary for our field of endeavour to advance and remain fresh. A fantastic new route idea only leads to a truly fantastic demo when it has been polished and refined by a good runner. Ever higher standards of running show what can be accomplished and that people needn't be satisfied with 'lazy' demos. If there are no new ideas, then the tasks get reduced to a purely technical matter, with a few tics getting shaved off - you can see this with some of the shorter compet-n records, where the best route was worked out, and new runs dried up in the early 2000s, with a comment in a txt along the lines of "taking a second off this would just be a question of even better luck with infighting". Sorry for rambling a bit. But my point is that a demo that adeptly implements an existing route or idea is of great value, and appreciated by the people who contributed route ideas, big or small. It's essentially a culmination of the efforts of everyone who has been involved in the process. I recall Radek (at the pub during the Prague LAN) saying something about this, and feeling that his effort was largely polishing the ideas of others. But even if that is largely true, then we have as a result so many fine works of art (by him and others that his demos have encouraged) that he can truly be regarded as a creator. I'd disagree completely with the notion that the activity in this forum is overly competitive in any negative connotation of the word. If I thought so, I wouldn't want to be a moderator of the forum at all, in fact. To my mind, there would be a problem if there was a "pwning" attitude and crowing over beating the times of others. Or if people's primary motivation to record was simply to beat the times of others. But I don't detect that at all (other than some slightly rough-sounding comments that can, I feel, be put down to language issues and/or misunderstandings). As for comparing demos - sure they can be compared when the same game physics apply and nothing has been used that gives the player vastly more info than another. But comparing players is another matter, and again I don't recall anyone seriously claiming that beating someone else's time proves that one player is somehow "better" than another. We respect other players for what they have created - for the pleasure it has given us, and how it has enriched our own playing and recording experience.

Not just that, but they tend not to be the "easy" east-to-west variety, but (like the one in your demo) west-to-east or north/south. I'm certainly interested to hear your thoughts on what is going on with these glides (in particular the "drift" to the side when attempting the "difficult" directions), and possible methods for making them work more reliably. Even random unscientific musings based on experience may give someone the germ of an idea that unravels a little more of the mystery.

Split off, so discuss to your hearts' content, competitively or otherwise. :)

Evilution (TNT.WAD) map13 features a very easy void glide (it should be obvious from a glance at the map where it is), but also useless from the point of view of exiting as far as I can tell, as there is no viable path through the void.

Map12 UV Speed/Pacifist in 0:19 Easy run; anyone who feels like will be able to improve the time. BTW, I used the naming convention hl instead of ht, which conflicts with the standard naming for Hell Revealed Tyson demos. Although, with Extended Format, it doesn't matter too much either way. BTW, map13 should make for a fairly interesting violent UV Speed thanks to two tricks. You only need the yellow and blue keys (and to press the blue and yellow switches), and you can get the yellow key at the start using a thing-wobble-glide off a former human in the start room (you can also get it without that, by accurate running). You'd need to glide through the gap where the three bars block your way (not having pressed the red key switch), and there would need to be some monster-fighting along the way. But it could be a nice-looking demo for someone willing to put some work into it. Edit: the route would also feature a further glide near the exit - it's an obvious one and not difficult. (So obvious that I forgot even to mention it at first!) Edit2: Oops, the reason I didn't mention the "third glide" is that it is on the next map! Something got scrambled there! hl12p019.zip

Aliens TC

Firestorm. Never leave home without it.

No, the opposite. It doesn't display them in cases where they would occur in vanilla. If you only test a wad that is intended to be strictly vanilla compatible in prboom+ with -complevel 2, then you won't detect certain type of visual glitches, or problems (such as crashes) due to exceeding certain limits. There are also some types of wad errors that it fixes on the fly, to avoid a crash. But it does emulate the in-game behaviour precisely in other respects. Info on the raised limits in Doom+ can be found here. Note that this should not be confused with "Doom 1.91", which modified the exe to use longtics for recording and playback. That was a separate project entirely. The two hacks can be used together though. To clarify: Doom+ maintains demo full compatibility with vanilla (unless the relevant limits are exceeded), whereas Doom 1.91 has no demo compatibility with vanilla.

You can choose software rendering in glboom-plus.exe.

They all play back OK without needing to add -solo-net to the command-line, so you had successfully enabled this feature before recording.

I'll just insert a [fairly obvious?] comment here: you don't need to play the demo to the end to check this. If you start the demo playing and quit immediately, this info will be in the stdout.txt. You don't even need to have loaded the correct wads - you can exploit this to determine the format of an unknown demo in a few seconds.

The convention you have used looks good to me. I don't think it conflicts with anything.

That got my attention... I notice that the Scythe2 (2nd Release) table doesn't appear to include demos recorded on the first version even when they play back perfectly OK with the new version (such as my own Map26 UV Pacifist in 0:17 and DomRem's Map09 UV Speed in 0:14, and presumably some others that are yet to be improved upon). It would seem logical to include in the table those that play back with the second version - otherwise it gives the impression that they don't work any more, and people might get wrong information about what has been achieved previously. I'm not sure exactly how many maps have extensive enough changes to cause desyncs of demos recorded on the first release. From the Scythe 2-2 text-file, you'd think "most" or "all", but that doesn't appear to be so. I guess Andy has it set up so that any particular demo can only appear in one table. If so, I'd suggest making the first release table specifically for those demos that need the older version to play back, and moving all others to the table for the second release. Though I'd understand if that seems too much work - consider it just a request. Edit: I did just a tiny bit of testing, with the shortest demo on each map, and the ones on the following play back OK with the new version: 1, 3, 7, 8, 9, 11, 12, 15s, 16, 26, 31, 31s (That's not to say that all demos on those maps will be OK, or that no demos on other maps will work.)

FYI, Nevan, your demo is Boom format. The wad doesn't use or require Boom features.

He is not granting any permission to use anything from his wad. And if permission is not specifically granted, then it is withheld. That's how copyright works. Of course, if he didn't make certain stuff, then he cannot restrict the use of that stuff by anyone else. That's not to say that it is free to use - that depends on whatever permissions were granted by whoever made it.

Just in case the original poster is unaware, Commander Keen was an earlier game series made by id. So it is rather consistent to have a Commander Keen element if you have already decided to have Wolfenstein 3D themes.

Two maps of that type that spring to mind, with traps and puzzles, are Strain map21 and Eye of the Beholder map03. Both have at least one monster, though they aren't the main challenge. I'm not sure it's a great idea, though the occasional map of that type can be a refreshing change from the normal. Though those who like the idea of playing without fighting probably prefer Pacifist-style.

Bishop: if what you mean is that your map will require a Boom-compatible port, then that makes things a lot easier: you can put the voodoo doll on a conveyor belt and arrange things so it crosses an exit linedef just after you have killed the player. To test if it works in prboom+, use -complevel 9 to emulate Boom behaviour. But if it is intended as a vanilla-compatible map, but you still want to ensure it works in Zdoom and are worried about crushing a barrel, then you can have the player telefrag the barrel. That will surely work. Maybe it would simplify things if you stated exactly which exe(s) your map is intended to work with.

Wow, a classic question. It says "On your marks!", and anyone who thinks otherwise is simply wrong. http://www.doomworld.com/vb/everything-else/13169-the-mancubus/ http://www.doomworld.com/vb/post-hell/19890-what-does-mancubus-say-when-he-shoots/ http://www.doomworld.com/vb/doomworld-news/13170-dwbs/ http://forums.newdoom.com/archive/index.php/t-32996.html

There are some pitfalls here. Almost any situation with a voodoo doll being damaged holds the risk of zombification - if the player has low health, for instance. So you'd want the voodoo doll to pick up as much health as it loses while exiting. Also, the player's armour transfers to the voodoo doll - type IDFA in 4mer's map, and you won't exit. And what if the player is invulnerable? These things can be tweaked to make it more foolproof, but unless you have very tight control over the player's state (e.g. force him to pick up a megasphere just before exiting), there are things that can go wrong. I'd suggest putting the voodoo doll very close to the exit line and pushing it over it with just the tiniest blast. I'm surprised by what you said about teleporting the player into a voodoo doll in that sector type. The effect that should have is that the player starts the next map at 1% health. Was there anything funny going on? (Two voodoo dolls telefragged? Were you using a port that changes this behaviour?) Anyway, this isn't a solution, but I am puzzled by what you say. BTW, you can use a Romero head in a Doom1 level. See this thread. Or you can use dehacked to give the relevant code pointer to something else. Some more discussion on this topic here. MBF introduced a compat option that prevented dead players from exiting (bad idea). Prboom still has this as its default option. Prboom-plus (recommended) doesn't, but this all depends on the settings chosen. If you want emulation of vanilla behaviour, you need to use a complevel (3 for Ultimate Doom). Perhaps simplest solution: teleport the player into a voodoo doll (in a normal sector) and a barrel, whose explosion propels another voodoo doll over an exit line. The player is thoroughly dead, meaning no chance of a zombie outcome.

Try running from the command line, without any launcher. Other people haven't had this problem, and the most obvious thing you are doing different is using the CDL launcher, so that is the first thing to consider. (From what N_A says just above, it doesn't appear to be a fundamental problem with the launcher, but maybe there is something in the settings you are using.) And don't delete the corrupted demos you have recorded. From what N_A says, it is just a matter of editing them with a Hex editor, and they'll work OK. Done. Please repost your unrelated demo in the misc demos thread. (Yeah, I could have duplicated the post by splitting it into its own thread, copying and remerging into both threads, but it's a messy process.)

When you play back a demo, you need to load the same wads (iwads and pwads) that were used when recording it. There are various ways to achieve this. You can turn on extended format when recording, so that the wad info is recorded in with the demo. Alternatively, you can use standard naming so that the demo name is recognized by autoloading (which you need to have turned on). If the wad is not one that is included in the autoloading patterns, you can add it yourself, if you know what you are doing. Or you can load the wads via the built-in launcher, if you have it enabled. And finally, you can load them the old-fashioned way, via the command line. To specify an iwad, you need to use, e.g., -iwad doom.wad Obviously all the wads need to be somewhere that they program will find them. That would be in the same wad as the exe, the current directory, or the $doomwaddir$. BTW, I strongly recommend not using a new directory each new version. It's messy and error-prone. Just overwrite the old version of prboom-plus exes with the new one, but keep your old cfgs.

Jim Flynn's STAT.EXE does more or less what you describe. I recall it has some issues with multiplayer stuff (don't recall what exactly - whether it counted them even for SP stats, maybe), but you'll be taking the results with a large pinch of salt in any case, naturally. There are other tools along those lines too; I recall Yonatan Donner created one, whose name I forget. Edit: Doom Things Analyzer. more info