You are a day too late.
Seriously, though, I have the nagging feeling that raising expectations by making a kind of season-length story arc ("what is in that box?") will only lead to disappointment when what's revealed is something meh. I could perfectly well be wrong (and I hope I will), but I'm not holding my breath.
I just hope they don't repeat the disaster that was season 3 finale. Even a "meh" payoff would be a hundred times better than that.
You can't simply "square both sides". That's not a valid operation (that keeps the equality). You have to multiply both sides by the same number, and you did not do that there.
If you restrict all the reset-button-using and arbitrary-code-executing runs to the paid portion of the site and leave the actually fun runs to the free part, then I'm all for it. You can keep your soft-hacked games for all I care.
Actually the funniest part of all this is that some people really are unsure if this is a joke or not. (Unless they are meta-joking...)
You make good points.
Many people here seem to think that cheat codes are ok if they are executed in a way not intended by the developers, or by abusing a glitch, or even simply in a manner that's "harder" than the intended manner (ie. via a key sequence that has been programmed into the game).
I cannot comprehend the logic behind this. The point is not how easy the cheat code is to execute. The point is what the cheat code does. It doesn't matter how the cheat code is executed.
Abusing cheat codes, or outright "soft-gamesharking" the game via glitches, feels more like circumventing the spirit of the rule, its original purpose. It was interesting the first few times it was achieved, but since it has steadily become more and more frequent as new glitches are being discovered, I have grown a great distaste towards the technique.
This is not to say that we couldn't have them on the site at all. It can be useful to kind of document and archive all the ways that a game can be broken. However, once those start obsoleting the more "genuine" (in a sense) playthroughs, which are then dropped off completely, that's where I personally draw the line. It kills the fun in watching the game being played by a perfect being for me.
It seems that at first Hasbro didn't mind their episodes being distributed, but in the last year or so they have got a lot more protective, for some reason.
Either executive meddling, or they have changed their minds.
In Dragon Quest VII there's a poker mini-game where, when you win something, you can start doubling your winnings. You guess "high" or "low" compared to the previous card, and if you guess right, your winnings are doubled, but if you guess wrong, you lose everything.
The cards come otherwise at random, except that at the beginning of each round the game decides in advance how many times at most you are allowed to guess right. If you get that far, you will lose no matter what you choose (if you choose high, it will deliberately give you a lower card, and vice-versa.)
My idea for an April Fools submission had always been a "true RBO" run that kills MB first, then Ridley, GT, Draygon, Botwoon, Phantoon, Crcomire, Kraid, Spore Spwan, bomb Torizo and finally Ridley on Ceres with the help of Space/Time beam. The problem is that it would be an insane amount of work (probably longer than the 100% run) for a joke submission. Not entirely sure that it's possible to escape after killing MB either but it definitely might be with Space/Time.
Actually if well executed, it could be a genuine publication (at least if we allow yet another branch.)
Warp: Unless one excludes the undead pause trick from the category. The in-game tases are in the moon tier, meaning that people found them to be entertaining. A tas that used the pause trick would probably not be found to be entertaining, and so couldn't obsolete them. The cleanest and simplest solution is therefore to just disallow the pause trick in in-game category TASes. Why would you want to remove entertaining runs?
If the category is "fastest in-game time", then a submission that has a lower in-game time completion ought to obsolete it.
Disallowing some glitches (pause-glitching) while allowing others (arbitrary code execution) is arbitrary, subjective and inconsistent.
(Hey, if it were up to me, both of those would be disallowed. But speaking from a pragmatic point of view, why allow one but not the other?)
To be fair, using C or C++ makes it easier to arrange data in whatever way you want, or access data in ways that managed code doesn't allow (copying 4 bytes from an array by casting char* to int*, that sort of thing). It also helps that, unlike C#, C(++) doesn't pretend that structs are somehow primitive types.
Many high-level languages make a point out of hiding how data is stored, because it's not something the programmer should be concerned about. Although most often true, this does mean it's a lot harder to do things just slightly different from how the language wants you to do it.
You are right in that a lower-level language like C or C++ allows for better space-optimization of data. This kind of optimization is often laborious, difficult or even outright impossible in higher-level languages (with some exceptions, of course.)
While it's not very common (especially nowadays, as speed and RAM has increased and keeps increasing), sometimes it can be beneficial if your data takes as little RAM as possible, ie. it's packed into memory as tightly as is physically possible (even going so far as individual values taking less than one byte of space, ie. you start using bitfields, or "manually" encode your values into less then 8 bits and pack them together into bytes). I have quite a lot of experience at this kind of optimization in C++. Most higher-level languages lack the capacity of this kind of optimization completely (or if it's possible in them, it's often difficult; some exceptions notwithstanding.) Some programming languages are actually horrendously lavish in their memory usage (at least by default.)
(Note, however, that there can be downsides to the tight optimization, and some upsides to the "lavish" approach that many other languages use. The former can often be harder to make work, or be efficient, in a multithreaded program, while the latter often allows for automated multithreading.)
Anyway, my original point still stands: You don't need to know machine code (or even what kind of machine code the compiler is producing) in order to perform these space optimizations.
Vykan12 wrote:
What I don't like are qualifiers like std
For some reason many people detest having to write, or see, the "std::" prefix. However, this is a bad instinct. I can tell from extensive experience that once you start religiously using it, your code actually becomes clearer and easier to read at a glance, than when not using it.
For one, the familiar "std::" prefix allows you to see where standard functions/types are being used from a quick glance. It also more easily distinguishes those standard names from your own names (especially if you use some custom prefixing scheme). There isn't even a theoretical downside to this.
Secondly, the "std::" prefix conveys a surprising amount of information that might not be immediately apparent. For example, suppose that you see in some program a line of code like this:
Language: cpp
if(equal(a, b, c))
What does that tell you? Not much, really. It could be anything. It could be a custom function that compares three values to see if they are all equal. This line also doesn't really tell what the type of those values 'a', 'b' and 'c' are. You'll have to look somewhere else to find that out.
However, assume that the line had been like this instead:
Language: cpp
if(std::equal(a, b, c))
Now this is an entirely different story. With the simple addition of the "std::" prefix we now know a whole lot more about that line of code.
For one, we immediately see that it's a standard function, not a custom function. Even if we didn't know or remember what the function does, we know where to look.
Secondly, if we know what std::equal() does, we understand a lot better what that line is doing: It's comparing two iterator ranges. Which in itself is giving us even more information: 'a', 'b' and 'c' are iterators.
Did the code become more illegible with the addition of "std::"? No! The exact opposite!
An interesting side effect of the pause glitch is that the game clock stops running while Samus health is 0
Btw, this is a good reason why "fastest in-game time" should be removed as a valid branch. Why? Because the "fastest" run would get Samus' health to 0 as fast as possible, and then just use the pause-glitch throughout the run. The run would take ages to complete, but the in-game timer would not advance. Thus it would be a definite word-record... that takes hours and hours to finish.
There are significantly more syllables than in the original song. Also the wrong parts are often stressed. Kind of annoying, really.
Speaking of This Day Aria... http://www.youtube.com/watch?v=v38oWllJj-c
Why are people acting like this TAS being in the Moon tier would be a great injustice and insult that must be corrected as soon as humanly possible?
I'm pretty sure I could find several Mooned TASes that I find ten times more boring than this.
Respectfully, I am curious why this was selected for Moons. It seems like a perfect choice for the Vault. I'd like to hear why it was viewed to be suitable for a different tier.
