The principle to follow when working on projects on a computer is 'save early, save often'. I've been bitten by crashing programs and power outages too often.
If the only difference in PJ2.0 vs N64 is lag, then wouldn't it be able to be console verified still? In the same way the SM64 TAS was console verified, even though mupen had different amounts of lag in different places, because the game only polled on input frames and so the TAS could be a stream of input frames.
BisqBot had to be told that increasing x co-ordinate is. good, getting power ups is good, taking warp pipes is good, etc and dying is bad in SMB1. The novelty of this bot is that you don't tell it what to do - it watches you play and assigns itself its goals for the game. BisqBot is great but the idea of this bot is that it decides what it wants, in a way I haven't seen applied to game bots before.
(btw, I think this should be split to http://tasvideos.org/forum/viewtopic.php?t=13996 ) (Mod edit: Done --Mothrayas)
Guess we should ask the devs if using the 1.6 source is allowed then... now that 2.0 is officially open source I don't think they'll have anything against it...
Apparently there are some settings you can change in 2.0 to make oot play more like it did in 1.7/1.6 in terms of loading times. Scour through the comments on cosmo's youtube video for people's suggestions
What would the ruling be if someone wanted to TAS a super mario world romhack that crashed in bizhawk/lsnes due to a physically impossible echo buffer size that snes9x allows?
(H)alf of the hacks they provide do not run on an actual SNES, let alone on accurate emulators. This is because of a flawed tool known as addmusic. It was designed to allow hackers to insert new music tracks, but it was developed with and tested against an inaccurate emulator. One that cheated when it came to DSP sound emulation. The echo effect of the SNES DSP works by writing previous results into RAM, in order to mix with them later. This addmusic tool did not know this, because the emulator did not do this. As a result, impossible values were used for echo buffer sizes, which on real hardware and accurate emulators, results in all of the APU's RAM (and thus, program code and samples), being overwritten—crashing the game.
The run is fun to watch. I wonder what "bad ending" would be like.
Bad ending would not be very interesting. Same route except you wouldn't need to use the eversion glitch to reach -8 (the purple realm) which allows you to do the true final stage. I would consider this to obsolete any 'bad ending' run and 'all gems' to be the 100% of the game. Not sure if all gems glitched or glitchless would be better though, I guess the runner decides that one :)
Well, here's an incomplete playlist of a japanese runner TASing it:
http://www.nicovideo.jp/mylist/35757062
Goes up to Mission 14. Needs a Nico account, but it's pretty swanky. It's very much a "spends time for entertainment value" sort of run, but that's not a bad thing.
Really interesting, I'd like to see the result when you feed the bot one of those sub 5 minutes mario run.
The way it is currently written I suspect it would suspect it wouldn't do better than any good play of SMB1, because what it does with the input file is observe what memory addresses tend to go up over time (and in what ways) and what the input tends to be like for playing the game (identifying motifs).
Sorry this is my first post and already it is a new topic at the off topic section. But I just did not know where to put this. So please feel free to moderate or relocate.
I'm reading the research paper now, it's a cool read. (One thing the bot does is, instead of trying inputs randomly, it prefers input chunks that featured commonly in the input file used to train the bot, which both means it can look ahead in larger chunks than single frames and tries to play the same way you did)
One thing that strikes me is that the author often laments that things like frame counters and music cursors (that go up regardless of how good your play is) ensure that the bot will include them in their objective function for scoring (since they go up as progress is made) even though they are not discriminating. Maybe the bot, either while computing the objective function or as it plays and observes the objective function set, could notice when variables go up no matter what, and steadily weigh them less and less.
(On the other hand, such functions that always go up might NOT go up when the player character is currently dying - and such a variable suddenly IS discriminatory, and the input sequence the bot uses to learn the game might not include any or many deaths. So this isn't a perfect solution either.)
EDIT 1: At the end he admits that he hasn't gone as far as he'd like to due to the conference coming up. So, I'm interested to see if this will go further. Since he lists potential improvements and makes the source code available, maybe some collaboration/feedback could even happen?
EDIT 2: adelikat and TASVideos in the references at the end :')
http://www.cs.cmu.edu/~tom7/mario/Link to video
Ok, this isn't my work but it's really, really cool. Basically, this guy wrote a bot that plays NES games by attempting to increase addresses in memory that have a lexicographical ordering (for instance, score goes up but it has more than one byte - but lexicographically it still increases when you observe someone play) and trying multiple future sequences and greedily picking the best one. Without knowing anything about a NES game except what it sees happen in memory from the game being played once by a human (which it uses to decide what memory addresses are important, e.g. increase lexicographically), it displays emergent skill in games like Super Mario Bros due to being driven to increase score and scroll the camera right (two lexicographical orderings) and therefore to progress and not to die to hazards (preferring to get their score). It even finds glitches in the game and does insanely risky dodges purely because it keeps the bot alive.
In the video the gameplay starts at about 6 minutes in. He's published a paper and source code for it.
While the bot only gets so far before dying in each game, I think that if it was made more 'death-averse' somehow and looked a bit further ahead it would be able to beat simple NES platformers. It's really exciting that it can get so far with so little knowledge of the game![/i]
If you care about it being as accurate as possible to the console, etc then you'd be watching it in emulator anyway, IMO. Remove the black screens so I can see what's going on! (Maybe with some kind of on screen indicator that a blackout has happened. Dim the screen maybe?)
Voted no because:
-You didn't beat andrewg's unassisted time of 4:58.
-You didn't jam to the amazing original background music featured with this original game.
-You clearly used a game genie code to let cheep cheeps hold L to levitate.
-You didn't jump through any hammer streams.
-This game teaches poor lessons to children about the physics and procreation of spinys. I cannot in good faith vote Yes to a TAS that spreads false information about the finest creature of the Mushroom Kingdom.
There is an any% TAS being worked on of this game at Nicovideo:
Link to videoLink to video
It has a LUA hud and is aware of the major sequence breaks thus far (black toad skip via OoB, the 'pie double jump' in chapter 1). Hopefully he will do lava pirahna skip, etc :D
If you haven't been keeping up with any% of this game, the lava pirahna skip means you do almost nothing in chapter 5 - you get sushi, glitch into the volcano, glitch out of the volcano without fighting the boss and peace out to chapter 6.
Link to video
