Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
InfamousKnight wrote:
On the submission page, it says 7:58:17:77 obsolete the 8h04m tas.
But this page claims 8h03m. Whats up with that?
The PSX framerate constant used by movie parser was changed after that this movie was submitted, but before that it was published. The timing displayed in the publication page is correct. A site administrator should be able to fix the timer displayed for the submission page.
Edit: I was reminded that this movie was made with a very old BizHawk version, so in the end the timing is still technically incorrect. Oh well, if we think about it, it's incorrect anyway since we don't use cycle count for calculating the movie length of PSX movies.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
CasualPokePlayer wrote:
ais523 wrote:
At least some Nintendo games for the Game Boy have "delete save" functions that are intended to be used by an end user in some circumstances, and if I remember correctly, they work by overwriting the save RAM entirely with FFs. I think that's evidence that all-FFs is "intended" to be the/a blank state of the save file on Game Boy cartridges, and at least makes it reasonable to use on an emulator.
"some" being "Gen 1 Pokemon"
Yeah, this is my fault, as I incorrectly stated, my judgement note for your Crystal save glitch, that it'd be "most Game Boy games", while from your researches it appears that reality is different. My mistake was making an assumption based on looking only at three examples of games expecting 0xFF, of which two were not even GB/C games (a GBA game and a NES game). Sorry.
CasualPokePlayer wrote:
I've looked at many games to find something to save glitch, and all of them zero out save data and consider that as empty data. Link's Awakening zeros out save data, so does Super Mario Bros. DX, Wario Land 2, Donkey Kong Land 3, some Kirby game, some Pokemon Pinball game, hell even that Devil Island game I referred to. Gen 1 Pokemon is the exception with this as it FFs save data for some reason. Hell they got it right the next gen, which zeros out save data.
This is really interesting, thanks for your contribute! I need to ask you some questions about that:
How hard it was to figure out what each game expects/prefers as an empty state SRAM?
After having looked this much, do you think there could be any game that could be hard to figure out in that regard?
Do you think, at this point, that it would be more accurate and more functional for the GB/C emulators to initialize SRAM as 0x00 bytes, instead than 0xFF?
DankBot Treeview, a linked side script that generates a graphic output, in form of .BMP file, for illustrating some useful botting data, in an elegant and comfortable way. This helps in seeing which parts of the route.lua script may be optimized, by removing unnecessary additional waits or by adding more savestate slots for specific actions.
There are also some minor implementations:
Display the amount of frames wait for each savestate generated, in both text log and graphic view
Introduce ability to set a minimum amount of frames to wait for each action attempt
Make check_freeze() compatible with argument-less functions
Minor improvements of code readability and text log messages
Since GitHub isn't the proper place for deep philosophical reasoning, I wanted to give some more extensive explanations in this forum instead. Specifically: What, and Why?
First of all, here is an example of .BMP file automatically generated by my new script, DankBot Treeview (click for zoom):
Strictly speaking, all the information we can get from looking at this image, we can also get from the text log, which is a feature available from day 0. So you may ask, what's the point? Well, take a quick look from text log generated from the same botting session: https://pastebin.com/5XH3efPv
As you can (not) see, there is a lot of stuff that is really hard to figure out from the text log, which instead can be instantly observed from looking at the graphical equivalent. These include:
Which savestate generated which savestate (hence the Treeview name)
Which road was took for generating the fastest final savestate (smallest framecount or cyclecount)
Which savestates lead to dead ends
How many savestates have been used out of how many slots available
Which is the smallest amount of frame wait for an action
Which is the biggest amount of frame wait for an action
What is the overall amount of frame wait for an action
All right, so we now get to the answer to the bigger question: why, and why colored?
Let me start by telling you that the main goal I've desired to achieve with this project, is having a botting framework that can be not only flexible, but also performing. For this reason, I've figured out as many ways as possible to avoid redundant or less useful iterations for the botting sessions. Additionally, I also developed the ability of resuming a suspended session, so that you don't need to keep your PC working continuously for weeks straight, and live with the fear of power outages. Also, it allows the user to change the route.lua settings without having to restart the session from the beginning. However... It is completely useless if your emulator doesn't support any way for automatically storing persistent savestates (or movie files) by Lua functions. In other words: FCEUX. It was a very ugly discovery for me, since I own a very old pc and FCEUX is much faster than BizHawk. So which choices do I had? The first and most obvious choice was just to give up. The second choice was to go around ranting and whining about FCEUX being bad (and still getting nothing). I didn't like either of these, so I've come out with another idea, yet a very stubborn one: making DankBot even faster. But how do I do that? Well, I soon noticed that by tweaking out the right settings in the route.lua, I can optimize the sessions by excluding more of the useless play routes. The only issue was that it was very complex to figure out, since each situation is completely unique and requires an ad-hoc solution. But I had an idea: what if I could "see" the whole "picture" of a botting session? That would make it much easier to figure out which routes are less useful, and which routes are instead more promising. That way, it's possible to avoid routes that lead to overall slower results, while also be able to focus more on routes that are more likely to make a faster TAS. Which gets to why I've coded it to make the table cells colored. You see, each color shade corresponds to a specific wait amount, from 0 to 51 (beyond 51 is just red), so that allows to quickly see how much hard it is in-game to meet the requirements for that that specific action (example: performing a critical hit while also getting the enemy to miss). Lastly, there is one blue line among the rest of the tree: that indicates the road for fastest final savestate, which is what the resulting TAS will consist of, unless you manage to beat it in subsequent sessions by figuring out better settings for the actions list in the route.lua, which is also something that from today will be easier to do, thank to DankBot Treeview.
TL;DR: Graphical output allows you to make the bot faster while also making a faster TAS. Quoting myself: "we're not optimizing movies anymore, instead we optimize movie optimizers."
Next time I'll bring you some extensive route.lua examples, with proper explanation, so that everyone will be able to figure out themselves how to use DankBot. See you again!
Edit: bad news... when the image gets too big FCEUX runs out of memory, so I'll have to rework a lot of code. On top of that, I also noticed a bug with the tree drawing logic.
Edit: good news, I fixed everything! Get the new version here: https://github.com/ThunderAxe31/DankBot/releases/tag/v3.1 I also updated the example image above. Enjoy!
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
I need more feedback on this one. In particular: how much entertained did you feel from watching this movie? And: do you feel like you'd want to watch it again in the future?
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Memory wrote:
Which values could it have been initialized to that would allow this TAS to work?
I did check again, and I was wrong. The strategies used for this submission do only require two unintialized bits: SRAM domain; bit 6 of byte 0x220, and bit 3 of byte 0x221. The former bit unlocks the ultimate whip, the latter bit unlocks the gauntlet item.
Previously, I incorrectly counted four bits, because I thought that the ultimate whip is unlocked by the three bits of the whip parts, but these are actually used for activating the secret bridge. However, in this submission the bridge is not used, as I warp directly inside the castle island by using the Y coordinate buffering save glitch.
By the way, I'm happy to see that my submission was appreciated, but I have to note that I'm actually in favor of seeing it rejected. As a judge, I think that's important to set a borderline for the fairness of save glitches, and I really think that uninitialized SRAM data is a major no-no. But don't worry! Thanks to the Y buffering glitch I discovered, I can still beat the published run without having to rely on uninitialized SRAM bytes! I'm just waiting for the next BizHawk version to be released, since it will feature a fix for a graphical bug that happens in GBHawk and SubGBHawk during GBC BIOS...
Edit: and here it is, a new TAS that doesn't use the save glitch. It's 26 frames slower than this submission. User movie #65965169748492218Link to videoEdit 2: So, I just did some tests to see how the game handles save data... The game allows for four regular save files, plus the quicksave file. In the main menu, there are five options: new game, load, copy, erase, load quicksave (if present). When you save your game to a save file, the game writes the ASCII string "GETSUFUU" followed by the player data, and it fills the unused bytes of the save file as 0x00. When you use the file erasing option from the main menu, the game will overwrite the save file with 0x00. However, this doesn't apply to the quicksave file, as that can't be selected for erasing... And this submission only used the quicksave.
So, we have a situation where we can tell that the game has been clearly designed to consider empty data as 0x00 bytes, as opposed of the classic 0xFF, however the region of the SRAM used for performing the save glitch can't be erased by using in-game mechanics... So, in my opinion, we still have to come out with our own policy for deciding if allowing uninitialized SRAM data or not.
Edit 3: I just found out that beside the "GETSUFUU" string, the save file also needs to have at least 1 life left, otherwise the game won't consider the save file as existing. So I guess this submission actually relies on a total of 3 uninitialized bits.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Oh, thank you for the temp encode. Even though I'm not familiar with this game at all, I could tell that something crazy was going on. I feel entertained, so I'm placing a Yes vote.
So, this run performs some heavy glitching that allows for skipping much of the game, yet it has no label, like its predecessor. Maybe something like "inventory glitch" would fit?
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
CasualPokePlayer wrote:
Unlock everything fast
In the SRAM, the data about the items unlocked is stored last (SRAM domain, bytes 0x0220-0x0229). So if you turn off the console while saving a new game file, just before the the item data is written, you can have it kept to 0xFF uninitialized bytes, which means that you have all items unlocked, and money and exp maxed. Yay!
That sounds a lot bigger than half of a byte :P
Yeah, but I'm not using the other items in this movie, and the money and exp don't affect the fight either (ultimate whip has a fixed damage).
CasualPokePlayer wrote:
Anyways, I don't think non-save glitch TAS logic should apply. Those TASes may unintentionally desync due to the state of SRAM. Needing an external device to clear SRAM is really just a sad necessary evil for console sync.
However, once we get into save glitch TASes, TASes that inherently exploit the state of save data, that is when abusing uninitialized save data should not be done. In fact... I'm just going to say the Red TAS is already somewhat guilty of this, it technically abused uninitialized save data, its only saving grace is that wiped save data is identical to the technically arbitrary pattern set by the emulator. Even then, I am wondering if that is enough to justify the choice, but I digress.
Yes, that's why I said that I consider your doubt to be valid.
CasualPokePlayer wrote:
Anyways, I'm just going to put a case that I think can display the issues with letting save glitch TASes use uninitialized save data. Let's say there are 2 emulators with different patterns for uninitialized SRAM. One pads it with FFs, the other pads it with 00s. Both these patterns I would argue are perfectly valid for the purpose of establishing "clean" SRAM. Now it gets dicey when these patterns are abused with save corruption. One emulator could have a better pattern for one movie, the other emulator could have a better pattern for another movie. And, I would go as far as saying movies abusing these technically arbitrary patterns the emulator sets should be considered New Game+ (and thus ineligible for Vault). Your TAS actually displays perfectly why it should, you literally unlock everything because the pattern set the emulator effectively matches a New Game+ kind of SRAM. Again, the pattern set by an emulator is effectively arbitrary, a TAS specifically abusing this should not be allowed in my opinion.
I don't consider that as an issue. All we need to do is agree to use one standardized initial state, for fairness. If an emulator uses something different than 0xFF, reject, unless the run is not exploiting that initial data intentionally:
judgment note for #5915 wrote:
There is an emulator bug that causes this game to behave differently from how it should behave regarding SRAM. But this run does not rely on that emulator bug, it just happens to have encountered it. Since virtually all Bizhawk versions have this bug, it's not the author's fault. And even if the new Bizhawk release fixes it, the start of the movie will be different, causing different timings for the entire run, whitch may be impossible to resync without redoing the whole TAS from scratch. Since actual gameplay is still similar to the imaginary bugless version, the run itself is legit.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
CasualPokePlayer wrote:
So does the game have any way to wipe save data/does wiped save data pad SRAM with FF bytes? Wondering about the legitimacy of some of this save corruption.
No, I really don't think this game has that sort pf functionalities.
If you're referring to my judgment note for your Pokemon Red "save glitch" TAS, I've also stated that there are games which are known to affect sync depending on the initial SRAM state, so that cartridges need to be formatted with external devices, in order for their TASes to be played back on console. However, your doubt is still valid, as in this submission we have the substantial difference that the uninitialized data is being specifically exploited for performing a save glitch.
Regardless, I want to note that this submission relies on just 4 uninitialized bits. Not sure where to draw the line, but I think it would be weird to forbid this glitch while still allowing non-glitching TASes that run on games that are much more sensible to uninitialized SRAM bytes.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
I just found another graphical bug with GBHawk and SubGBHawk. The first 11 frames of the GBC BIOS sequence consist in a black screen. I can confirm this behavior is NOT present on any real console: GBC, GBA, GBI.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Why do the tilt controls need to be explicitly set? It's confusing, user-unfriendly. It's not like you can choose to not use them when you play on real hardware, as it's part of the cartridge itself, or decide to use it for other games.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Also, today I made a Lua script that displays on screen a list of currently spawned objects, including candles, pickups, monsters, and pretty much everything else including the player HP bar. Note that new objects can be spawned only when the spawning timer hits a multiple of 8, which this script also displays. Actually, it looks like it's different depending on the kind of object or monster. Some spawn every 4 frames, others every 8, others every 16, and other every 32.
You can download it from here: http://tasvideos.org/userfiles/info/68650558383198335
Edit: script updated.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Mazzin wrote:
ok, you won!
i take back what i said, you actually outsmarted me with this discovery...
if this works the way i think it does then you just hit me in my blind spot, making me look like a dumbfuck after all my "use your brain"-talk, because i litterally had all the clues in my hand but didn't put them together... (provided it does work as i think!).
Please, don't feel discouraged. Even if aruKado is working alone, it still doesn't make it a competition. Everyone has different strong points and weak points, and everyone learns from the discoveries of other TASers.
Mazzin wrote:
could you explain how it works please, because i wanna make sure that im dumb.
I agree that it should be explained. If needed, I can also help with debugging.
Mazzin wrote:
because im not going to screenshot every single screen in the game, that's even longer than just watching a full video...
There is no need to use screenshots, you can use just timestamps or frame numbers.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Why not farming power-ups?
Edit: by any chance, do the shot upgrades make the game lag more? Do they allow to perform more damage to the bosses?
Anycase, I think the net recharges should be farmed anyway.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
RetroEdit wrote:
Just want to weight in here on something related: I think handling of uninitialized RAM should ideally be a sync setting. That way it's documented in the movie file, instead of something floating around in the ether of emulation implementation details.
Though, some uninitialized RAM may be more consistent than others, so maybe my idea isn't fully robust.
Maybe you mean to "report it" inside the header. It's not like we can "set" the emulator to not use uninitialized RAM.
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Mazzin wrote:
btw i don't wanna hurt your feelings again, but i have to get this off my chest:
you seriously lack game knowledge! i can easily tell from looking at the gameplay.
As arukAdo mentioned, it was a "test run", meaning that the purpose was just demonstrating a specific better strategy, and not attempting to make a new improved submssion.
Mazzin wrote:
why is every time such a drama here, i just wanted to enrich your lifes with my work, but instead i kinda feel like i did something wrong when i made my run :(
I think you're the only one that sees it that way. Don't worry, no one is blaming you for making this submission. This is a genuine attempt and as a judge I appreciate it. We all make mistakes, and no one is expecting you to submit a perfect TAS, even though we all work with that intention.
Also, even if a submission ends up rejected, it can still be useful for the site for many reasons, so in many cases it's still appreciated. Our judging system benefits a lot from setting precedents, as these help future judgements and brings new situations to discuss and to figure out. It gives the chance to improve our knowledge and the ability to solve problems. For example, as I wrote in my previous post, I think it's interesting how a more laggy version, while being unavoidably slower, ends up de facto introducing more optimization challenge. I'd like the idea of putting in discussion the definition of how a game version should be chosen.
Mazzin wrote:
i appologise if i accidentally insulted anyone or whatever, i just feel disrespected if my improvements get ignored on purpose even when i showed and even explained how they could be achieved...
All right, it's nice to see that the misunderstanding was cleared. But next time, try to avoid assuming bad intentions from other people, and always ask for making sure.
By the way, sorry for the late reply, I've been much busy lately... I don't want this post to bring back the discussion, I just wanted to share my viewpoint... Let's move on.
Edit: oh, there is another thing that I forgot to say. I also got many rejections myself, but I'm proud of them because they helped the site in a way or another. You can see the list in my personal page: Wiki: ThunderAxe31
Experienced Forum User, Judge, Published Author, Skilled player
(1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Yeah, the category doesn't make much sense for me as well. Hitting the enemies looks cheap, and I feel that avoiding to hit them entirely would result in much more interesting strategies.
Also, how much time would be saved if you killed the enemies?
Strictly speaking, all the information we can get from looking at this image, we can also get from the text log, which is a feature available from day 0. So you may ask, what's the point? Well, take a quick look from text log generated from the same botting session: https://pastebin.com/5XH3efPv
As you can (not) see, there is a lot of stuff that is really hard to figure out from the text log, which instead can be instantly observed from looking at the graphical equivalent. These include:
Thank you so much for doing what I couldn't, great job!