Rolling Thunder Forums

So! Here it is! The fruit of countless hours of work. Seriously, waaaaay too much hours. It's far from perfect but I'm sick of working on it alone tbh so I'm getting it out there for you to see & test. Treat this as the alpha release... full of bugs but enough to be getting on with testing. And yes, I need you to test... please....!

Click here ---> http://gandalfgames.net/bbdb/matchlogdisplaytest.php and put the match ID you are interested in into the box. The match ID can be found on the matches page (left hand side) or in your address bar if you are viewing the match.

What would I like you to check?

Open up the BBM match log and compare the two side by side, especially looking out for the following....

• Re-roll status
• Player (should be fine)
• roll type
• roll target
• if there is a question mark after the roll target, it indicates that we aren't 100% sure of the roll target, is this correct?
• Presentation suggestions (please note it will be added to the main match page in the end, the current method of viewing it is for testing only)

Known issues

Rolls that aren't being picked up at all

• Casualty rolls (ie badly hurt, miss next game etc.)
• Bribes
• Kickoff rolls
• Dice bounces - but I intend to not capture these, I don't see the value in them
• Lightening bolts / fireballs from wizards
• Landings from throw team-mates (eg match ID 123 or 142)

Non-roll events I intend to add to the log

• touchdown
• touchback (not sure if this is possible)
• end of turn (together with calculated turn number; I can only guess at it and it will get screwed up if clock gets put back/forward a turn or if a player does nothing)
• end of game
• Player has used a team re-roll and how many are left

Things yet to implement properly

• Working out the right numbers for armour breaks & injuries (inc. modifiers)
• If player has taken root, he cannot follow up blocks
• Grab
• Non block armour blocks need to be split up
• Differentiate passes/catches/interceptions between the ball & a bomb
• Frenzy blocks should show that follow-up was obligatory (except when it's not)
• Loner... I tried but it's gone a bit weird
• I think negative dice roll modifiers are being applied as positive ones, doh
• Star players, mercenaries
• It assumes players' stats and skills are as they are now, not as they were at of the time of the match
• Noting when a skill re-roll is used up, ie the dodge skill can only be used once per turn per player
• The number at the left of the log will be the event number, not the roll number, eg a roll & its re-roll are one event

What is so good about all this, compared to BBM?

BBM uses the log, seemingly in isolation. It reports on the data as-is, without intelligently trying to interpret the data.

I use the log, but link to the players in question too. I also, such as
- Giving the true roll target (example, AG4 player dodge into space is a 2+ roll. The log says 3+ but adds 1 to your dice roll. My way is clearer)

- Get around unknowable rolls, where possible.
If you roll a 1 or a 6, for most rolls the log file does not tell you what you needed to make the roll. BBM makes minimal effort to work out what you actually needed. I try and get around this in two ways.
1) If you reroll it (team or skill), and the second roll is not a 1 or 6, it will have the modifiers in the text, so I can retrospectively apply it to the first roll.
2) Knowing who the player is and what the roll is, we can make a good guess as to what was required. To continue the above example, the AG4 player dodging will be a 2+ if there aren't any tackle zones. So 2+ is our best guess - we cannot know the tackle zones.

- Proper analysis of block rolls
I will give a "expected number of successful blocks" which you can compare against how many of them were actually successful, to show how lucky (or not) you are. Please address any questions regarding this to the analysing block dice rolls thread.
Also it will reflect your true luck - ie if you roll double skulls and then double defender down, you've had worse luck than if you rolled skull/defender down twice. This is not shown in BBM - all you see is that you rolled each dice twice.

- Calculating probability on events, not rolls
This is still to do but the building blocks are in place. I've mentioned this before but I'll do it again here. Consider you try a GFI (2+) and have sure feet (lets you reroll a GFI). If you do this 5 times, rolling a 1 the first time and rerolling it into a 2+, then the 1's you rolled are irrelevant (well apart from the fact you can't use sure feet again that turn for that player). So rather than reporting you succeeded with a 5/6 chance, you actually succeeded with a 35/36 chance. It didn't really matter that half your dice were 1's. BBM will report you had appalling luck, whereas BBDB will report you had ever-so-slightly-higher-than-average luck. This will give better analysis of coach's luck in a game.

And finally for now.... yes this is fairly dull work, but is ESSENTIAL to get right before moving on to the ore fun stuff of working out stats. If the source data for the stats is of poor quality, then the stats themselves will be too.

Please do spend some time helping me out on this. I'e put in > 100 hours on BBDB altogether so if you can spare an hour or two it's not much in the grand scheme of things but will be invaluable to the end result, as well as stopping me going insane from staring at the same bit of code all the time.

With the probability events, and sticking with the example you used because it's relevant, will you be tracking when a skill reroll is used that the odds change? So, as a matter of policy with the Bull Centaurs I will GFI until Sure Feet is used, then I'll often stop as the risk has increased, or carry on at greater risk if needed. So let's say 2 GFIs with Sure Feet

Roll 1 (1/36): 1 reroll 2
Roll 2 (1/6): 2

Does that make sense?

I had the same question as Rav.

Yes, sorry I thought that's what I was saying in the last paragraph of the 2nd post? I'd like to say I'm not being clear but I think actually I was, eg

So rather than reporting you succeeded with a 5/6 chance, you actually succeeded with a 35/36 chance.

There's a job I would rather like that lists "excellent written communicator" as something so if it's the writer at fault rather than the leader, please offer constructive criticism.

Now how does this appear in the BBDB log? If you look at the web page the first thing it says for every roll is the re-roll status, so your roll 1 (actually it's 2 rolls - but 1 "event") will say "skill re-roll used" and then "skill re-roll". If on your first roll you rolled a 2 it would say "skill re-roll available but not used" - at least that is the theory. "Re-roll status" is first on the list of things for people to check, so please do check it.

PS I added a couple more things to the bottom of the first post, that are relevant to implementing this properly. If the lists look long to you then imagine what it was like 2 weeks ago. I really should've written them all down somewhere, as it was they were all flying around my head and getting in the way of normal work/life

In terms of clarity here's how I read your statement:

When you have a reroll skill the actual risk of the event will take this into account.

My question was about after a reroll skill is used, will BBDB know that the odds have changed?

I tied myself in knots trying to explain what I meant so I have sympathy

Oh and because I don't say it enough, thank you for doing all this, it is appreciated!

My question was about after a reroll skill is used, will BBDB know that the odds have changed?

Ah, right, OK, so any communication fail happened after my initial post.

I think this question is covered by the penultimate point on the first post (which I only added 15 minutes ago . So, yes, it will do that, but I don't think it does yet.

Oh and because I don't say it enough, thank you for doing all this, it is appreciated!

To clarify/emphasise,

I'm not doing any more work until people start using this tool & providing feedback. Several people have said in that past that "I would help if I could" - well, here's an opportunity for you.

First question (and apologies if it is a silly one) is - it is a lot shorter than I expected?

It only has the last 90 lines of the match. Is it looking at/displaying just the second log file i.e. 001 not 000?

Also, I realised after a few minutes of reading that I needed to look at BBM too, but I can't access it at work unsurprisingly. I'll try to find time at home but it's a bit scarce at the moment.

lawastooshort wrote:First question (and apologies if it is a silly one) is - it is a lot shorter than I expected?

It only has the last 90 lines of the match. Is it looking at/displaying just the second log file i.e. 001 not 000?

Match ID please

97

ok.... thanks for that. Having looked into it, yes it has only done the first log file. But other matches have done multiple log files just fine. I don't have the functionality to reload them at the stage where it lost 1 of them, so I will work on adding that ability.

Perhaps Rav can confirm if he uploaded both?

Is there the ability to delete a match to reupload it?

How about an admin validation button to verify it's all correct etc.? Say to add the result officially to a league.

Rav did upload them both, the physical file is sat on the webserver, it just didn't make it into the database. I don't think I've ever seen a file not make that jump before so I've never catered for being able to do it again. It's a doable piece of coding though.

There is not the ability to delete a match and I doubt there will be in the medium term. There's too much stuff that is changed to undo it all. As you say, perhaps there should be a "admin verification" option, if an admin does not trust his users much.

Ideally the upload should be self-verifying. In the end I would like the whole thing to happen behind the scenes anyway. So you click "upload" and all it does is upload the physical file which only takes a second or two, and then in the background it processes it into the database (this is what takes all the time). Google "asynchronous processing" if you want to find out more about this approach.

Finally I should add that this week I have 2 evenings & Saturday free, next week it's only 2 evenings and Saturday/Sunday so I don't envisage much coding being done in that time. I need to relax. Some of Feb is looking quieter though. This doesn't mean "don't test until Feb" - issues can be picked up now & worked on later.