jcwren

Turn auto-update off! That s**t is first-order evil.

Other way around. Paper always wins. Not rock, not scissors, not spock, not lizard, not electronic copies.

You probably only knew about it from randomly tapping on the screen. I only push the labeled buttons

iOS 8 also broke printing from within PractiScore.

Yep. In my book, you'd be nuts to run without paper backup. While there are measures that may be taken to protect the data, you must remember that not every competitor has a cell phone, much less a smart phone. People I talk to like the emails, but most still want the paper. It's cheap insurance, it's time proven, and if I absolutely HAD to, I could score a match using Excel and the white sheets. Don't *want* to, but I could. What I still want are low-cost stage printers. Print a thermal strip for you and one for me. No manual copying, no transcription errors, you have your paper copy, and I have mine (which, incidentally, has YOUR signature agreeing that the COF has been correctly scored).

I know I didn't. And I thought I knew just about everything you could do with it

PractiScore *does* work under it, but I'm seeing issues with syncing, mostly in device discovery. It's very slow to discover other iOS devices, and often doesn't see the Android devices al all (it uses two different techniques to locate devices). Sometimes devices don't appear at all, and other times the full list will populate. If you enter the sync code, it will usually find it and sync. So something's definitely a little squirrely. As far as scoring a match and such, I haven't seen anything that's a show stopper. All the screens appear to work correctly, the keyboard appears and dismisses when it should (some apps appear to never dismiss the keyboard). Short form: If you haven't updated, don't. If you have, you're not totally screwed, just inconvenienced.

There's more to it than that. The first and last name columns are reversed. The fields are unquoted, so if you have a competitor with a comma in their name, it will break ("John Smith, Jr"). Again, this is the current iOS release. I haven't checked this with Android 1.2.19.

If you're using the Android version, you can bring squadding information over (assuming it works. Unfortunately, I know it's broken in the iOS version, at the moment. When you export the stages and scores, there will be a file named 'squadding_export.txt' (or something to that effect) in the .zip file. Going to the Online Squadding tab in the Match->Registration section, you can import that file and your squads will come across. If you're just posting results, you don't need to do this, but it is doable. The iOS version will be fixed in the next release.

So because I've got nothing better to do right now, if you add the following snippet in ActivityModifyShooter.java, ActivityScoresShootersList.java, or ActivityShooterList.java, does it work then? This would also fix the scrolling in the change log (tapping the version number on the main screen), which also suffers from the scrolling issue. This should go after the wv.setLayoutParams() call. wv.setOnKeyDownListener (new View.OnKeyListener () { @override public boolean onKey (View v, int keyCode, KeyEvent event) { if (event == KeyEvent.ACTION_DOWN) { if (keyCode == 92 || keyCode == 94) { this.v.scrollBy (0, -200); return true; } if (keyCode == 93 || keyCode == 95) { this.v.scrollBy (0, 200); return true; } } return super.onKey (v, keyCode, event); }); PS: I take "can't" as a challenge.

Anything could be built in, but everything takes time. Given that it is only relevant to one device (which is already discontinued) and I will have to spend 5..6 hours banging my head off the wall trying to hack something for this issue on Nook only and without guaranteed result... I'd say there are issues with higher priority at the moment. You've already got the code for this in com/niftybytes/practiscore/ActivityMatchResults.java: public boolean onKeyDown(int keyCode, KeyEvent event) { if (keyCode == 92 || keyCode == 94) { this.webview.scrollBy(0, -200); return true; } else if (keyCode != 93 && keyCode != 95) { return super.onKeyDown(keyCode, event); } else { this.webview.scrollBy(0, 200); return true; } } In com/niftybytes/practiscore/ActivityScoresShootersList.java, override the onKeyDown() method for the WebView class with that same code, and the side buttons will work.

Something else to consider is that if you created your match in EzWinScore, OR your competitors all had EzWinScore numbers assigned already, the -1's are going to occur at the end. On the "Enter/Edit Shooters" screen, if you set the sort order to "None", it SHOULD be your most recently added competitors that will have an EZWS number of -1. These are usually caused by some fool using "Add Walk-on" instead "Move Shooter To Squad", or, in the case of Area 6, "Well, we couldn't find them in the NOOK, so we added them." 3 FREAKIN' TIMES!

It is a pull. But like I said, if someone used the 'Move To Squad' button, that can cause a change warning. I too wish the device could be locked into a "Score Only This Stage" mode (device stays on stage), or a "Score Only This Squad" (device follows squad). Probably has to be some way to handle a shoot-thru, which maybe is handled by mode 3, "Scoring Only". About the only thing I *might* consider allowing is 'Move Shooter To Squad', and that's iffy. It is very frustrating to know that something has been changed, and that it's kind enough to warn you, but won't tell you WHAT changed. To understand how this works, the match data is basically divided into two groups, "match definition", which contains the match type, date, shooters and stage definitions, and the "scores", which is purely the scores. While it should be possible to sync scores without being concerned that a SHOOTER has changed, if something in the match stages has changed, it MAY be necessary to sync the stage(s) before the scores, because otherwise the scores won't be correct. In supporting that, you've made the system more complex (be it a little or a lot, it's still MORE complex), and knowing when it's proper or not to accept changes. The whole merge process is somewhat complex internally. For instance, it's not just the shooter record that has a timestamp, but about half a dozen fields inside the shooter record have timestamps. DQs, squad number, division, power factor and a couple others all have their own timestamps, and those can change without affecting the "shooter profile", which is their name, country, sex, military, law, etc. Basically, things which are directly relevant to affecting scores (again, power factor, division, DQ, DNF) are all tracked. The timestamps are used because, in theory, any device can be synced to another device, and as long as the clocks on the devices are within 10 minutes of each other, it can correctly propagate changes through the system. This is what could be considered a problem with a peer-to-peer system, instead of a defined master/slave relationship. If you had a master, and the stage devices were all slaves, you could forbid slaves syncing to each other, and only the master can sync. But then a host of issues with having a single master can crop up, the worst of knowing who actually *is* the master. When you sync'ed stage devices to the master, you'd have to have a button somewhere that says "I'm a slave!", because you'd still need to allow a master to pass along it's "master status", so there can be backups of the master device, etc. Any time you start merging data, be it on handheld devices, on super-computers, on networks, whatever, there's always the issue of accurately and correctly determining what data is more current. There's a whole sub-set of information theory that covers this kind of stuff. So, yeah, it'd be better if there were finer grained control for people who know what they're doing, and a "Trust me, I'm from Microsoft and I'm here to help" setting for those that aren't. PractiScore is still evolving, and user input does get fed back into the system. A large number of the changes in it's evolution over the last couple years are direct user input. But it's got to be input that doesn't cover just cover your specific case, it's got to be a "all users" use case.

On iOS, there's a little arrow to the right that will let you see the changes. I can't remember if the Android version has something similar, because we use NOOKs for stage devices, and they only get synced once. As a side point, it gets confusing as hell when we're talking about syncing, and if you're syncing TO a device or FROM a device. Seems that in the interest of customer support, some clearly defined terms need to be defined.

Personally, I'd prefer it's something we didn't do. Not my call, though. We definitely don't let it hold up a match. It happens more often when a squad finished on the classifier stage, or if a squad is backed up on that stage. Otherwise, I only get one or two reshoots from all the other squads combined. We charge $3 for a classifier re-shoot. In a July match, we made an extra $42 (gross) from reshoots.

It's perfectly legal to do so, and the phrase "Paper GM" wasn't created for no good reason. In EZWS, you add them to the match again, and EZWS will ask if this is a re-entry. Say yes, they show up in the name box highlighted in yellow. You enter a re-shoot score for the classifier, and repeat as many times as they shot it. EZWS will use the NON-re-entry for the match score, and the best of all their entries for the classifier submission. This is doable in PractiScore, but rather than creating a new entry and risk someone on the stage screwing something up, we have any classifier re-shoots recorded on paper, and we enter them in to EZWS manually. They never get entered in PractiScore, because we still use EZWS for classifier submission. One day we'll give that a try, but one of the clubs will be more difficult than the other, just because change is ... more difficult, let us say. Also remember that classifier re-shoots (other than for the purpose of a legitimate reshoot like you'd do on any other stage) is purely at the discretion of the match director. I've had matches where I've seen reshoots done up to four times. Usually only one of the actual re-shoots gets entered, because they're so hot to look at their hit factors right then and there that they'll literally throw away all but the best of the re-shoots. If you have three classifiers, enter the match classifier and the best re-shoot, since the middle one will just be ignored by EZWS anyway. See page 4, 'Entering Classifier Scores In EzWinScore', in http://www.uspsa.org/classifiers/Intro.pdf

It doesn't and most of the changes are relevant to all match types, not just USPSA. I'd suggest to inform your area director and USPSA HQ that you need to be able to upload uspsa and sc match results and classification reports from PractiScore. You mean inform them that the iOS version already supports uploading classifier/activity reports, and then have them ask you why the Android version doesn't? We can do that.

A friend of mine did it ~ 10 years ago at a level 2. He finished shooting the match with us -- and had fun..... Linda Chico -- the awesome stats person -- either left him in the daily results so he could see where he finished that night, or sent him a copy of the results for his division before deleting him for going sub minor...... See, that's the kind of customer service I'm talking about. It's the >decent< thing to do.

It also doesn't say that scores MUST be calculated. With paper score sheets, competitor just gets a copy of his stages and he can do the match himself if he wanted to... I guess if you've got an easy way for them to print their scores so they can do that, it would be OK. Oh, wait, NO ONE HAS A PRACTICAL WAY TO PRINT COMPETITOR'S SCORES AT A MATCH. This is a classic case of software supposed to make people's life easier, not more difficult. The competitor is our customer. A happy customer is a repeat customer, and spreads positive news of their experience. An unhappy customer tells 10 times as many people about how it sucked. As someone who writes software for a living, I try to keep in mind that, where possible, we add features and functions to make life easier and customers happy, not simply because we don't feel like doing it. When someone pays $125+ to shoot a match, and we can't give them something as simple as a copy of their scores, whether they DQ'ed, went sub-minor, or whatever, that's just LAME. And when we're talking about doing away with paper completely, and they're now at our mercy to get some value for their $125+, that's even lamer. "You shot 9 of the 10 stages, hit chrono, went sub-minor, and now we're not going to tell you what ANY of your hit-factors are, or let you play what-if with your buddies". Now put yourself in THEIR shoes. Shitty customer service? Damn right.

I've seen it happen. And "continue to shoot" depends on where their squad falls for going to chrono. It can be the last stage you "shoot.

Which rule? According to item number 40 on page 73 the shooter may continue shooting the match. Therefore deleting them from the match is not an appropriate action. I wonder what EzWin does? If you use the Match->Chronograph function (which I've never seen done, but that's not say that it's not, so I'd ask Bill Noyes), a sub-minor competitor is deleted from the match, just as if you had set 'Deleted from pistol match' to 'Yes' in the registration screen. For going minor, it changes their power factor from 'Major' to 'Minor' in the 'Power Factor' setting.

Appendix C2.40. If the resultant power factor fails to meet the minimum power factor floor for the relevant Division, the competitor may continue shooting the match, but not for score or match recognition. I believe this to mean that the competitors scores cannot be used for the purpose of classifications, standings AS COMPARED TO OTHER COMPETITORS, or awards. It does NOT say that a competitor cannot have a score calculated, nor that they cannot be made aware of what that is. So I'm with Ken. You sort them to the bottom, perhaps even below the DQs, and label them as NSS, or Non-Standing Score.

I largely like it, although I'm not thrilled with calling them DQ'ed. Technically, yes, they are. But DQ has a bad connotation, usually indicating they did something unsafe. Admittedly, I can't think of anything better at the moment, but maybe our collective brain cell(s) can come up with something?

Just about any tablet in existence right now, really. There's other more significant factors into making a tablet unusable, at least if you're talking about using it as a scoring device. For just a general tablet, I'd avoid any of the $70 Chinese crap. Nexus 7 is a nice tablet, and the older models are less expensive. Anything with a resistive touch screen is unpleasant to use. If it's not a scoring device, battery life isn't an overwhelming concern. Almost all modern tablets have at least 512MiB of RAM, usually a GiB, sometimes two or four GiB. e-Readers are a special class of tablet. They're designed to have a decent battery life, so you're not recharging it every 6-7 hours of reading. To accomplish that, they use slower processors and have non-backlit screens (Glowlight is not real backlighting). Avoid an e-Reader platform, and anything you use will be fine.

"Crummy, weak processors". O...M...G... It's an 800MHz TI OMAP processor with 256MB of RAM! Compared to the 1.6GHz quad core and 16 *gigs* of memory in my phone, yeah, maybe it's not as hot. But it's still no slouch. I started out working on 2MHz 8080's with 16 *kilobytes* of RAM, and <1MHz 6502's with 4K of RAM. I've used smaller and larger machines since then, but still, an 800MHz CPU is hardly "crummy" or "weak". Kids these days! Sheesh...