1 2 3
7 8
Posted: 1/18/2016 1:15 AM
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
True wrote:
Nach wrote:
I think making such a thing is unnecessary.
What, computer vision robot? It's a neat thing. Is it necessary? No, none of this is necessary. Yeah, we can illegally run a ROM alongside a game and hope it doesn't go out of sync...or we (or I) can write an AI that beats a game unmodified, like K3, and can adapt this to other platformers. I could even have it press keyboard buttons mechanically :)
Such a robot though won't be able to manipulate luck. If it can't, then it's not related to TASing anymore.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 1/18/2016 7:11 AM
Quote
True
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
That doesn't mean that such a robot can't manipulate luck, just that it can't do so presciently. Obviously the goal would be not be to read game state through a side channel (as in, anything not on the screen) to play as a human would, so in this case, the RNG would need to be characterized if it would be manipulated by the robot. Also, TAS does not equate to "luck manipulation," which is merely one facet of creating a TAS movie. The first two letters of TAS are "Tool Assisted." So not only would this robot be related to TAS, it _would_ result in tool-assisted play which could result in TAS. Just because the input derived might not be submittable here doesn't mean it isn't a TAS. Perhaps a different take on this robot: it could act as a trainer helping a human player by taking over their inputs and helping them escape trouble (not hitting any spikes for example - hold right for justice).
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Posted: 1/18/2016 10:39 AM
Quote
Warp
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
I think Nach makes a good point in that chaining consoles like this is too finicky and prone to something going wrong, with too little payoff to be worth it. Even if just one of the consoles in the chain does not sync properly, the entire thing will fail. If you have, for example 5 consoled chained like this, and it takes something like three minutes for eventually console #4 to be taken over, and console #5 fails to sync properly, what will you do? Start over, or end the demonstration there as only partially successful? What if it's console #3 or #2 that fails? Something that Warepire wrote gave me a different idea, involving two consoles. I don't know if it's technically possible, but maybe: What if one console would be taken over by tasbot, and made into a tasbot itself, and would then proceed to TAS another console as normal? In other words, for example, tasbot takes total control of a SNES console, which is connected to a NES console, and proceed to TAS a game as normal on the NES. Tasbot itself could be disconnected (if possible) on camera to demonstrate that it is indeed the SNES which is TASing the NES game. This could be made so that even if the NES fails to sync at first, the "tasbot" program in the SNES is constantly running, so the NES can simply be restarted for a new attempt. Obviously this should be clearly explained by the presenters and, if possible, shown on camera to the livestream. As said, I have no idea if this is technically and physically possible, but could be an idea.
Posted: 1/18/2016 12:55 PM
Quote
total
Player (41)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Warp wrote:
In other words, for example, tasbot takes total control of a SNES console, which is connected to a NES console, and proceed to TAS a game as normal on the NES. Tasbot itself could be disconnected (if possible) on camera to demonstrate that it is indeed the SNES which is TASing the NES game.
This is a pretty cool idea, and something I think would be very possible without even any extra hardware apart from a custom made cable between the SNES and NES controller ports. A SNES should certainly be fast enough to be able to send inputs to a NES using manual polling register reads and writes. There would be a limit ofcourse to fit the controller data in SNES RAM, but 128k should be enough for a pretty decent TAS.
Posted: 1/18/2016 5:31 PM
Post subject: A Virus? Yes! We should try this.
Quote
dwangoAC
Moderator, Senior Ambassador, Experienced player (907)
Joined: 9/14/2008
Posts: 1014
Exotic platforms TASer of 2015 Exotic platforms TASer of 2013
My original intent was to make it so if the next console in the chain failed for any reason, we would just reset that console and send data "fresh", reducing the risk that we would be unable to complete the chain. I realize there is some amount of risk, and if through the process of developing the chain of consoles we discover it is too fragile we will give up and do something else, but I'm not willing to admit defeat without even trying. :) Virus yes! :) While I originally envisioned this as one long chain of unbroken consoles I kind of like the idea of writing a virus that can take over the next console in the chain independently. It may be the same level of risk - as described above, if the next console has a problem the payload for the previous console would need the same logic to know that if the "downstream" console powers off, restart the payload from the start. This approach tells me that we need to start from the biggest consoles and work our way back down as some of the movie files could be too large to fit in memory on the slower consoles. Much testing is needed to know if this is even a sane idea but we still have 11 months to go so there's time to change course as needed. Thanks for everyone's ideas!
I was laid off in May 2023 and became too ill to work this year and could use support via Patreon or onetime donations as work on TASBot Re: and TASBot HD is stalled. I'm dwangoAC, TASVideos Senior Ambassador and BDFL of the TASBot community; when healthy, I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Posted: 1/19/2016 12:03 AM
Quote
ais523
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
I think "save-persistent" ACE is an obvious next step to use (i.e. TASbot permanently reprograms a game via putting stuff in the save file that would mean a few simple manually-entered controller inputs would re-ACE it upon load). You can definitely do this in both Pokémon and Pwn Adventure Z, so it's probably possible in quite a few games. You wouldn't have to combine this with the console chaining idea, but if you did, it'd basically mean reprogramming a console to turn it into a TASbot. Which is a pretty crazy (and fun) thought, and pretty much in line with what Warp was suggesting.
Posted: 1/19/2016 4:24 PM
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
I'd like to emphasize that we should think about what this will look like to the audience. Taking over consoles is cool and all, but if the big payoff is just that we show a little demoscene video on an NES (or some other "small" ACE demo), I don't think it's going to have that much of an impact, no matter how much effort went into achieving that video.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 1/19/2016 4:37 PM
Quote
dwangoAC
Moderator, Senior Ambassador, Experienced player (907)
Joined: 9/14/2008
Posts: 1014
Exotic platforms TASer of 2015 Exotic platforms TASer of 2013
Derakon wrote:
I'd like to emphasize that we should think about what this will look like to the audience. Taking over consoles is cool and all, but if the big payoff is just that we show a little demoscene video on an NES (or some other "small" ACE demo), I don't think it's going to have that much of an impact, no matter how much effort went into achieving that video.
That's exactly why my intended payload is "live" and able to respond to things happening in the room, i.e. an equalizer that moves based on when the audience claps, or can be fed from some awesome soundtrack (possibly one produced by one of the newer consoles). I'm more than willing to experiment with the virus idea, though, having one console take over the next take over the next, and simply physically moving TASBot that has now been upgraded to work without even touching a controller from one console to another to show where the locus of control is as the process advances. I'm willing to pursue all avenues here. Thanks for the feedback!
I was laid off in May 2023 and became too ill to work this year and could use support via Patreon or onetime donations as work on TASBot Re: and TASBot HD is stalled. I'm dwangoAC, TASVideos Senior Ambassador and BDFL of the TASBot community; when healthy, I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Posted: 1/19/2016 7:06 PM
Post subject: Re: A Virus? Yes! We should try this.
Quote
ars4326
He/Him
Experienced player (777)
Joined: 12/8/2012
Posts: 706
Location: Missouri, USA
dwangoAC wrote:
...Virus yes! :) While I originally envisioned this as one long chain of unbroken consoles I kind of like the idea of writing a virus that can take over the next console in the chain independently...
Dwango, when I read "virus" in your post, I immediately thought of Final Fantasy IV and someone casting the spell Virus in battle. So could this be an idea? Say, an event happens on one of the other consoles that has something to do with viruses in the game's story (whether a cut-scene, or someone casting a "spell virus", etc.). After the virus scene occurs, you'd then use that as a swerve to cause the actual virus payload.
"But as it is written, Eye hath not seen, nor ear heard, neither have entered into the heart of man, the things which God hath prepared for them that love him." - 1 Corinthians 2:9
Posted: 1/19/2016 7:40 PM
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
True wrote:
That doesn't mean that such a robot can't manipulate luck, just that it can't do so presciently. Obviously the goal would be not be to read game state through a side channel (as in, anything not on the screen) to play as a human would, so in this case, the RNG would need to be characterized if it would be manipulated by the robot.
I agree, but a robot crippled in this way wouldn't be able to take advantage the way a normal TAS can. The idea we have in TASing is that the player becomes perfect, omnipotent if you will. That doesn't hold true (no pun intended) if the robot is using vision alone to play.
True wrote:
Also, TAS does not equate to "luck manipulation," which is merely one facet of creating a TAS movie. The first two letters of TAS are "Tool Assisted." So not only would this robot be related to TAS, it _would_ result in tool-assisted play which could result in TAS. Just because the input derived might not be submittable here doesn't mean it isn't a TAS.
I agree with this point too, but it undermines the foundational essence of what a TAS is - perfect play, knowing all the variables.
Warp wrote:
Something that Warepire wrote gave me a different idea, involving two consoles. I don't know if it's technically possible, but maybe: What if one console would be taken over by tasbot, and made into a tasbot itself, and would then proceed to TAS another console as normal?
I like this idea a lot. On a practical level, if you're using an SNES with Super Mario World, or a Gameboy with Pokemon Yellow, or an NES with Super Mario Bros 3, or any other compatible console/game combination, I'd have it do the following: First show a TASBot boot up splash-screen. This way the audience can see the console itself is now a TASBot. At this point, we can disconnect the first TASBot from it and plug in a regular controller. In TASBot OS, we can show a couple of options (to be determined later). One of the available options in the OS is "TASBot reproduction sequence". In that menu it can choose which combination console/game to reproduce into. We plug in the appropriate console to the first one, and start the process. During the reproduction process, we see a screen which says something like "TASBot reproducing", with a progress bar and percentage indicator. The progress should be worked out in advance to increase at a consistent rate, and reach 100% when the second console shows the TASBot boot up splash-screen. If we can get the bootstrap sequence and payloads small enough for each system, we should be able to install an identical TASBot OS with payloads for all systems onto each one. We may need to RLE the bootstrap for certain games to make this feasible. We should also take advantage of SRAM or anything else offered to eek out as much space as we can to make the OS self working. Lastly, after we show all the consoles are running TASBot OS, one of the options to choose from should be saved for the end and shown (nearly) simultaneously on all of them. Maybe something cute like TASBot announcing that even though it can go terminator on all humans, it would rather save humans and wants people to donate for a good cause.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 1/19/2016 8:22 PM
Post subject: Re: A Virus? Yes! We should try this.
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
ars4326 wrote:
dwangoAC wrote:
...Virus yes! :) While I originally envisioned this as one long chain of unbroken consoles I kind of like the idea of writing a virus that can take over the next console in the chain independently...
Dwango, when I read "virus" in your post, I immediately thought of Final Fantasy IV and someone casting the spell Virus in battle. So could this be an idea? Say, an event happens on one of the other consoles that has something to do with viruses in the game's story (whether a cut-scene, or someone casting a "spell virus", etc.). After the virus scene occurs, you'd then use that as a swerve to cause the actual virus payload.
Tangentially related, but you could also have a payload that consists of one console providing some form of "commentary" on another console, or recreating an approximation of the events on that console in its own game. For example, the primary run is Super Mario Bros. and the secondary run is Final Fantasy: when mario dies, so does Fighter; when Mario throws a fireball, Fighter casts Fire1, the flagpole at end-of-stage signals the end of the fight, etc. Then you hand the controller of the primary game to someone to demonstrate that the system is working "live". Though I must admit I'm unclear on how you would read state from console 1 to feed into console 2. Consoles don't have much in the way of output capability that I'm aware of.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 1/20/2016 1:22 AM
Quote
ais523
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
The significance of the word "virus" hadn't occurred to me, but it genuinely would be: a cross-platform TASbot virus that ran on old games consoles and caused them to infect each other. That's something that I suspect journalists could really get behind. A long-shot idea I'd like to throw out there while there's potentially still enough time to make it work: this idea of using one console as a controller another made me wonder if there's any instance where you can officially use one console as a controller for another. And of course, there is: a Gameboy Advance is an official Gamecube controller (and I know that the Gamecube at least has the ability to "officially" run code on the Gameboy Advance, not sure about the other direction). You could thus get one to infect the other without even needing any sort of special cable (with no extra glitches, even, if it were the Gamecube infecting the GBA). This is quite an unfortunate console pairing, though, because neither has a really accurate emulator yet as far as I know (and I don't know if information on the controller protocol between them is public yet, although admittedly I haven't looked). The big advantage, though, is that given that the Gamecube uses separate memory cards, a save-persistent Gamecube exploit could be prepared in advance and used to infect a GBA at any time, which would make testing much easier, and also provide a huge amount of space for storing anything we need to store (we're talking about megabytes here). I also fear there might be some sort of checksum on the GBA end that prevents people feeding homebrew into it along the controller cable the intended way.
Posted: 4/26/2016 11:57 PM
Quote
BigBoct
He/Him
Editor, Former player
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
After a bit of discussion with dwangoAC on IRC, I am nominating [2529] Windows Hyper Princess Pitch "Reallyjoel's Mom difficulty, best ending" by Tseralith in 15:40.48 to be shown at AGDQ 2017. I feel like it's a good candidate on the ground that the ReallyJoel's Mom difficulty is completely impossible under unassisted conditions. Currently poking around for a mirror of the v1.3 Tseralith used for the run; will update this post once I find one and then again if I can sync it on W7.
Previous Name: boct1584
Posted: 4/29/2016 2:25 PM
Quote
BigBoct
He/Him
Editor, Former player
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
I did indeed find a mirror of v1.3 at http://hyper-princess-pitch.en.uptodown.com/ and I have also synced it on Windows 7 x64. Oddly, I can't get the movie to play properly on my Windows 7 x86 machine.
Previous Name: boct1584
Posted: 5/17/2016 8:22 PM
Quote
endrift
Any
Emulator Coder
Joined: 12/14/2014
Posts: 161
I bought a Game Boy Pocket over the weekend, partly for shits and giggles, partly for research, and realized something just now: if we could get a video out board for it, it would probably be pretty feasible for me to turn it into a TASbot prop. Have ROB holding it, wires hidden beneath, and it playing the GB in its hands. I don't know if any video out boards exist, or how hard they'd be to make, but it's a neat idea that might be feasible. I could presumably pick up a DMG to do the same thing with, since that would look "more authentic", but DMGs are a bit more troublesome to open up.
Posted: 7/10/2016 6:44 AM
Quote
comex
Joined: 12/4/2013
Posts: 8
I'm only a TAS fan, not a creator thus far, so don't mind me too much, but here are some broad suggestions for the next or any future GDQ: - I don't remember seeing any GDQ TASes that focused on showing off luck manipulation. To me this has a big "neat" factor whenever it's done either live or in TAS. While luck manipulation isn't TAS-only, TAS can make it work in far more games and with much more sophistication than a human, making it a good example of why TAS is inherently interesting rather than just a "cheat". An ideal showcase would be a game that is highly luck-based and can be completely broken with just luck manipulation, no other major glitches. CCGs sound like they could fit the bill well; in the "Heavy luck manipulation" category I see Gostop DS and Pokemon TCG, both around 20 minutes, though I haven't watched them (yet). (There is also Yu-Gi-Oh! Forbidden Memories, but it's longer and its description says "[t]he chances for manipulation are limited". Of course, there are dozens of other, unTASed Yu-Gi-Oh and Magic games...) Turn-based tactics games like Fire Emblem might work too, or even RPGs, though you probably couldn't get through the whole game. One big caveat: many/most submitted TASes of turn-based games go through the menus too fast for a viewer to have any real idea what's going on (without constantly pausing, at any rate). The result may be fast, but at least to me it’s not very entertaining at all. Especially for an exhibition, I think it would make more sense to optimize for some sort of turn count, then rate limit menuing so the viewer can follow along (and the couch can at least make an attempt to explain interesting mechanics). Of course, doing that would blow up the aforementioned 20 minutes considerably, but it may not be necessary to complete the whole game, or there may be other games/modes that can be completed faster. - Arbitrary code execution is now old hat both here and at GDQ - but only on 8- and 16-bit consoles. ACE in a 3D game would both be a novel feat and present the opportunity for a very different post-control playaround. Including just basic visual corruption effects - we've seen what sprite corruption on old systems look like too many times to count, but the silly effects you can get in 3D by messing with vertices and such are much less well known. More structured effects like cel shading, outlining, night vision, etc., usually associated with shader overrides on emulators, should also be possible to replicate on console in at least some cases. Probably lots of more elaborate things I haven't thought of. Not sure how much time people on this site have spent looking for suitable bugs in 3D games. Certainly likely to be much rarer due to higher level code, higher likelihood that invalid states crash rather than doing anything interesting, etc., but far from nonexistent. Super Mario 64 in particular has so much known about it and so many glitches... (This is something I actually know a little about; I once wrote an exploit for Brawl people still use for homebrew, albeit based on save data rather than controller input. Maybe someday I'll spend time on my dream of finding an ACE bug in Melee. But I'm lazy.) Of course this also runs into the issue that most modern consoles have never had attempts at TAS verification, and may require fundamentally different techniques to verifiably TAS due to timing variation. But the N64 at least has been shown to not require this. - Oh, and yes please on Hyper Princess Pitch! That run was amazing.
Posted: 7/22/2016 8:01 PM
Quote
BigBoct
He/Him
Editor, Former player
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
A few more ideas while I'm stewing in boredom at work. Various people have suggested we try Gradius again at various points. I would also like to see it tried again. I'd also like to see the 4-CPU Monopoly run if it can be made to sync.
Previous Name: boct1584
Posted: 7/23/2016 3:05 AM
Quote
Bobthefloater
He/Him
Joined: 11/20/2015
Posts: 31
comex wrote:
I'm only a TAS fan, not a creator thus far, so don't mind me too much
So you're basically the equivalent of the people watching these runs, telling the organisers (I would say 'us' if I was one of 'them') what you (and viewers as a whole) would find entertaining. People should consider absolutely every word you have said. (BTW, searching 'executes arbitrary code' gives no 3D games, i.e. we cannot do an ACE for a 3D game yet; but it would be cool if we could.)
Posted: 7/23/2016 8:15 AM
Quote
Warepire
He/Him
Editor
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
boct1584 wrote:
After a bit of discussion with dwangoAC on IRC, I am nominating [2529] Windows Hyper Princess Pitch "Reallyjoel's Mom difficulty, best ending" by Tseralith in 15:40.48 to be shown at AGDQ 2017. I feel like it's a good candidate on the ground that the ReallyJoel's Mom difficulty is completely impossible under unassisted conditions. Currently poking around for a mirror of the v1.3 Tseralith used for the run; will update this post once I find one and then again if I can sync it on W7.
I just saw this post. As much as I would love to see this presented, I have to say it's a bad idea to submit this without extremely careful planning. The technical description by YaLTeR is here: https://github.com/Hourglass-Resurrection/Hourglass-Resurrection/issues/30 This is in untouched code since nitsuja's Hourglass-win32. The less technical description is: nVidia driver devs are using userspace WinAPI calls to do driver-stuff. There may be problems with ATI and Intel as well, we don't have any graphics cards / chips from those vendors at our disposal. The issue lays in how the nVidia drivers initialize their states when Direct3D9Create is called, which is what Hyper Princess Pitch uses. Leaving the driver permanently hanged in the initialize steps and the game never launches.
Posted: 7/23/2016 1:51 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
Bobthefloater wrote:
So you're basically the equivalent of the people watching these runs, telling the organisers (I would say 'us' if I was one of 'them') what you (and viewers as a whole) would find entertaining. People should consider absolutely every word you have said. (BTW, searching 'executes arbitrary code' gives no 3D games, i.e. we cannot do an ACE for a 3D game yet; but it would be cool if we could.)
Maybe there is a way to poll the broader GDQ audience and ask what TAS THEY want to see? It might help guide GDQ content, if it's possible to reach enough people to ask.
boct1584 wrote:
I'd also like to see the 4-CPU Monopoly run if it can be made to sync.
I can probably help with any NES stuff that needs to be done on the emulator side to get things like that working.
Posted: 7/23/2016 2:23 PM
Quote
DeHackEd
Emulator Coder, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Another vote for the four CPUs monopoly run. As a special request, I would like it to be presented like this:
At the end of input, call "Time!", unplug the controllers and wave them in the air to show you disconnected tasbot. Then start talking about the heavy luck manipulation of the run as through the run was actually over even though it's still playing. "Sorry, what? Oh it's basically over. We've won."
Or something to that general effect. Also Dwango had a TGM (Tetris) request we discussed briefly in IRC
Posted: 7/23/2016 2:52 PM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
I suggested the same idea for Gradius btw.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 7/23/2016 8:06 PM
Quote
ais523
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
You need to be very careful with disconnecting controllers. It's been known to cause spurious button presses, especially of Start, which would rather ruin the effect.
Posted: 7/24/2016 2:38 PM
Quote
dwangoAC
Moderator, Senior Ambassador, Experienced player (907)
Joined: 9/14/2008
Posts: 1014
Exotic platforms TASer of 2015 Exotic platforms TASer of 2013
A few updates which I haven't made to the first post yet:
  • comex, thanks for the feedback. You are spot on about the luck manipulation aspect, which is why I featured it so heavily in Mega Man at SGDQ 2015. It could certainly be done again, and it could almost positively be done better than I did the first time. I'm with you in that I'm not sure what the best game choice would be for this as it needs to be short and the luck manipulation needs to be obvious; I'll put some more thought into this.
  • A proper 3D console ACE would probably cross over to the demoscene world. I'd be interested to see something here, but it will require many hours of work and for now will likely be limited to N64 games. Keep in mind that we can only control RAM so we'll probably have to get creative with whatever assets are in the ROM of the game we find an ACE in, and if you re-parse that sentence you'll probably start to get the same feeling of "Wow, that's going to be a lot of work!" but if we can pull it off I think it would be awesome.
  • Gradius is a possibility now that we have reliable cabling, but honestly I think I'll save that for SGDQ 2017. I'd change my mind if, say, adelikat was willing to come to AGDQ 2017 and could provide commentary in person (doing it over Skype isn't worth it).
  • Hyper Princess Peach is definitely interesting but risky. I'll probably save this one in the wings for a while. There are some cases where people complain about us showing TAS's that came out a couple of years previous but the content is nearly always new to the vast majority of the viewing audience so I'm not worried about holding off on this one for now.
  • Regarding feedback from the general speedrunning community, see this post: https://forum.speeddemosarchive.com/post/tasbot_sgdq_2015_feedback_thread_for_improving_future_gdq_appearences.html
I'll update the first post soon to include things that need to be carried over from SGDQ 2016 and didn't get used, like NESPack and Super Scribblenauts for the 3rd time :).
I was laid off in May 2023 and became too ill to work this year and could use support via Patreon or onetime donations as work on TASBot Re: and TASBot HD is stalled. I'm dwangoAC, TASVideos Senior Ambassador and BDFL of the TASBot community; when healthy, I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Posted: 7/24/2016 7:29 PM
Quote
jlun2
Skilled player (1741)
Joined: 9/17/2009
Posts: 4981
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
GBA TASer of 2010
dwangoAC wrote:
A few updates which I haven't made to the first post yet: [*]A proper 3D console ACE would probably cross over to the demoscene world. I'd be interested to see something here, but it will require many hours of work and for now will likely be limited to N64 games. Keep in mind that we can only control RAM so we'll probably have to get creative with whatever assets are in the ROM of the game we find an ACE in, and if you re-parse that sentence you'll probably start to get the same feeling of "Wow, that's going to be a lot of work!" but if we can pull it off I think it would be awesome.
Are there any known exploits for 3D consoles that doesn't require a modified save?
LLCoolDave wrote:
This seems to be competing for the "Worst looking TAS of 2011" Award.
1 2 3
7 8