BBManager issues discussion

I remember here in bbt at some point we discussed the few shortcomings of BBManager, namely the wrong calculations for pass, fireballs and also the incorrect luck factors for natural 6 and 1. I cant seem to find that thread, does anyone know where it was?

 

There's no way he'd consider opening up the source code I guess? Should probably not be that hard to fix given some effort. I'd certainly volunteer for giving it a try, given that it's in some language I'm familiar with (C/C++/C#/Java)

 

I think old threads get archived. I recall i once found an archived thread by using the advanced search function (as i could remember the thread title). Maybe try that?

 

See SuperJC response at the bottom... the admin himself is not aware of the bugs!

http://forum.bbleague.org/showthread.php?t=9984

The pass and fireball ones are fairly straightforward (I ll see if i can do a couple scree captures) but the natural 6 and 1 was a bit less intuitive. That is why I was looking for the discussion about it.

I think I remember the gist of it but any of you knows it better please post it here and I ll respond to SuperJC.

 

The problem with the 1s and 6s is probably not solvable really.

A 1 or a 6 is auto success or failure which means the game does not print the modifications to the agility roll in the log and all you get are the odds of a straight agility roll.

For many agility rolls there is a +1 modifier (catch, pickup ball, dodge) which means that a 2+ roll for elves say looks like a 3+ roll in the logs. Then you have the other cases e.g. when willpower managed to pass out of 4 TZ against me and gets a 6 and it just says 4+ pass or whatever.

Probally no way to fix that unless you assume that all the 1s and 6s come for agility rolls with a +1 modifier (and that is not a real fix either, but might be closer to the truth).

I don't think the 1s and 6s are such a big deal, it is the fireball and pass that is more annoying.

 

Ah yes, cheers guys. Thats right, it was the bloody log. Ok, I ll respond to SuperJC on the other 2 issues then.

 

The problem with that is the RNG, Dreamy. Kvasilad and I (95% Kvasi, admittedly) had a look at replay file/sql and our conclusion was that unless one actually recreates the entire mechanics engine with a completely similar RNG, you will not get enough data to know about dice results and modifiers. So while the method of solving it is 'obvious', actually implementing it is far from it, unless you are a wizard (with a ridiculous amount of spare time) when it comes to decompiling/reverse engineering.

 

Reverse-engineering the RNG is way beyond my skills at least, and I'm guessing that a lot of people have tried without success (after all, the first RNG was indeed reverse-engineered I think?)

However, this particular problem is indeed theoretically solvable using the replay file, but the bad news is that it requires basicallly implementing the entire rulebook. You basically have information on all players, which skills they have, and where they move to at any given time (well it's not that simple, but in theory..)

I did have a go at actually re-creating the game turn-by-turn from the replay file (with simple red and blue dots on a grid), and had some success, but was ultimately stumped by so many implicit events and inconsistent messages. For instance, the replay never mentions such trivial things as "pick-up". It will tell you that a player number N moved from X to Y, and you will have had to track the ball movement yourself (which is a nightmare in and of itself, due to most kick-off calculations being implicit and not mentioned in the replay db), and then check if a player ever moves into a position where you have tracked the ball to be at this time. It will also not tell you if the pick-up was successful or not, but a number of these things can be derived from circumstancial evidence. Any dodges are also implicit, and the replay never states "the dice were rolled", but you can derive this from the game state and the rulebook with considerable effort. Suffice to say, they haven't made it easy.

I still do believe that it is possible to recreate the entire game from a combination of the replay file and the log file, for someone with enough skill, time and motivation. I think I ran out of all three at some point.

 

Well, it wasn't as much reverse-engineered as much as figured out which common algorithm Cyanide were using and managed to identify the seed, which of course is effectively the same, but different

 

They probably used srand() and rand() from the standard C-library, thinking that was a good idea when the random seed is pushed to the replay-db as you're playing

 

I just can't fathom why the heck they would make a replay system that has to generate the rolls anew... It boggles the mind.

 

That is a horrible horrible random number generator.

I think they used a Mersenne twister
Mersenne twister - Wikipedia, the free encyclopedia

which gives much better stuff. if you set up the seed properly.

Well it is much better to store one number than 500+ in the replay file. If you store the seed and know how the generate it (aparently they throw away a number every time you move a square anyway) then it makes the replays smaller.

In that case you just need to store the random seed and store the inputs then you can use the engine to replicate the game.

It does mean that you break replays as soon as you patch the client though.

 

This.

I can see the arguments for it, but it would make for a lot more robust solution if the replay actually contained everything you'd need to re-create the game. I'm positive that a lot of the net desync errors and especially the 12-man/missing man bugs originates from this kind of thinking. The game has some "magic" hard-coded default starting lineup for players, and only if you re-position them all before kick-off, are all the positions of players stored in the actual replay. This is another one of the snags I found while trying to reverse-engineer it.

 

Well, duuuh. I guess I sat myself up for this kind of reply with my last comment

It really isn't better from a security perspective, at least when the replay starts recording to a client side file as soon as the game starts. Storing 500 numbers would also be a minimal overhead compared to all the crap that seems to be stuffed into a replay file (team history, etc). A lot of Cyanide's implementation choices can seem good or at least decent if it weren't for the context they're used in. Makes me wonder if the team just sat down with their separate assignments, hammered in the code and expected it all to work without any kind of higher level coordination.

 

Hey, I take offense to that (even if it's usually true)!

 

It seems Super JC has fixed the Pass stats bug (havent checked it yet to make sure though).

On the Fireball one he says that he has no easy way to assign the rolls to the player who actually threw the fireball but what he has managed to do is to inverse the stat calculation at least showing a "true" luck value for the target player if you know what I mean (so far the stats showed the luck for the other team who threw the fireball).

On the critical 1 and 6, nothing he can do he confirms:

Chaos Edition - BBLeague, Blood Bowl Community