Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Looking good. I felt this game would make for a nice TAS when libtas came out originally, but at the time I was unable to actually get it to accept input for whatever reason. Regardless, keep it up.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
slamo wrote:
I uploaded the last WIP for my N+ run:
http://tasvideos.org/userfiles/info/66062010127425480
I would like people to try and sync this, it's 32 minutes long and while it's not complete, it should be a pretty good test with the amount of precision the run requires. I put some info about the firmware in the file description.
A bit late, so to speak, but I decided to test the sync on this today. Used bizhawk 2.5.2, a firmware.bin that did not match the same sha-1 (mine was 6679ab9ce99835c1d57d91e27cb979e8c2f1b4e1), and it synced through the entire thing just fine.
I am curious as to how something that would actually use bios features or rely on bios modification mid run for manipulation would actually fare, if such a feature had even been implemented yet.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Quite a solid TAS. I was surprised that so much time was able to be extracted from the previous run. I also agree that those bounces were offensively loud.
My only gripe would be that the puzzle solutions this time around weren't as entertaining as the previous run, more or less because of the ability to use a mouse rather than having to keyboard input it "i'm losing frames anyway so i may as well make it stylish". This is a personal preference/opinion/etc. anyway, as it's inevitable that some people will prefer the faster puzzle solving since it reduces the downtime between the action, so to speak.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Only thing I can suggest is to try recording again from the start, and see if it occurs again. If it was recorded with settings that could possibly be considered desync prone, then a desync occuring when played with different settings is probably unavoidable.
Alternatively, dshawk is in testing if you wanted to try testing that I guess? I don't believe there are any guarantees of it being 100% sync stable, and it also requires firmware, but it's something else that can be considered since it also gives you the ability to use tastudio.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
In theory, you would check 'enable advanced bus-level timing' and uncheck 'use dynamic recompiler'
since it says right there in the picture that the dynamic recompiler should not be assumed to be deterministic.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Selicre wrote:
Since the publishing of the movie is fairly soon, I decided to work some more on the Atlas encode. This time with a dynamic camera that needs a bunch of fixes to make transitions not as jarring.
Link to video
I didn't particularly like the submission because I had no idea what in the blazes of hell was going on, but this on the other hand, is so much better and easier to grasp, even if it is still crazy as hell. Nice job.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
In all honesty, while the run itself was solid, I found the monkey choice (I just hate baby, gongon best monkey) and the goal of real time over per level optimisation to be a questionable one, mostly due to any future changes in emulator loading times (whether it to be more accurate and longer, or more accurate and shorter).
The real question though, is where is the signature monkey ball THUNK whenever you bounce hard and the SNAP of the goal tape? Both are replaced by some weird 'bubbly' sounding effect and I honestly found it extremely off putting.
Weak yes vote.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
So I got around to watching this run last night. Without having a fair understanding of what's actually going on the entire time, to me it just felt somewhat confusing to watch and I couldn't really find it entertaining. The hydra skip was pretty cool, but that alone couldn't save it for me.
I give it a meh, but recommend it for a vault publication.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Dashjump wrote:
Would you mind sharing your WIP if you still have it? I'm still not 100% certain on how to optimise certain stuff, especially the scalpel dotted lines.
Eh, why not. I will give the following advice towards using it, however: don't watch it past the last operation you've completed until you've gave a solid shot at it yourself, so not as to have a preconception that the methods I've used are the fastest that something can be done (three operations in particular come to mind, one being the last I did).
There are still some basic optimisation techniques that I'm not sure are truly optimal.
This is what actually stalled my run, though I wont explain what it was. All that really needs to be said about it is that it would've involved an extremely large amount of trial and error to optimize, and I wasn't willing to both overlook it just to proceed further, nor redo it over and over again until it was as optimal as I could get it.
And the injections - my god, I wanna stay away from them as much as possible. I have absolutely no idea how to fill a syringe to max optimally, I feel that it's 2 frames per tick of the syringe, but sometimes I can only do 3 frames.
Here is an old as hell ram watch list for it, but I couldn't tell you what half of them are for at this point. In the trauma center games things get real weird when it comes to low values on tools/health/etc, and become oddly inaccurate, and I could never be bothered to find out why.
I will be prioritising fastest overall run time, over in-game time, for a similar reason you stated - fastest in-game time would basically mean Healing Touch everywhere to slow down the timer and that seems kinda stupid to me. Depending on the other operations' criteria, I may add on a rule to not use the HT unless necessary.
For operations that don't require any usage of healing at all (ie. early ones), the healing touch is most likely to be slower be a mere fraction as far as realtime goes, but if you have to heal with a syringe at any point in the operation, the time it takes to use the healing touch at the start of the operation instead is far likely to be shorter.
I also don't mind the "good" and "bad", since iirc they only appear at the very beginning and the end of the operation? (the initial incision and the bandage?). Of course, I try to get "cools" over "good" and "bad" where it can be done without wasting time (like extracting the bone fragments in 1-1).
It's a personal preference thing really. I just imagine it as you've got this superhuman doctor working on people, and then he goes and fucks up your initial incisions/post op wound closure. Just feels like a real sloppy copout to me, but eh, as I said personal preference.
Anyway, I'll be posting more WIPs when I can (already solved my SRAM issue), so I'm looking forward to more suggestions and criticisms from everyone :D
If you're also posting movie files that would be nice.
There's also at least one extremely subtle non-operation relevant timesaver you may or may not use or even notice being used in my run past operation 3(?), which is enabling skip mode after an operation to be able to bring the menu up faster.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Dashjump wrote:
I've never TASed a DS game before. This is my first time TASing on DeSmuME, so the quality of the run may be a little sloppy.
For a first attempt, it was really quite solid. it's only .17 seconds slower (ingame timer) than my run that I never finished before our goals diverge (you get a bad on bandage, I heal goo+cool bandaged).
If I do complete this run, I'll make it an any% on Hard difficulty aiming for fastest time, disregarding rank. So far I only have Operation 1-1 to show; I complete it in 9.11 seconds, with a final timer of 4:50.89.
As always, I am of the opinion that such is a bad goal from an entertainment perspective, for a few reasons:
1) "ignoring rank" is the correct choice, because tasing actually makes certain missions basically impossible to XS because you're too good, and can't meet the sub criteria.
2) "fastest time" has the explicit implication that the entire run will be done using the healing touch which, iirc, lasts for 1800 frames (could easily be wrong, it's been 7 years since I last touched it), which is pretty much enough for any mission in the game to be completed with.
3) "fastest time" also shows how bad of a doctor you are by getting all those 'good' and 'bad' ranks.
My personal goal was always "all cool, no healing touch". This, for example, wouldn't be anywhere near as cool if it was done with the healing touch active from the very start.
Regardless of what you go for, keep it up I guess.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
"Bad", the sign of a subpar doctor.
I have the personal opinion that a tas of a trauma center game should be one that doesn't use healing touch outside of mandatory instances, and gets "cool" at every instance possible (getting XS not mandatory simply because you have to artifically prolong a number of operations to meet the XS requirements). Using the healing touch on every operation after you acquire it trivialises the entire TAS, and while getting "Bad" is obviously faster, to me personally it just seems slopping for something that's supposed to be above and beyond.
As far as the actual operation is concerned, it looks fairly what I'd expect (having seen it done before on the DS version), though putting the required ultrasounds in the same spot repeatedly is kind of lame.
Finally, version wise I think playing it on the english version is fine. You can get some funny results with skip enabled, such as "Doctor, wait!" "No." in UTK2 on DS.
Keep up the good work, I guess.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
I just watched the entire video you linked in the first post. While it may be apparent to someone who played the game as to why that path is difficult, as someone who has not, the choice means nothing. I presume there is a lot of behind the scenes manipulation to avoid getting into battles or the like, and there being some absurdly strong enemies on that path and you manipulate them away, but to me the run as a whole was actually pretty uninteresting. Run to point A, collect item. Run to point B, collect item. Repeat for the entire game with no real idea of what's going on until you jump off a building at the end.
If there's a visible difference in difficulty of the path chosen (to the watcher) which makes it incredibly difficult for a regular player to get through, then sure, sacrifice some time to show it being breezed through while noting exactly how much time is lost by choosing that path for that purpose. But as it is, to me there would've been no difference either way because at no point are you under any kind of a visible threat.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
I must say the finished product of the first visit is really solid to watch. I've been watching each individual wip, and while I haven't commented since I didn't really have anything to contribute, but this was worth commenting on for how good it looks alone.
It felt like there was so much that simply wouldn't be possible to do at such a speed on the actual system itself.
Keep up the great work on this run.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Hetfield90 wrote:
I was under the impression that the graphical glitches were fixed as well, although I was not able to fix them myself using feos' instructions. I think Atma also told me on irc at one point that he dumped the AVIs for the encode of one of Bernka's runs, which do not have the glitches.
I did for both actually, since the initial encode for the Grolla tas had some weird graphical issues in one stage which did not occur for me. The graphical glitches in this run are explicitly a result of the video memory setting used, which happens to have an effect on sync. The game won't sync without the setting being as it is, and the graphical errors wont go away without the setting being different.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Much like the other run done by hetfield, this one requires Graphics > Surface Memory to be set to "System Memory" in order to sync. I watched through it just fine, though it has the same minor graphical issues as the other did. Still a really solid run however, easily a yes vote.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
I tried using said XP trial version (though in vmware), still desynced at the same point for me.
I'd say the graphical glitches are related to virtualbox rather than hourglass, as previous encodes did not have that issue or so I recall.
I can't even get rks to start in my main win7, though it already has its own share of problems so they're probably related.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Yes vote for being a solid run with some cool new tricks.
However, I was unable to get it to sync on neither vmware, virtualbox, or even an actual pc running windows xp. It would seem syncability is the key factor for this run.
Experienced Forum User, Published Author, Former player
Joined: 9/1/2005
Posts: 803
Assuming that itsPersonnal was tasing with something around 4r5400, it's not really reliable to do a frame precise desync test due to a frame advance bug introduced in builds beyond 5400 or 5402 that causes it to unpause after 2 frames of frame advancing.
