I agree with feos's post entirely. Well spoken. In one sentence - don't let the perfect be the enemy of the good. If it's not feasible for everyone to use the most accurate emulator (due to secondary reasons, like OS compatibility, slowness or script/workflow compatibility) then don't demand it until the roadblocks are fixed, or instead of a good TAS you get no TAS at all.
My view is: If you want Gen TASers to swap to Bizhawk, then accomodate their workflows (performance/OS compatibility needs, camhacks and other scripts they rely on, etc). Otherwise you're asking for TASers to effectively make worse work by swapping to an emulator that is less performant for their use cases. Until that's no longer true, it's too early to require a switch. (This is similar to how e.g. snes9x TASes are still allowed, even though Bizhawk's SNES core is more accurate - since its performance is so much worse, it would be too excluding to mandate it.)
I've already watched this TAS and it's great. In true metroidvania TAS, it goes from walkathon to a blur of maximally exploited movement techniques, and combat is unbelievably fast.
Not sure if this counts, but...
In SMW low-exit-count, we don't allow glitching a cloud into the item box to later glitch out Bowser's AI because the glitch used can also be used to game-end-glitch the run and why wouldn't you just do that instead?
Is the glitch actually banned by tasvideos rules, or is it really just that the TASers who could do this any% route aren't interested because it doesn't make sense from a TASing perspective to use a trick that can trivially be used for ACE instead, whereas in RTA the setups for cloud and ACE are so distinct that they don't overlap?
Overall I just enjoy the sheer perfection a TAS displays. Like a song sequenced in a program, a TAS has none of the flaws of human playing left, and is entirely an optimisation challenge solved, a work of visual audio art.
Enjoyed it. In-bounds movement is on the slower end of TASed castlevania runs but what can you do?
What's NKT mean? It shows up a lot in the niconico comments of the temp embed when the ending starts.
It's a meme that means (IIRC) "It was a long and challenging adventure." It's making fun of how short Castlevania TASes tend to be due to the glitches and movement tech.
The other one that commonly shows up is shouting IGAAAAAAAAAAA when IGA's name appears in the credits.
Thought of another one, it might be possible nowadays. In secret of mana, you can unplug second and third controllers to return second and third players to AI control for a while, and this is useful since the AIs don’t trigger things like cutscenes like players do. But I don’t think this is possible to TAS yet.
I suppose there probably are games where you could somewhat reliably play back a TAS using real time (on a sufficiently powerful computer).
Even then it would be pretty difficult - modern OSes multitask a ton, and you never know when a frame will take slightly too long to compute of resource contentions at the wrong moment. It's not like playing something back on a NES where there's only one thing going on (the game) and no nondeterministic I/O or multithreading.
I guess the main 'problem' here is that instead of fully simulating a computer and advancing it by a specific amount of cycles (like JPC-RR), we're residing inside of a computer, fooling another program by swapping out the results of system calls, into thinking that certain amounts of time are passing (and other things). But if something about this 'fake time' concept is suspect, then shouldn't we apply the same suspicion to Hourglass TASes, which IIRC do a similar thing? Obviously the reason why we're talking about it now is to standardize rulings on FPSes usable in Linux TASes, but why was there no similar debate for Windows TASes?
I think this is the correct interpretation:
So I can TAS computer games at any monitor refresh rate I can successfully emulate it being VSynced to and that exists (60, 120, 144, etc)?
This would mean the 1000 FPS Towerfall Ascension TAS is rejected as invalid, even if an existing computer could run it that fast, unless a monitor that refreshes that fast can be proven to exist. Conversely, the 120 FPS Axiom Verge TAS (not submitted yet) is valid since a 120 FPS Monitor does exist.
Probably JPC-rr-TASScript will have sub-millisecond input and DOSBox inside libTAS won't, so which emulator is optimal will depend on what you're TASing.
DrD2k9 wrote:
EDIT:
In case it happens to anyone else. Chrome is warning me that the download may be dangerous because it's not a commonly downloaded file (whatever that means).
Browsers like Chrome keep track of which executibles and zips have been downloaded very few times globally, and assumes they are malware by default. But it is just making a guess to help low information users' safety. If you know it is safe because you trust the creator, you can ignore the warning.
I understand Warp's concern, in that it reminds me of the alt+tab glitch in Super Meat Boy - by tabbing in and out of the program mid movement, you create arbitrary amounts of lag, and the game's arbitrary frame rate will move you forward by a huge amount and clip you past walls. It doesn't feel like you're really playing the game as intended, but instead exploiting that the arbitrary frame rate has no reasonable limits. But is it different in spirit to lag clipping in DK64? I am not sure if it needs to be specifically ruled out or not - or more to the point, what kinds of objective rules you would instate, if you think this is not desirable.
Could one of the admins please update our submission file with this one that's one frame shorter?
We discovered that we had lost a frame between Bowser's death and the door opening due to an unfavorable Bowser y sub-pixel. This was fixed with a trivial change to 8-Tank2; the rest of the input is unchanged. Thanks.
Haha, does that mean it's now a 0 frame speed/entertainment tradeoff? Because you were only 1 frame behind before this.
So some PC games have speedrun modes where they basically play an in game timer during your play through, games like Celeste and Fez have this. Is it required in cases like this to TAS the game in this mode or can the authors do this by choice?
What would be an example of a situation where you forego using the provided speedrun mode?
If it is emulating hardware that a normal human would use at time of game release, it's OK. If it's emulating hardware that is not available to a normal human (i.e. no super computers), or came out after the game was released, it's not.
One question I'd ask to clarify your view - if the game has been updated since then, can hardware used at the time of its most recent update be emulated?
Is there a ruleset that could be decided upon that disallows running games tied to CPU speed at rates higher than intended, but still allows free framerate manipulation below that limit (and above for games that don't apply)? That seems like the best solution.
My suggestion from the Towerfall Ascension thread should work. In brief:
* If a game's speed increases asymptotically with higher FPS (e.g. because it lets you put in inputs faster and certain tricks are more efficient, but the game tries to run physics at a framerate dependent speed so running at 1bil FPS doesn't make the game finish in under seconds e.g.), then raising the FPS is OK. (Additionally, future TASes are not required to run at the same FPS. Time lost purely because of setting the FPS to a different value is not counted, similar to how time lost purely because of changing regions or languages is not counted.)
* If a game's speed increases unbound with higher FPS (like a DOS game that gets 2x as fast every time you double cycle speed) then raising the FPS is not OK. Use some meaningfully defined default (like the game's default FPS if it has one, or how fast the game would run on typical machines when the game was released if it does not)
The stat system seems to be based on old school (1st and 2nd edition) D&D. The stats are Strength, Dexterity, Constitution, Intelligence, Wisdom and Charisma, And normally vary in the range 3-18 (the result of rolling 3d6). However, Fighters have a mechanic called ‘exceptional strength’ where their strength can range from 18/01 to 18/99. This post explains it well: https://rpg.stackexchange.com/questions/59638/how-does-fighter-strength-work-in-advanced-dungeons-dragons-2nd-edition-and-ba
Many old roguelikes and RPGs based their stat system on D&D, which is why this weird vestigal mechanic crops up in unexpected places, like Angband and Nethack.
