In the forum, when I try to change my login, the site says:
Your password must be no more than 32 characters.
However, even passwords with 32 chars will result this message.
BTW, why only 32 chars?
Presumably because the database has to allocate a fixed amount of memory per password to be able to be remotely efficient, and whoever set up the schema figured "32 ought to be enough for anybody". Using too much makes the database take up more memory per user, which might have been a significant concern when the database was first created (back in, what, 2001?).
As for 31 vs. 32, maybe an off-by-one error in the form validation?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Glitches don't count for "difficulty", and we have plenty of runs that choose specific versions of a game for the glitches they enable. Symphony of the Night is a notable example.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Harmony of Dissonance is fun for frame hunters to pick over, since you move very fast and there's a number of out-of-bounds glitches to toy with. Aria of Sorrow is a highly-polished game and has a number of interesting options for how to play it. Circle of the Moon is comparatively unpolished, has very repetitive level design, and while it's breakable, the results aren't as hilarious as they are in the other games.
So it's understandable that this game doesn't get as many runs. Personally, I'd love to see a "clean" playthrough that doesn't use the "access any card combination" glitch, but there doesn't seem to be much interest.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Regarding the hack: it's a neat concept, and seems to be executed well with the exception of the palettes used for, well, everything. This hack is pretty eye-searing.
Regarding the run: it seemed decently well-optimized. Of course, everything moves so quickly that it's hard to see mistakes without going through in an emulator, which I didn't bother with. I did notice a lot of missed shots, which tends to look sloppy. I'm not counting sections where the TASer spammed shots just for fun, more areas where he shot several times at an enemy and only one bullet hit. Was there any purpose to that? I don't think the RNG can be manipulated by shots in MM3...
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Wouldn't you run into an issue where you need certain enemy formations early in the game, but getting the experience from them ruins your perfect stats?
Once he gets Umaro and/or Gogo, he can use them to advance the formation counter. That may be a bit late though.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Well, follow your bliss, I guess. I'm sure there's people who would watch it.
You're going to have trouble coming up with a good definition for "perfect stats". Grinding every single character up to 99 (including Umaro?) is going to take awhile, too. Are you planning to teach every spell to every character? Figuring out a good grinding strategy is going to pay big time dividends...assuming you care all that much about optimization.
I can't remember if the Esper Ragnarok gives access to items you can't get otherwise. Obviously if you wanted "max" of every item then you'd need it for Metamorph...unless there's some infinite supply of the random-esper battle item that I'm forgetting. Even ignoring that, though, Ragnarok/Illumina are just swords; very nice swords, of course, but there's plenty of other perfectly adequate weapons in the game. The esper is much harder to replace, even if it isn't very useful.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
In this case, the first input (although not obvious?) is the power-on action, if we handpick a valid state of "uninitialized" RAM, wouldn't that be equivalent to powering on the console at "the perfect moment"?
Depending on the exact RAM state wanted, this could range from "merely unlikely" (e.g. you need a single byte to have a specific value, at odds of 1 in 256) to "stretches credulity" (need multiple bytes at odds of 1 in 2^(8 * number of bytes)) to "unlikely to ever happen before the heat death of the universe" (RAM "naturally" contains a boot loader or other moderately complex program). It depends on a) what the RAM state tends to look like naturally, and b) how picky you're being.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Other things that could potentially affect the RAM state on powerup: temperature (and humidity?), proximity to speakers or a CRT (fluctuating magnetic fields), "cleanliness" of power (fluctuation of voltage source), time since last power on (and game played when last powered on)...uh, maybe solder whiskers on the card?
Hell, if you want to be really picky, it's possible for stray radiation from cosmic rays to flip bits in your RAM.
I would still like to see results from someone testing what power-on RAM looks like, as a matter of curiosity at the very least. And it's better to use a "verified" startup RAM state than a wholly-synthetic one. But I don't think we can assume that a single set of measurements from one console in one set of conditions will be representative of all consoles everywhere.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I think maybe Warp should re-read the thread, since he's retreading old ground. Specifically, the "zero out RAM" thing was debunked in adelikat's initial post (it causes some games to break!), and we've already had an extensive argument about what kinds of "set initial state" runs would be acceptable. Meanwhile it looks like there's going to be a project to actually read out what the NES's initial state tends to be, allowing us to have some idea of what setups are actually realistic.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
SoR2 has more varied locations and better music; SoR3 is a more impressive technical achievement. Personally I find SoR2 easier to watch. SoR3 just has too many long corridors filled with far too many enemies.
But honestly they're both great movies; I don't think there will be many complaints regardless of which you choose.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I propose that the problem we have is that we do have to PICK a universe. Up to now, we've been living in a universe outside of our control. And the universe conditions have been decided by emulator coders making semi-arbituary decisions, certainly without thought as to what the ideal scenario is for TASing. We have the power to pick a universe and as such we are in fact picking a univserse. If we decide to stay in the comfortable universe that was given to us, we are still deciding that one over another. So why are we picking on vs another? And what criteria do we pick one? And by what criteria to we deem on to be cheating and not another?
This is definitely a valid point; there's nothing particularly special about the starting state that FCEUX uses. I would be curious to see what a normal NES starting state is like. The emulator has to use something, and it might as well be as plausible as possible.
Regarding publishing such "selected initial conditions" runs under the Demo category, that seems reasonable. I'm having trouble convincing myself that such runs would be valid in other categories. As creaothceann said, it looks like the TASer is "playing a different game" from everyone else.
EDIT: where it enters "cheating" for me is when the gameplay diverges from what normal play would look like due specifically to non-"random" events. That is, if your RNG is seeded from the initial state and you pick a specific initial state solely to get a favorable RNG, that's fine. If you pick an initial state that is unique, or nearly so, in triggering bugs or other game-logic breakdowns, then that's "cheating". If your initial state is sufficiently common that real-life play could occasionally stumble onto those bugs, then we're back out of "cheating". That's why I initially suggested the statistical-impossibility approach, which I grant is very fiddly and ill-defined.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
This is a reasonable suggestion except for that fact that we generally deal in absolutes. When has "how possible" ever been a factor with TAS techniques? We have RNG abuse to the point that the heat death of the universe will happen before a reasonable chance of reproducing the TAS. I am resistant to the idea (not sold against completely) of having to deal with how likely something is. In fact the more unlikely the more fascinating it is to me.
I meant "reproducing" in the TASBot sense, not in the "human gameplay" sense. Absolutely TASing should be about doing superhuman things. However, I'm not convinced that picking and choosing the ideal initial console state is "playing by the rules", so to speak.
The way I see it, TASing occurs within a closed "universe". The universe consists of the console and its input devices, the game, and presumably a display and speakers. The TASer enters into this closed universe after it has been created, and, with perfect knowledge of the state of the universe and perfect timing, manipulates the input devices (possibly including reset, power off, eject, etc.) to achieve their desired goals. Those are "the rules" from my perspective, and I grant that others may feel differently.
It sounds to me like what is being proposed here is generating many different "universes" -- potentially googols or more of them depending on how picky you are -- until you get the one with the desired perfect initial conditions, and only then will you deign to enter the universe and start controlling things "normally".
Don't get me wrong, if you make an entertaining movie then I'll be happy to watch it. I just can't shake the feeling that this kind of thing, except in very limited circumstances, amounts to cheating. If poking the console's memory with a magnetized needle is the only way to realistically be able to replicate the TAS on real hardware, then something has gone wrong somewhere. It's like using a Game Genie.
...in fact, yes, that's the problem here. Functionally you're using a Game Genie to adjust memory to exactly your specifications. The fact that no Game Genie is actually present doesn't change that that's the effect that's being accomplished.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
My general attitude towards this kind of thing is that if your approach could realistically be replicated on the console, then it's legit. So my suggestion is that we create some kind of threshold to decide how realistic a given starting RAM state is. If you require too much initial setup to happen entirely by chance, then your movie is a statistical impossibility and is incredibly unlikely to ever be replicated even by the most accurate TASBot.
For example, we could say that if you need to have more than 32 bits have precise values, then your movie is too demanding. After all, assuming random bit states that's a 1 in 4 billion chance -- if it took you 1 second to attempt each run, you'd be running, on average, for 136 years before you'd get a version that synced.
On the other hand, a run that only required 8 bits to be specific values would need, on average, 256 attempts, which isn't unreasonable.
Of course, if you can achieve the RAM state you want in the game and then reset the console, then you have much better odds of having the specific memory state that you want.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
You could set up an actual database for this, but the use case is so simple that it's probably easier to just have a single file, that'd look something like this:
Your program would load the file, read the first line to get the list of valid tags, then read the following lines to learn which files have which associated tags. In the program you'd build a map of tags to lists of files that have those tags. The user selects the tags they want to filter by, you extract the lists, and then you go through and find all files that are in all of the lists; that's your result.
Alternately, if your language supports a Set datatype, then the tags should map to sets of files instead of lists, and you just intersect all the sets to get the set of files that have all tags.
This is a very simple and limited approach to the problem. If you want to do something more complicated with a GUI and all that, then you certainly can. I'm just trying to point out that the underlying functionality is not that complicated and certainly doesn't require a full-blown database.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Neat post, Kirkq! It's always interesting to hear about formalizing and automating portions of a TAS. You're right, A* is great for this kind of constrained case.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The movie description ought to include something about the glitches being used here. Suggested text:
"This run ignores the vast majority of the game, by using a glitch that allows a party member's experience points to be used as plot items."
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Kinda strange, especially given that the title is "For the World’s Fastest Gamers, Failure Is Just One Bad Jump Away", which means if he were to try to play around a bit and messed up, he'll have to redo that crap all over again.
There's other ways to be entertaining besides playing around in the game itself. In particular, providing commentary makes a big difference in the entertainment value of a run, especially for people who aren't familiar with the game.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I'm not especially familiar with this game; is it possible to drop most of your gold in a pile, then pick up 1GP at a time to give to beggars? Alternately, give away all your gold, sell one small item (perhaps a spell reagent?), give the resulting money away, etc?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Another option you could try would be using the current most-common color as the background color. Obviously this won't work in all situations, but I don't think there is a solution that will work in all cases.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Procyon: for a circular ripple effect, your Z displacement should be based on your distance from the center of the ripple. Something like
z = sin(sqrt((x - cX)^2 + (y - cY)^2) + n / pi)
where x and y are the pixel location and cX/cY are the center of the ripple, and n is the frame number. You might not even need the sqrt; I think that removing it would mean that the ripple density would increase as you get further away, though, which is kind of counterintuitive. Bet it'd look neat though.
Glad to hear you got the performance issues sorted!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
ProcyonSJJ already mentioned they were using display lists earlier on. I think it's just the drawing of thousands of cubes one by one that's causing problems, which is why I suggested using glDrawElements.
Of course, it could also be that some non-drawing aspect of the code is being slow; I guess the question is how slow things are when the game is paused but the view is manipulated.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
When I was in college I took one digital engineering course that had an awful (seriously, the UI was a trainwreck) computer-aided design program for setting up circuits that served a similar purpose.
Out of curiousity, was it MicroCap?
Sorry, I honestly don't remember what it was called.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Looking good! I dig the wave effect; now you need to do a circular ripple. :)
Spheres are gonna be expensive; they have massively more surfaces in them than cubes do. A UV sphere with only 6 circumferences and 6 great circles would have, if I did the math right, 98 tris in it.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
