tain.totalcodex.net

Long post there ChrisP. I'm surprised to see you also take that stance. "no absolute proof", therefore, abandon all further reasoning.

Basically, as soon as you decide that "game over" doesn't really mean game over, this argument becomes meaningless. Game over doesn't really mean game over, so maybe it means (insert anything you want here).

I'm operating under the basic assumption that when Myth's internal game state is set to game over, then the game has ended. We can tell when it's set to game over because it says so in big letters.

In this particular case, yes you really can see that the score changes after the game is over - see the screenshots linked in the OP. The only way this is not a bug is if you change the definition of game over.

Ah ha! I found some evidence in the source code that should convince everyone beyond a reasonable doubt.

In the code, there are some flags for the game state, accompanied by comments. The important one is here:

_game_is_over_bit, // game is over, no more scoring is possible

So bungie defines game over as "no more scoring is possible". Of course they do, since that's the only reasonable definition, but this proves it for all you doubters.

But wait, there's more. Here's a comment from the section for scoring terries and captures games:

// these games cannot end until all flags are accounted for (neutral and contested flags
// are not counted)
// they also end prematurely if one team captures all the flags

(emphasis mine)

Put those two together, and there's only one conclusion! This is a bug, according to Bungie's original intentions, as specified by their own comments.

So the code comments match Myth's rules with Territories. I still find it hard to believe people couldn't simiply see it as a bug just by knowing the rules of the gametype. The delay for the game to end that gives another team a chance to contest like for LMOTH is not the same thing as the bug in that Terries game. Just like there is a difference between overtime or tie breakers and changing the score after the end of the game.

Basically, as soon as you decide that "game over" doesn't really mean game over, this argument becomes meaningless. Game over doesn't really mean game over, so maybe it means (insert anything you want here).

Of course, but you entirely missed my point as that’s not what we differed on. I'd blame my long posts on the misunderstanding, but I did state my case in the opening sentence of my argument.

My debate was over exactly when the game ended. I'm not suggesting we change the definition of game over, but that the defintion was fuzzy in the first place. All we really had to go by was what the rules state is game over, but with LMOTH as case in point, that's not how Bungie always defined game over.

Most people assumed or felt that it should end in the same instant of 6 flagging, however, game scoring would indicate it ends an instant after. It was never a matter of the score changing after the game is over, but rather whether or not the game really doesn’t end until a tic after six flagging occurs.

Sure, Myrd basically said the game ends at the six flag instant, but he was vague and offered no support to the statement. I trust Myrd, but for I know, he was merely offering an opinion like the rest of us.

You state we can unequivocally tell when the game is over by the flashing “Game Over”. Ok, but logically, I find it hard to believe the flashing occurs in the same tic as the six flag as opposed to a tic later (when the scoring is read).

Unlike the real world, time in Myth is reduced to units of 1/30th of a second, i.e. tics. My understanding is that lots of things may happen simultaneously in a given tic, but you can’t have subsequent events displayed in the same tic - meaning you can’t have both a cause and effect in the same tic. So, for the “game over” message (the effect) to flash in the same tic as the six flagging (the cause) it means either, a) the game is predicting what will happen a tic ahead of time, which is fairly absurd (but would explain all those OOS’s!) or b) the “game over” messaging is operating independently of, and not constrained by tics - which I guess is possible, but seems unlikely. If I am wrong about the assumptions in this paragraph, I would dearly like to know how it really works, but if I am right, it would have only further supported that the official game ending occurs a tic after the six flagging.

Of course, given the code and comment snippets, I have to concede it appears the game does end the same tic as six flagging, though now I'm curious what the LMOTH comments say. But prior to revealing the code, there was no real logic given to support it was definetly a bug, only opinions on what the rules should be. I hardly “abandoned all reasoning” and if “absolute proof“ was called for it is because reason dictates, if something is the way it is (in this case the scoring) one shouldn’t be absolutely certain it is incorrect without objective proof.

Again, I had nothing invested in this argument. I could care less about the tournament results or if the behavior is fixed or not. It was insteresting, but I’d probably have ignored the matter entirely were it not for the “Duh!” reaction given to Archer that made me think, “Hmmm… given the LMOTH inconsistency, I don’t see a reason to be positive it’s a bug.”

Oh, and sorry, Pyro, but I don't see how if the rules for LMOTH clearly state the game ends based upon certain conditions, yet that's not exactly what happens - and it's not a bug, that you can refer to the Terries rules and say "Aha, it's clearly a bug".

CP, "game over" is a variable in the code that Myth sets at a specific point in time (based on various conditions). That's what I was referring to. The final scores were getting collected 1 tick after the "game over" variable was set - which is the bug. This was also not specific to any game type - the same would happen on other game types - and also applies to more than just flag scores. For instance, # of unit kills or damage would also get recorded 1 tick later.

Chris,

I think you're very confused about this. You talk about the definition of game over being "fuzzy", and that "All we really had to go by was what the rules state is game over".

Myth TELLS you when the game is over. This is definition is not fuzzy, it is 100% precise.

You can argue that this should not be the definition of game over, or that we can't know if bungie intended it to be the real definition, but then you're off to la-la land (in a hurry).

If you do trust that the game is over when Myth says it is, then there can be no doubt that this is a bug, even without the evidence from the comments: the score was observed to change after the game ended.

As for your LMOTH example, it is irrelevant because you're not going by the correct definition of game over. Once you use the right definition there is no problem - Myth does not allow the flag to be recontested after the game is over.

A general comment about "absolute" proof - except in math, it often doesn't exist at all, sometimes you have to apply occam's razor otherwise you'll never get anywhere. I can't prove that gravity isn't going to disappear in the next 5 seconds, but that doesn't mean that the possibility is worthy of my consideration.

Ok, I guess I will try to explain this as clearly as I can, CP.

We are not talking about sudden death that happens when time is out and there is still uncontested flags/balls. We are also not talking about the delay before a game ends in which it gives teams a chance to uncontest a captured flag/ball. We are talking about the game recording information after the end of the game. This also has nothing to do with any tournament, but the actual bug. It just happen to be uncovered due to a game played for that tournament.

There are 6 flags on a certain multiplayer map. The gametype is Territories. If there is any uncontested flag, the game CANNOT end. That is part of the rules. No need to look at the code comments to know this. The end score always totals the number of flags the map has. So if the score was 4-2 when a game on that map ended, it would still add up to the 6 flags.

In the game where the glitch occured didn't even run out of time, there were still a few minutes left but it ended. Why? Because one team capatured all the flags. The point is not if it ended (or if it should end) the MOMENT all flags were captured, nor is the point if there were (or should be) a delay before the end to give time for contesting the flag. The end score for that glitched game was 5-0. Do you see there is one flag not accounted for?

The whole point of this thread was not when the game ends or when it should end. The point of all this... was that the data being recorded should happen in the same tick as when it does end. So it isn't changing the rules of ANY gametype. It is just recording the information when the game does end.

Thank you, Myrd. That's exactly what was needed to settle this, a clear, concise explanation that even someone like myself, with only a minimal grasp of programming, can fully understand. That is the kind of proof I was looking for to be totally convinced it is a bug.

Mel, I think you must realize that by absolute proof I didn't really mean it in a philosophical sense, but rather as proof beyond a reasonable doubt. As stated, I accepted the code comments as good enough proof - not nearly as good as Myrd's explanation... but good enough. Other than that, you still haven't stated anything convincing.

Myth TELLS you when the game is over. This is definition is not fuzzy, it is 100% precise.

I still don't know what the heck you mean by that, so it's pretty fuzzy to me. Does Myth whisper it in your ear, or what? Does it tell me too... or just certain people? If you still mean the flashing message or announcer voice, then I'll state again, I have my doubts those events can occur in the same tic as the six-flagging, and if they occur one tic later then it does nothing to support your argument. Did you eyeball the film and precisely determine the order of events down to the 30th of a second? If you have some better way of analyzing it, you should probably explain your method and save us both a lot of trouble.

Anyway, Mel, please don't take offense and I'm sorry if I seem exasperatingly dense to you. It's not that I didn't believe you - and I am sure you are far more knowledgeable about how the game works than I am - it's just that for whatever reasons, I couldn't understand how you came to your conclusions.

The end score for that glitched game was 5-0. Do you see there is one flag not accounted for?

Pyro, my apologies. I started by merely browsing this thread and was not paying enough attention to realize the score was 5-0 and not 5-1 as I had wrongly assumed. The scoring discrepancy would have been enough to make me think something had to be amiss and there was a bug. However, by the time I posted, the debate was indeed about determining the exact moment when the game ended. Basketball analogies were being offered as why one view or the other was either right or wrong, and at this rather logically thin juncture is when I stepped into the fray.

The whole point of this thread was not when the game ends or when it should end. The point of all this... was that the data being recorded should happen in the same tick as when it does end.

Well, ok, yes, but the thing is, you must have a definition of when the game ends or how else do you know what tic the data should be recorded on? Thus determining the exact moment of game end has been vital to a mutual understanding. Even considering the scoring error, no one was able to describe a convincing enough reason for why the game end should be one tic sooner or later. Myrd finally did, and Mel kind of did too with the code comments, and finally you did too by basically making the link to scoring impossibilities, but up to that point, it was mostly "I can't believe you don't understand...", basketball buzzers, and circular arguments of how the game ends when it ends when the game ends and not after the game ends.

Considering the furor over that match, Project Magma's delicate position with that crowd, and that an expert opinion was asked of Project Magma to help settle the matter - or heck, even just out of respect to Archer and his doubts - perhaps a clearer explanation was due, or at least a slightly less condescending tone.

ChrisP wrote:

Myth TELLS you when the game is over. This is definition is not fuzzy, it is 100% precise.

I still don't know what the heck you mean by that, so it's pretty fuzzy to me. Does Myth whisper it in your ear, or what? Does it tell me too... or just certain people? If you still mean the flashing message or announcer voice, then I'll state again, I have my doubts those events can occur in the same tic as the six-flagging, and if they occur one tic later then it does nothing to support your argument. Did you eyeball the film and precisely determine the order of events down to the 30th of a second? If you have some better way of analyzing it, you should probably explain your method and save us both a lot of trouble. ;)

I said this before but maybe you missed it. Did you look at the screenshots linked in the OP?

One screenshot shows the score right after tagging (6-0). Notice that says "GAME OVER". That's how you can tell that the game is over.

The other screenshot shows the score some time later. The score has changed.

For the purposes of this argument, It doesn't matter how much time has elapsed between them or if the 6-flagging occurred in the exact tick as the screenshot or not. All that matters is we have observed the score changing after the game ended, therefore, it's a bug.

EDIT: let me just note that this variable that Myrd mentioned is exactly equivelant to the "GAME OVER" message being printed (which I believe I've mentioned that in almost every one of my posts). That message is printed if and only if the variable is set. I would never have guessed that talking about the variable would be more convincing to a non programmer. Still, I hope that I've shown that you can come to the same conclusion without knowledge of the inner workings.

Myrd wrote:...This was also not specific to any game type - the same would happen on other game types - and also applies to more than just flag scores. For instance, # of unit kills or damage would also get recorded 1 tick later.

Excuse me, I have to go rank h00r some BC games.

w00t! I HAF SEKRT NFO!

ps. Having an extra tick is a great advantage, but it really relies on awfully precise timing - Is there any way in the next version of Myth II we could increase the # of ticks the game waits after game end to count up the score? Maybe make it configurable in a poweruser parameter file so a host can decide how many seconds after game ends the score will be counted?

The best thing in these cases is to make your soldiers taunt so that other people think that you won.

ChrisP wrote:Considering the furor over that match, Project Magma's delicate position with that crowd, and that an expert opinion was asked of Project Magma to help settle the matter - or heck, even just out of respect to Archer and his doubts - perhaps a clearer explanation was due, or at least a slightly less condescending tone.

Look, I'm sorry if I sounded condescending. It just seemed like you and Archer didn't know what was being discussed. Or rather ignoring or overlooking certain things being said or shown with screenshots and the actual film. People can say they don't know when the game ends all they want, but we know it ends right? I am no programmer, and I didn't need one to tell me that this issue was a bug. If people actually saw the film, maybe they wouldn't be so doubtful as to the definition of the ending of the game.

All flags are captured... the Game Over text shows up. If the game was not really over why would that show up? Can the game predict when it ends? Maybe it shows up after the end or on it... but for sure it can't show up before the end. We don't have to know when exactly the game ends to know that it ends and to know the score should not be 5-0.

ChrisP wrote:Myrd finally did, and Mel kind of did too with the code comments, and finally you did too by basically making the link to scoring impossibilities, but up to that point, it was mostly "I can't believe you don't understand...", basketball buzzers, and circular arguments of how the game ends when it ends when the game ends and not after the game ends.

No, up to that point we just assumed you understood the issue (the 5-0 score). All that was done was repeat what was said before using different words. When Myrd said the data was being recorded one tick after the end of the game, that was enough for me to understand why the score was not right. While we as players may not know the exact moment the game ends, the game would have to end... the engine knows when it ends. So if a programmer says the data is being recorded after the end instead of on the end. That was more than enough.

Crispys just having trouble because WoW doesnt have an edgame screen is all.

He will learn the myth rules again someday.

Sorry, for the delay in replying, and more importantly, my apologies for the misunderstanding. I did initially click the link to the mwc forums, but at that point I was more interested in how much of a fuss was generated than the actual mechanics of the bug. A glance at how many pages had been written told me all I needed to know in that regard, and I only returned to this thread after a debate had spawned.

Embarrassingly, Deqlyn is partly right - as I've only really been playing Mazz betas since my return to Myth, I'd forgotten that the multiplayer score is displayed during the end of the game, and not just in the post game lobby. That's a key element, which had I returned to look at the screen shots, would have hastened my understanding and kept me from wasting everyone's time.

So, what I was picturing based upon Myrd's initial post was this:

Tic#1 6-flagging occurs.
Tic#2 Score is recorded based upon the current game state which is now different than in Tic#1.
Later, Post Game lobby displays score of 5-1... er, 5-0.

Essentially, I thought Mel and Pyro's position was that the score should have been recorded based upon the state of Tic#1, not #2, because the game ending event occurs in Tic#1. This seemed to me more a matter of opinion, which is why I wanted something in the code to support it being a bug.

What actually happens is probably more like this:

Tic#1 6-flagging occurs
Tic#2 Score and Game Over are displayed together.
Tic#3 Score is re-recorded, changed and re-displayed, based upon the game state in a subsequent tic.

If someone here mentioned that the score was displayed twice with differing results, I missed that too. Myrd's first post only mentions the score being read once, but it'd have to be twice - since it's displayed twice. You guys are right, in this case it doesn't really matter the exact tic the game ended; the obvious bug is that the game itself can't seem to make up its mind when it's over.

Yes, I guess I should have went back and researched the whole thing from the beginning before adding my two cents and sounding like an idiot, but in my humble defense, when I chimed in, I was casually replying to the most recent posts, which had turned the subject to theories of when the game should end - so I assumed that was the critical element upon which the matter hinged. Anyway, sorry!

I didn't read all the super long posts but I can confirm I have seen the equivalent bug occur on other gametypes throughout the years, most notably on LMotH where the game will end due to the flag being held uncontested for the required amount of time but someone contesting right as "game over" pops up. The game ends but the F7 scoring shows a check mark (signifying possession by two teams, aka contested flag) next to two names. If the flag was contested before time ran out then the game would not end. I believe that the perm scoring still scores the game correctly in that situation though.

The basketball equivalent of this bug is someone shooting the ball right after the buzzer sounded and the points changing on the scoreboard to show the score as tied even though they shouldn't count and the game was over before the shot. If the shot had occurred before the game was over the game would continue, just like the myth game. It's basically a scoreboard error, the game is rightfully over according to the rules but the scoreboard is displaying the wrong score.