Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
creaothceann wrote:
Maybe the percentage screen could be thought of as the 'ending sequence', and employ "uses death" to reach it more quickly?
I'd prefer to avoid the "Fastest Death" meme as much as possible. :)
I personally don't think showing the shot% is important at all; it's trivial to ensure that it's 100% but doing so prevents showing off the game firing mechanism during recorded input. I can be swayed on this, though. Thanks for your feedback,
A.C.
******
I appreciate the encode! A couple of thoughts have occurred to me after watching this - first, I was expecting the encode to end as soon as the challenge victory fanfare ends at 1:07 in the encode. I noticed that in your encode you allow the game to play through until all player ships are destroyed at which point it shows a % hit. At the beginning of the run I fire a few " calibration" shots to show how quickly two shots can be fired. These four shots might be worth removing (with no effect on the final time) if the encode goes all the way to the game over so the % hit shows 100% instead of 94%, although I'm still inclined to just crop the encode.
Thoughts? Opinions? I don't have any strongly held feelings on the matter. If the response is that people would prefer the game to play out to the game over I can position the ship a bit more to the left on the last frame of input to try and get it destroyed faster. Thanks in advance for feedback,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Would someone be willing to make an encode? I can probably tackle it myself this weekend but I'd rather leave it to the professionals. :)
Thanks,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
This brings back memories, although I'm far more familiar with the Atari 7800 version of Galaga. Definitely worth adding to the vault assuming it's optimal.
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
This was surprisingly entertaining for being in the vault. I enjoyed this and I hope the RRRR path can eventually be perfected and submitted.
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Warp wrote:
Assume that I owned, let's say, an online store where you can buy products, and I would start advertising it here. Maybe it's just me, but I would feel it inappropriate for this website.
That sounds like something that would cross into the realm of commercial sales advertising and I wouldn't find it appropriate either. One-off, personal items relevant to the community don't bother me, though.
Thanks for the clarification,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Warp wrote:
I have mixed feelings about this forum being used for this kind of post...
I am the one that suggested to exileUT on IRC that he might try posting here after he did not hear of anyone who was interested in the games from IRC.
With that disclaimer in mind, I have to say this is exactly the kind of thing that off-topic is for. There is nothing illegal here as these are games he legally owns. His post is not in violation of TASVideo's rules - it's not like he's linking to anything illegal. For being in off-topic, his subject is spot-on for TASVideos patrons (who are likely to be interested in video games and are likely to appreciate the value of the offer).
Warp, you stated you have mixed feelings - is there something specific you're concerned about? Are you worried about setting a particular precedent? Was this offensive to you somehow? If there's a discussion about appropriate content on off-topic I'd definitely encourage you to start a thread about it.
Thanks for your thoughts,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
goldfish wrote:
(lolwtf?)
That was quite possibly one of the strangest interchanges I've ever had about.. er.. melons. And Python classes. But hey, I got the classes to work!
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Enterim wrote:
Wow, now that I've read a 34,000 word text document on not even half of the run so far, I'm pretty excited.
I'm a bit concerned that our submission text will be so long that we'll break the site. I seem to recall some conversation about how if we're too long it'll get rejected, but if we're *really* too long it'll get past the length check and be allowed anyway. I guess we'll see what happens when we submit the run. :)
Thanks for your interest,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
errror1 wrote:
I think this run started about two years ago, I'm glad to see there is still progress, can't wait.
Your comment prompted me to go back to reread this thread and look at when I got involved in the run. Based on the forum posts I made and the file dates from the first script I wrote it looks like I got involved around 2010-08-26. Since then, ais523 and I have been working fairly consistently aside from a few breaks to work around our schedules. Someone in IRC recently asked if we would be done before Christmas, to which I asked "Of which year?" as I couldn't come up with a better qualifier. :) We're still chipping away, moving forward on ensuring the ascention run will actually work, but I wanted to look back at where we've come from framework-wise.
Over time the framework has changed considerably. In the beginning ais523 created a straight Expect script which we then decided to move into Python using pexpect - that worked, but we were effectively writing a pexpect script that played the entire game up to a given point and going further meant extending the script and every execution involved replaying the entire game which we knew wouldn't scale. I came up with a crazy idea in IRC one day and moved on to using a VirtualBox guest OS with snapshots. It was sync-stable and worked well, but our restore time was a bit more than 4 seconds per loadstate. Despite the long snapshot restore times we still managed to get a lot of the run done with this early framework. While ais523 was OK with the speed, I wasn't quite as content so I kept looking for better platforms and eventually settled on KVM.
With KVM, we've gradually introduced various speed improvements such as changing from using the migrate command to create snapshots to using savevm and loadvm with "unsafe" cache files. We've also moved to an entirely read-only filesystem (set to mount as a ro filesystem in fstab) and we're doing everything in /dev/shm on the guest. On the framework side I've tweaked pexpect's send delay to the bare minimum it can function at (note that this might cause problems if anyone tries it on different hardware but it's very stable on our shared TAS system). Changing the send delay significantly sped up the speed of execution of the scripts themselves as it now takes far less time to type characters. Finally, I bumped the pts serial speed from 115200 to 203400 which has shown to be helpful when we're sending a lot of characters to NetHack at once. It now takes about .2 seconds to restore state and we can go through 100 executions of a complicated script in 55 seconds.
On the usability front, the older VirtualBox and KVM implementations used a single pexpect-spawned shell and kept disconnecting from the guest to manipulate the state. I've since gone to spawning two separate shell sessions, one for controlling the state of the VM (which with KVM is done by connecting to a control serial interface, although we could also use something like QMP) and one for viewing the guest. This significantly reduced the amount of "flashing" when loading previous states and made it a lot easier to see the realtime results of scripts, although despite months of searching for a solution I still haven't found a way to get whitespace to align immediately after loading a state (there's always a brief delay before the redisplay completes but by that time the script has already moved on to the next result). In order to combat this I've moved to having a semi-HUD where we print the state of scripted results on the screen and update those in realtime. I've also introduced a tmux session inside the guest to use tmux's redisplay function so the exact state we had when the snapshot was taken is displayed.
This means that as of right now, to watch the current activity taking place on the run (think live TASing) the process involves:
- ./nethack (The actual application we're manipulating)
-> stty (for capturing input inside the guest)
-> tmux (for redisplaying the guest's state)
-> GNU screen (for connecting to the serial pts interface)
-> pexpect (for managing scripts and connecting to the guest)
-> tmux (on the host, for multiplayer commandline action)
-> ssh (from Ilari's machine, driven by a script he wrote)
-> termcast capture (for capturing activity for live TASing)
-> termcast.org (for broadcasting through telnet)
-> telnet (for connecting to termcast.org nethack-tas to view the activity)
If we add any more layers to this onion I think things will get incredibly out of hand. :)
On the code structure front, I've primarily used this project to become familiar with programming in general and get my feet under me with Python. I've come a long way, but I'm still a bit of a novice. One of my initial choices which I'm starting to regret was not moving to an abstraction layer earlier in the project, with the result that we now have dozens of scripts with substantial duplicated code. I've moved toward an initial abstraction layer that separates all NetHack references from the virtual machine guest state management which will allow this framework to be reused for other projects where useful state can be saved inside the guest (other rougelikes, in particular). As an asside, adding tmux in the guest was primarily needed because we were previously relying on sending Ctrl+R directly to NetHack to make NetHack refresh itself but that caused problems when we saved states at command prompts among other things. There's a fair bit of work left to migrate the older scripts (which still work) to the new abstraction layer but the result is far more readable scripts.
The next step in addition to the abstraction layer is to move to a class-based structure. What's crazy about this framework is it's actually possible to have concurrent copies of the KVM guest running. The best way to take advantage of this is to move to using Python classes and creating instances (of the pexpect spawn shell) which can each execute independently. Python itself would still be a single thread but the individual instances of the KVM guest could run on separate cores. My goal of parallel execution of scripts on multiple guests is very optimistic and may not come to fruition as it will require a HUD or some other interface to manage displaying the different guests. It's an exciting enough prospect to at least start moving everything in the current expectKvm.py into a class. I don't actually know what I'm doing here completely so it could be a rocky road but I will give it my best.
That's the state of the framework as it stands now. You can see the current code at http://gitorious.org/nethack-tas-tools and the current TAS state can be observed by telnetting to termcast.org and selecting nethack-tas. Thanks again for everyone's interest in this and by all means please feel free to ask questions,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Derakon wrote:
dwangoAC wrote:
I don't really have a feel for how tight the timing is before turn 2000 comes around.
That's OK, we don't either. :) If we do have free time we'll probably solicit feedback on what to do with it, but at most that'd be a hundred or so turns. We'll see how things turn out with getting the rocks/meatballs/eggs together.
Thanks for your interest,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Derakon wrote:
You should make the entirety of Minetown angry with you...
I don't think we'll be headed to minetown as there's not much there we really need. By NetHack standards, we're being very kind to any monsters we don't care about but we're being ruthless to any monster that stands between us and ascention.
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
hegyak wrote:
Update TurnByTurn please.
So recently ais523 made a substantive update to turnbyturn.txt. We've made a bitmore progress since then but we're holding off on putting it into turn-by-turn as the state we're in may change due to a misbehaving Archon which we need to force a wand on.
By all means, pester us for updates - we need to start posting updates here more frequently anyway. :)
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
In all honesty, my username is a trainwreck. A lot of people have never heard of DWANGO, but in brief it was a dial-up multiplayer gaming service in the 90's. I was a moderator on the Denver server using the username AC based on my initials. When I started registering accounts on various websites the username AC was frequently taken, so I fell back to dwangoAC (the AC from DWANGO) and the name stuck, as has my signature which has been the same since 1992.
Unfortunately, it's nearly impossible to pronounce. :)
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
There was a Red Dwarf episode where everything in the world was going in reverse (kind of like rewinding in a TAS). There's a poor quality capture of it on YouTube:
https://www.youtube.com/watch?v=36xSrKhCojw
If you've never seen it it's worth watching. Also, here's another higher quality portion of the reverse episode, in reverse:
https://www.youtube.com/watch?v=j8jxmkgBgtU
It's not exactly relevant but it's the closest I could get. :)
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
ptorflaxendrosis wrote:
Here's video comparing the non-TAS run with our TAS so far with removed loads so you can get an idea of how much time has been saved so far.
This makes the differences much more obvious - the TAS is clearly ahead. Having said that, I have to give credit to the SDA folks - that 's some pretty impressive playing right there. The fact that you had to make this to prove it, well, proves the point. :)
Thanks for creating this,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
I am a huge fan of infinite savestates. I relied on them heavily for my Otocky run, which would have been impossible without FatRatKnight's MultiTrack2.lua script (which I believe has a new name nowadays). In the case of the NetHack TAS, the framework we're using can have an infinite number of savestates all saved in a sequence with the ability to select any given savestate as the working state to load when the load savestate button is pressed. This allows us to traverse trees of various attempts in a linear list which means it's possible to get "lost" and forget what happened but gives us an immense amount of freedom and control.
I hear BizHawk may have something like that but I haven't looked into it just yet. Needless to say, I'm glad I'm not constrained by only 10 save slots.
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Just to bring things full-circle, I still think this run should be accepted based on the technical merit and the entertaining to read submission text. Furthermore, I nominate this thread for a currently nonexistent "Notable Submission Description" flag.
Thanks for making this,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
AnS wrote:
By the way, what about notable "music-sync" movies? Those where the player dances/shoots to the music in a notable fashion. An icon could be a music note or something.
I am a big fan of this category, assuming Otocky counts... :) I'm clearly biased on this one, however.
For the record, I like ais523's suggestion about the framewar - I know adelikat currently isn't sold on the idea but frame wars tend to generate a lot of viewer interest, usually because of the submission text moreso than the game.
That gives me another flag idea - "Notable Submission Description". Some of us enjoy reading what happened to the game as much or more than we like watching the movie itself and in many cases the submission text is actually more entertaining than the movie. Submission #3187: Bobo the King's NES Where in Time Is Carmen Sandiego is a good example where the movie is as boring as watching paint dry but the description is very entertaining and worth reading.
Just my two cents,
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
I was unfamiliar with this game until I saw this specific run of it. I was entertained by the run because it's a unique take on board-like games. I feel this is entertaining enough to warrant a moon and therefore I nominate it for one.
Of course, I have no idea if a run can even *be* nominated for a Moon, let alone a run that hasn't even been accepted yet. :)
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
I want to see games like this published. I believe the bar for the entire broad category of unlicensed games (including homebrew, hacks, etc.) should be held up to the question "Is this notable?" and if it is it should be allowed to go through the judging process like any other game and be eligible for the vault.
In this case, a viewer can watch the encode and be entertained without having to play the game at all. I think that's very worth publishing because TASVideos can become the go-to place to see what the hype of this meme is without having to go through the trouble of playing it. Yes, I know people who are that lazy. Sometimes I'm one of them. :)
That's my two cents...
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
adelikat wrote:
I really like the gold,silver,bronze suggestion (Kind of wish that had come up before the change).
So how about this:
Gold medal = old star criteria
Silver medal = old moons if they were used with consistency
Bronze medal = current moons
Vault = current vault
(And this system doesn't mean that we couldn't add in a demos type tier at some point.)
I wholeheartedly support this concept - it makes sense to people unfamiliar with the star / moon system and it gives the flexibility the site needs. It's never too late to change course on something like this.
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Baxter wrote:
On the other hand, if a solution to (1) is implemented, where TASes with more ratings get more points, does this not already solve the problem? Vault TASes are bound to get fewer ratings and lower ratings. Both have a significant effect on the player points... do we really need another factor lowering the points for vault movies? You can also wonder why a vault movie that gets the same number of ratings resulting in the same average rating as a non-vault movie deserves less player points.
This is definitely a case where I think it should be kept as simple as possible without causing problems. I personally feel that we probably don't need another factor lowering the points for vault movies, especially when a vault movie is boarderline for crossing into a higher tier.
Either way, the solution should be as simple as possible in my opinion. Thanks for thinking through the options, Baxter!
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Are there any other judges out there who would be willing to take the plunge and install Dolphin? This run deserves being reviewed by a judge. (I also think it deserves being published, but now I'm *definitely* repeating myself and digressing at the same time. :)
A.C.
******
Experienced Forum User, Moderator, Published Author, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
I watched this when it first came out and voted Yes because I found it to be one of the more entertaining FPS TAS's I've seen in a while. It seems like the comments against publication are focused on concerns about possible improvements; while there may be some improvable parts in the driving sections I find the answer to the question "Should this be published?" to definitely be Yes and I look forward to future runs which further improve the time.
Here's hoping this gets published,
A.C.
******
