I don't see how that changes anything, no game processes things biased on video frames it's just what is used for timing purposes because it's easy to do and consistent. Why should nethack be timed differently then Azure Dreams? http://tasvideos.org/2256S.html
Nethack only updates the video when it's done processing user input. On a modern computer you could actually do one input per video frame; it's not clear to me if this is the case in DOS emulation, though (or even the case for all configurations of DOS emulation, since presumably DOSBox has some features to vary the amount of computing power it exposes). Normally we don't have to deal with variations in processing power, which is part of what makes frames tempting.
However, regardless of how fast your computer is, you cannot possibly input more than one character per frame. Thus, measuring characters gives consistency for this game.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
However, regardless of how fast your computer is, you cannot possibly input more than one character per frame. Thus, measuring characters gives consistency for this game.
You can type faster than one key per frame. The limit for most main block keys is ~750 keys per second (20 cycles of ~15kHz clock) whereas VGA frame rate is far slower than that (limit comes from keyboard clocking emulation).
The typing rate also depends on key. There are keys (mainly arrows and those keys above arrows) that take double time (and pause takes triple time).
How about we just measure CPU time?
Consistant, fits nicely to a turn-based game like NetHack, wouldn't penalize multiletter commands too much.
It measures something which isn't the main goal. Also, you have to decide if you're measuring I/O (reading/writing level files to disk, redrawing the screen) or just pure CPU time.
I still don't see what the problem with counting keypresses is. Ascending with minimal keypresses is closest to "real" time in terms of a player of NetHack; when you play NetHack the speed of the computer is not the rate-determining step, it's the speed you can think and the speed you can input commands. There are actually remarkably few situations where you need to type something in NetHack; and when you do, it's for a very good reason (wishing, genocide, castle tune, Elbereth) so I don't think that this will be too much of a deterrent to using such commands.
If my preferred option doesn't get support, my second choice would be ais523's suggestion of minimal turns, and minimal realtime (total wall-clock time) within that number of turns.
Another question: I have heard from the Duke Nukem thread that JPC-RR doesn't like playing movies if your hdd contents are different. As a result, do we need to agree on a standard defaults.nh file, or even a whole standard NH distribution? Would not matching byte-for-byte cause desyncs or would it just be awkward? A standard defaults.nh file could also prevent players using the ugly and difficult-to-follow extmenu to save keypresses on a minimal-keypress run.
Shortest gametime is probably the best option, being NetHack a turn-based game; the defaults.nh file should be provided by the TASer, since there's no way to set some of the options from within the game (it's popular to set monsters in a way that shows ghosts as 8 or X instead of a blank space, and it makes some areas more interesting to watch - I'm also thinking of autopickup exceptions, which are possible to set ingame but the interface is flunky and having a premade file lets the watchers also know what's going on without having to go frame-by-frame at the beginning of the game).
How about we just measure CPU time?
Consistant, fits nicely to a turn-based game like NetHack, wouldn't penalize multiletter commands too much.
It measures something which isn't the main goal. Also, you have to decide if you're measuring I/O (reading/writing level files to disk, redrawing the screen) or just pure CPU time.
All those operations themselves occur in zero time. Unless you mean completely ignoring I/O system call durations, which would be quite difficult to calculate.
rhebus wrote:
Another question: I have heard from the Duke Nukem thread that JPC-RR doesn't like playing movies if your hdd contents are different. As a result, do we need to agree on a standard defaults.nh file, or even a whole standard NH distribution? Would not matching byte-for-byte cause desyncs or would it just be awkward? A standard defaults.nh file could also prevent players using the ugly and difficult-to-follow extmenu to save keypresses on a minimal-keypress run.
Some extra files are needed anyway, because Nethack doesn't ship with any working DPMI extender (the one known to work is HXDPMI). That file could be put into separate floppy and run from there, but it can also be put together with game image.
As for byte-to-byte identical disk images, Nethack might be special case that syncs even with quite different ROMs. One can edit the image name in movie if one wants to try if it syncs. No guarantees that such editing will give movie that syncs.
As for byte-to-byte identical disk images, Nethack might be special case that syncs even with quite different ROMs. One can edit the image name in movie if one wants to try if it syncs. No guarantees that such editing will give movie that syncs.
I managed to get the Linux version to sync with the DOS version, with a few changes. If even that syncs, slightly different ROMs are likely to have no issues.
Shortest gametime is probably the best option, being NetHack a turn-based game; the defaults.nh file should be provided by the TASer, since there's no way to set some of the options from within the game (it's popular to set monsters in a way that shows ghosts as 8 or X instead of a blank space, and it makes some areas more interesting to watch - I'm also thinking of autopickup exceptions, which are possible to set ingame but the interface is flunky and having a premade file lets the watchers also know what's going on without having to go frame-by-frame at the beginning of the game).
I disagree with allowing custom configuration before the game starts that doesn't count towards a time limit; it would be different from every other TAS out there, every other game that wants to change options changes them in-game and takes the time penalty. Also, autopickup exceptions aren't even in the official version of NetHack (but rather, a common patch or hack on the game); you'd be playing a different game if you used them.
I disagree with allowing custom configuration before the game starts that doesn't count towards a time limit; it would be different from every other TAS out there, every other game that wants to change options changes them in-game and takes the time penalty.
Other games don't allow you to edit the configuration before you start; the ONLY way to change options is through an in-game option screen. With the rule of "game begins from poweron", it therefore follows that changing options must be done in gametime. Since NH has always been based on media with persistent storage, there's nothing to stop defaults.nh having the desired options at time of poweron.
There are some options which would not help a TAS but which would make it more entertaining: showexp, boulder, {cat,dog,horse}name, fruit. It would be a shame to throw these options out by making them too costly to implement in a TAS.
If an option can be implemented/switched on during gameplay, it should be done during gameplay — the more transparent option-fiddling is, the better. This way you won't need an accompanying text file saying what options were used — that can be inferred from the video.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Setting the options ingame is probably counter-productive, unless we aim for something else than realtime: the options screen is confusing to an experienced player, and there are A LOT of options that can be changed; I vote we allow a custom defaults.nh - even though its main purpose is to set autopickup exceptions which i now realize are out of the picture here.
What about purely cosmetic patches though, if they don't mess with the chosen time measuring system?
For what it's worth, nobody cares about absolute values of realtime frames/commands/actions/etc., because there is simply no reference frame. If you spend some of them on options, it's one hundred percent fine because all future runs will have to do likewise anyway. Now if we were talking in-game time, which is highly competed (and thus you have absolute reference), then it would make sense. But options screen doesn't count towards those.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Setting role, race, gender, alignment and name in the nethackrc saves time, setting monsters makes the video show ghosts (has no effect otherwise, this being a TAS - you could farlook every square to look for ghosts, if they're set to the default value of " ") and thus makes the movie more entertaining, pettype lets the TASer choose whether to have a starting pet or not (the type of pet is not important for the distinction between kitten and puppy because they're effectively identical), not sure if there's something else that's DOS-only.
So basically the only desirable command that can't be set in-game is "monsters", and it only has an effect on visibility of ghosts. How severe is this problem? How many ghosts are expected to be encountered during the TAS?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
You're ignoring pettype, although i'm not sure it will be helpful in a TAS - but yeah, if we don't allow cosmetic patches, the only thing that can't be set ingame is monsters (the only helpful thing - you can set objects or dungeon too, but nobody does that). I just think that having a separate nethackrc is better for the watcher and for the TASer - and DS tases allow external settings already, so...
As long as nethack support ACSII, color and lit_corridor.. I'm alright with entertainement.
If the TASer want any special setting, he could simply write them in a external editor or directly by the dos prompt, this should take only several second and would look kind of cool.
For the character creation, just let the RNG handle it?
Now if we were talking in-game time, which is highly competed (and thus you have absolute reference), then it would make sense. But options screen doesn't count towards those.
We haven't decided what the metric for success is yet, but pure in-game time has been ruled out on grounds of opening the door to incredibly boring luck manipulation abuse. (You can shuffle the RNG without wasting in-game time, so you could endlessly shuffle each action until it's totally optimal.)
Is there a list of options that can't be set in-game that are relevant to TASing, together with their descriptions?
http://nethack.wikia.com/wiki/Options has a complete list, with each one labelled "Can/Cannot be set in-game".
I'm quite keen to see TASes setting "fruit". It has no value for TASing besides entertainment, but it's part of the flavour of NH that you can specify an arbitrary food-item (and even collect different kinds in bones levels). If you don't set it, it defaults to "slime mold". Here are some silly ideas for fruit names. I especially like "1-up mushroom", "booger", "strip of bacon" and "sand hamwich".
Speed-related options (depending on speed metric) include autopickup, autodig, autoquiver, pickup_types, confirm, menustyle, extmenu, mail. I don't think much advantage is gotten by setting them ingame, because if you know NH well enough to know what the option means, you can recognise when it's in effect without needing to be told.
Speed-related options (depending on speed metric) include autopickup, autodig, autoquiver, pickup_types, confirm, menustyle, extmenu, mail. I don't think much advantage is gotten by setting them ingame, because if you know NH well enough to know what the option means, you can recognise when it's in effect without needing to be told.
This is mostly correct, except for "mail". On the DOS version, the occurrence of mail daemons happens at random, and thus the option does not just change speed, but also has an effect on luck manipulation.
regardless of minor technical squabbles it seems like the place to start would be determining the rout for a least turn run. Then figuring out how the chosen run should change from that
A truly optimal "least turncount" run would probably involve YEARS of realtime luck manipulation - anyway...
In 2000 turns, you should take the candelabrum and the book, then, lighting the candelabrum and killing a monster at T:2000, you should (assuming this is a wizard or someone with the Eye at least) get permission by getting the QL to talk to you (abuse the speed system as needed to get permission on T:2000), levelport down to the quest goal level, oneshot the quest nemesis, move to his square where you'll autopickup the quest artifact and the Bell, then branchport to gehennom (landing in the VotD), levelport down to the vibrating square level (landing on the VS if possible), then ring the bell and read the book, then levelport down, landing in the sanctum, near the HPoM, oneshotting him, moving to his square autopickupping the Amulet, then c!oGL until on Earth. Assuming perfect luck, always getting 3 actions/turn as an air elemental, you should reach the plane of Earth on turn 2022. I'll let someone else calculate the closer portal there, and what's the best form to reach it. To carry enough cursed gain level pots, one would need to place stashes on some levels in gehennom - this shouldn't be a problem because we have 2000 turns that we *need* to wait for the quest to unlock.
