Some guy on reddit asked about TAS'ing a Flash game. In the past I have tried scripts which wait on specific pixels, but that isn't a real TAS since its frames are not at exact times.
You could go the simulation road by creating a wrapper which swaps out RAM for a program that runs the Flash container. But there might be a cleaner solution.
It is possible to decompile .swf files and be able to edit them. Afterwards some code for TAS tools can be copied in and perfect frame-by-frame inputs will work nicely. Maybe this can even be applied as a patch. I don't know how savestates would work though, so that may be a point of discussion.
The advantage of this method is that it would open up Flash games for perfect TAS'es. What do you guys think? Would it even work?
No I don't think IWBTG would be a dull TAS, there are indeed many things one could do for entertainment. And many parts that could be optimized far beyond human possibilities.
subanark wrote:
I would vote for simply allowing a bot that controls the input (and can decide when to input the keys) to be acceptable as part of the run. Such bot might be limited to having to input the exact same sequence each time, but simply decides when to input the next key (based on memory analysis). This would be subjective, and would require a level of technical skill from the TASer, but I'm sure in most cases someone can justify why their better run is in fact better.
I have actually made something like this. But not by memory watching, but by watching the screen. Basically it holds a certain key to move, until a pixel turns a certain color, on which it hops to the next step. It was quite a long-dreaded script, but it could easily be written to a input-file, compressing all required data for the script.
I managed to clear a few screens using this technique, I haven't had it desync once. You can see it on youtube.com/cxgamer, sorry I can't link to the video, as my school network blocks it (no proxies, no vm's either).
Though obviously I wouldn't vote this being allowed, as this can't be a long-term solution.
I wish I had the programming skills to contribute to this awesome project, I'm learning as fast as I can. :P
It wasn't that much entertaining to me. Though that may not be your fault. TAS's tend to go too fast for explaining each trick, like the fast pole climbing wasn't even mentioned. I would like to hear more details about it.
However I like to hear the things such as that you can go to that place in mario kart, or that the 2nd boss fight is the only one that has lava.
Maybe you could add more on developpment of the run?
I offered to volunteer some CPU time to brute-force seeds
If more brute-forcing is required, maybe I could help?
I'm offering CPU time on an intel i7, liquid-cooled and 6 Gb RAM.
Though I don't really know much about emulating DOS and thus would require help on teamviewer. But I would love to help. :)
I've read that the RNG is affected by the time passed since january 1st 1970, so should a tas start at that time?
Also, if the RNG is so hard to manipulate, you should consider a brute-force script to test all possible solutions for a given outcome. I have a above-average rig, so if you guys ever need to run some complex calculations, don't be afraid to ask. :)
And I agree with you, realTime would be the way to go. :)
I'm going to download this game to check it out. Or at least try.
Hi, can anyone explain what stuffed bones are, and why they won't be allowed, please?
Thank you.
EDIT:
Whether using the contents of a deceased player's bones is ethical is left to the player to decide. Bones can often make a difficult game much easier by providing items that the current player has not "earned" yet.
Finding one's own bones is an even more difficult position. Luckily on a public server there are enough players that this is unlikely to happen too frequently.
EDIT2: This one is clearer;
Bones stuffing consists of playing a game for the express purpose of gathering useful items (up to and including a full ascension kit) and then deliberately committing suicide with the intention of leaving a bones pile for another character to exploit in some pre-designed manner. Sometimes the practice is taken to such extremes that the true identities of randomized items are engraved on the floor to aid subsequent characters.
Bones stuffing is not considered bug exploitation and technically speaking is within the rules of the game, but most regard it as violating the spirit of the game. For example, a pacifist character who ascends using an ascension kit obtained via bones stuffing would not generally be considered to have ascended legitimately.
It is important to observe that under normal circumstances, encountering and exploiting bones piles is a legitimate action, even in borderline cases such as bones piles containing full ascension kits. The difference is that bones stuffing involves deliberate suicide of a character, whereas a normal bones pile is a result of an honest (albeit failed) attempt to survive.
Bones stuffing on a multi-user system is risky, as it is possible that another player will get the benefit of your bones pile.
I once did a part of a game with macro's, it used pixel-color detection against desync. It's more like a lot of checkpoints than a frame-perfect sync.
But it worked smoothly. :)
I tried that.. Well not a real tas, but a script..
It uses pixel-color detection to know where the guy is at each given time. I made this video as proof that it's possible, however it would take a lot of work; which it's not worth to me..
http://www.youtube.com/watch?v=G98KqfYVqP4
The code for this simple vid was:
There was a level in Yoshi's island, (something with morph) that I could hardly complete as a kid. :D
I've played I Wanna Be The Guy on Very Hard, nothing seems hard to me anymore. :P
There's two other problems I encountered, with Portal specifically. One, the game runs at 300 frames per second. (Was it 300? I forget, but something really high like that.) Portal's camera works like this: where your mouse is pointing, you turn and look. This would, using frame advance only, create the most spastic camera work ever, with 300 crazy camera movements per second. Because during framestep you can't hold down the button, you can't create smooth movement, and the end movie would most likely cause anyone to throw up from motion sickness. Like this.
When standing still (so the direction of movement doesn't matter), could a script be made to move the mouse between two points when waiting for the gun to reload?