Flash (and Ruffle) are able to retain the state of the game progression, and save the current progress.
Refresh is abused to skip every single ending shown making it quicker to basically reset the game and "Load Save" in a sense.
That's not good.
Mainly cause if this is a modified file from the version available on Newgrounds then we need to know what elements were removed (if any) from the srcom version.
Especially if this will follow the repeat issues of previously submitted Newgrounds TASes.
This is more of a Staff question.
Even though as a standalone this is called "Fleeing the Complex" is it more fair to call it by the full title of Henry Stickmin 5: Fleeing the Complex?
I've never seen Klonoa so angry until now, ok, i'll see if newgrounds version of this game can sync this TAS.
It syncs on ungrounded/newgrounds version of the game with MD5 hash of 542945bd96db65ed95833dba88a35339 named 665992_complex.swf
User movie #638041879886997201Link to video
That's not good.
Mainly cause if this is a modified file from the version available on Newgrounds then we need to know what elements were removed (if any) from the srcom version.
Especially if this will follow the repeat issues of previously submitted Newgrounds TASes.
This is more of a Staff question.
Even though as a standalone this is called "Fleeing the Complex" is it more fair to call it by the full title of Henry Stickmin 5: Fleeing the Complex?
I've never seen Klonoa so angry until now, ok, i'll see if newgrounds version of this game can sync this TAS.
There's probably a possible improvement by finishing Presumed Dead as the last ending instead of it being the first, i'll test this tomorrow at night from my timezone.
Also having sync issues. I went ahead and created my own test movie file, and that file has no issues playing for me. So I started doing some digging into the movie file to see if I could diagnose the issue.
The file on the left is TheRandomMaster's movie file. The one on the right is my test file. The blue and the red color coding is used to separate data into the frames they are relevant to. The area I have highlighted is frame 46 of both of our movie files. The short and simple of it is that each red chunk and each blue chunk should be identical in size and position between the two files. However, frame 46 in my movie file is 7 bytes longer than frame 46 in TheRandomMaster's. The reason for this is because my movie started recording data for accelerometer inputs slightly before TheRandomMaster's movie. I have no idea why this is happening. By inserting 02 00 00 00 FE 00 00 at 0x0AD8 (the accelerometer data Citra is polling for at this time in the movie file), I fix the desync and the TAS plays just fine. I have confirmed sync with this fix.
I have uploaded the fixed movie to my user files: User movie #638023496031275421
Synced on Nightly 1800 from Public Computer with benstephens1000's movie TAS fix was the last resort.
I can verify the movie syncs on the nightly build 1800.
It's important to note that you need to delete the save data before running the movie, Citra seems to not have any flags that tell the emulator not to use sram, so it'll initially desync because of that.
For me, besides of nightly 1800, the movie also syncs on canary 2306.
Gamecube games:
Super Mario Sunshine
Mario Kart: Double Dash
Paper Mario: The Thousand-Year Door
Mario Party 4-5-6-7
Wii games:
Super Mario Galaxy 1-2
Mario Kart WII
Wii Sports
Wii Sports Resorted
Wii Fit
Wii Fit Plus
Wii Play
Wii Party
The Homebrew Channel (For expermients)
Gecko (For expermients)
Animal Crossing: City Folk
New Super Mario Bros Wii
Mario Party 8-9
The biggest unfortunate is that we'll never see publication of both old Cheat% TAS and new Cheat% TAS on TASVideos.org because these Cheat codes are used to unlock power-ups and access to final boss and therefore not allowed since Cheat codes and passwords are only allowed to access harder difficulties and/or bonus content, including cosmetic improvements.
In-game codes that add gameplay are allowed for Standard (2022-07-14)In-game codes that add gameplay are allowed for a separate branch, as long as such codes are used optimally. Codes that modify or disable in-game mechanics are not allowed, unless they unlock an in-game item or a skill that does that.
All new Cheat% TAS dropping this Thursday, Oct 13th, most optimized TAS of BfBB by wide margin. Sub minute end-time if loads times are converted to Xbox length (TAS was made on Gamecube emu because better tools, despite slower loads). Stay tuned...
The biggest unfortunate is that we'll never see publication of both old Cheat% TAS and new Cheat% TAS on TASVideos.org because these Cheat codes are used to unlock power-ups and access to final boss and therefore not allowed since Cheat codes and passwords are only allowed to access harder difficulties and/or bonus content, including cosmetic improvements.
Mizumaririn's SM3DW TAS
Credits to that Someone that i don't know the name.
I can remove it if you want.
Link to video
The video above will be changed to youtube once streamable automatically deletes the video for 90 days inactivity.
There's no such improvement, I think it's maxed in term of TAS timing due to this game being extremely shorter even optimized position wouldn't do the thing, i give up...
(lost streak of becoming co-author on some simple flash games)
Sorry EZGames69, i can't get it to sync because of Error dispatching event EventObject(EventObject { type: "click", class: flash.events::MouseEvent, ptr: 0x5621e5013d70 }) to handler FunctionObject(FunctionObject(GcCell(Gc { ptr: 0x5621e5035278 }))) : "Resolved parameter type flash.net::URLVariables is unresolvable, not a class, null, or undefined"
The md5 hash of 432872_Spoiler.swf is 82fb82289425058a3be17e0647b36ec5 and for ruffle is 7afa2473a2476cb19722eb48a0d74e35
Dolphin on my PC was nearly finishing the TAS playback around 80000 to 100000 input frames when suddenly a blue screen of death appeared with error code: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
Since this TAS playback saves many times on a memory card.
After the BSOD, my PC rebooted then i loaded the memory card where the TAS playback saves and this is what i got.
Lobsterzelda wrote:
TheAmazingAladdin wrote:
Rendering Error?
You’d think so, but this is actually what it looks like on console as well! This area loads as rainbow boxes due to us getting the camera out-of-bounds in the previous area, which causes the game to fail to load objects in the next map. The same thing happens to speedrunners of the game (the game is programmed to use rainbow boxes as a default placeholder when it fails to load an object).
The file on the left is TheRandomMaster's movie file. The one on the right is my test file. The blue and the red color coding is used to separate data into the frames they are relevant to. The area I have highlighted is frame 46 of both of our movie files. The short and simple of it is that each red chunk and each blue chunk should be identical in size and position between the two files. However, frame 46 in my movie file is 7 bytes longer than frame 46 in TheRandomMaster's. The reason for this is because my movie started recording data for accelerometer inputs slightly before TheRandomMaster's movie. I have no idea why this is happening. By inserting 02 00 00 00 FE 00 00 at 0x0AD8 (the accelerometer data Citra is polling for at this time in the movie file), I fix the desync and the TAS plays just fine. I have confirmed sync with this fix. I have uploaded the fixed movie to my user files: User movie #638023496031275421
