Counterpoints:
http://tasvideos.org/2285M.htmlhttp://tasvideos.org/984M.html
Both of these movies wait at the title screen for over a minute. Your proposed pathing model could not begin to exploit classes of bugs like these because it would almost certainly not model the title screen. The title screen is just an example, but the takeaway point is your model almost certainly cannot reliably be simpler than the entire execution context of the game program.
Sorry, I don't follow. Symbolic execution explores any reachable state, so I'm not sure where your supposed contradiction lies. Symbolic execution degrades to brute force in the worst case, so anything reachable by brute force is reachable by symbolic execution.
You say "model the title screen". I don't know where the idea that we needed to model the game is coming from, maybe I was too terse in my explanation. We model the system (NES, N64, etc.) at a cycle-accurate level and execute arbitrary programs, symbolically. (In practice, everything starts with concrete values and only the inputs are symbolic, and those propagate throughout the system.)
You can do "better" than brute force. The problem with brute force is that it treats the game as a black box, and just kind of tries inputs until the desired end state is reached.
The more practical approach you'd use for automatic TASing would be symbolic execution with model checking. This allows you to turn your input state explosion into path explosion, which is smaller (multiple inputs go through the same path). The reason I put "better" in quotes is because the complexity is still exponential in the number of frames, but the constant factor is smaller.
I've been working on this on and off for some time, but never quite dedicated enough time to it for it to be useful. Maybe I should get back to it...
why didn't you simply message an admin to change the username for you,
i think it's possible ? (as double accounts are forbiden, it should be ? riiighht ? )
as for the site security, until it gets fixed, try to think of it as ridding a bike...
it's fun, but it's safer to walk...
especialy when ducks are involved
Just didn't cross my mind to bug an admin about it. Now that the two accounts already exist, merging them is a pain in the ass. Oh well, it doesn't really matter anyway. As for using them both, I won't. Should someone really care, they can audit my last login times or just ban the old account.
No, I don't use the same password everywhere, though that doesn't really mean plain text handling of a password is okay. (And some people, for worse, do. I don't think it's fair to them to say "you shouldn't have to care the site is insecure" and not care if the site is insecure.)
While I agree hacking tasvideos is probably low on the totem pole, the reason I brought it up is that the perceived quality of site is certainly lessened by the issue, and I would like to help out by just making sure the issue was known. I now know it is and that the site administrators just haven't had the time for it, which is perfectly valid.
(As for why I changed my name anyway, I've been using "GMan" in some variation or another as my moniker for almost 17 years, and it's grown tired to me to the point of being annoying.)
And storing it with reversible encryption is nearly just as bad, and I hope that's what is being done as a minimum currently in order to even make this possible.
My old account was GMan, and I've been meaning to switch to this new one for some time. Having just done so, upon registration my username and password were sent to me in plain text in an email. This is a huge security no-no.
Can we not do this? Perhaps switch to something like OpenId so the site doesn't even have to be in the business of handling passwords, which is notoriously easy to mess up.
Thanks! Even better, perhaps we could retire phpBB, which is now bit-rotten and out of date. A more modern alternative like http://www.discourse.org/ would be swell.
(This is still the same person behind GManNickG; I've been meaning to swap accounts for some time now, and now is a fine time I suppose. I likely won't be using that account any longer.)
Sure, at least the core of it. Someday this will end up on GitHub properly, but as the beginning of a very large project sharing all of it would be pointless and broken. This is the hardest part anyway. :)
https://github.com/NicholasGorski/Scratch/tree/master/n64_arduino
Please read NOTES.md and view the pictures to see the circuit, I haven't diagrammed it yet. The black controller cord is a controller extension cord that I cut in half and spliced with breadboard cables. The tags are just notes on what each wire does (they don't match the usual color schemes).
Getting the data to the Arduino for playback is left as an exercise for the reader. You can stream the data from the computer (note that the Arduino Uno supports up to 1 Mbps on the serial line), but for some games the latency of the communication is too low to keep up. I'm preloading the data to an SD card now.
(As you can see there are various things that may not make sense out of the box, like the DEBUG_PRINT methods; engineering that to work is also an exercise for the reader.)
The assembly is well-commented (IMO), so you should have no trouble following the code itself. Make sure you have your Arduino datasheets handy:
http://www.atmel.com/Images/doc0856.pdfhttp://www.atmel.com/Images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet.pdf
