I think we are talking past one another.
Here is my suggestion from above for that situation:
"I don't see why the system can't, or shouldn't, display the order that the shots arrived. That would give the scorekeeper the opportunity to override the result to award the correct shot in the case of an identifiable cross-fire (as described in your second paragraph)."
As a note: Additional sighters are NOT given in the US for a crossfire.
No matter which set of rules are being used, a system that displays the arrival sequence/time of arrival of shots and gives the scorer the ability to apply the rules correctly is optimal in my mind. a delay in the presentation of the result of the shot(s) isn't going to change that aspect.
I think we agree that the system must accommodate proper application of the rules. We only differ on how to prevent benchrest rates of fire (that we are seeing in the US already).
Watching this and the other thread has at times over the last few days cracked me up!
A lot of the features listed as being a mix of mandatory, desired, or simply "nice to have" have been available on at least one ET - Ozscore (mine) - and probaby Dimtri's (Hex) as well. I have never seen let alone shot on Dimtri's system so I cannot speak in any way about the Hexta system. But we have each in our own way designed our systems in our own way and with the same objectives i mind.
I have on this forum in the past stated some of the (if you like esoteric) features of the Ozscore System. I will state them again as a lot of them have been listed as "should be available" in the two current threads.
Ozscore has always (amongst other things):
1) provided automatic crossfire detection. This is exercised every week on just about every range using Ozscore with multiple targets. Whoever crossfires is told they crossfired (by means of a popup dialog window on the display), cops a miss, but is not told onto which target he/she crossfired. The target onto which the shot impacted measures it but does not report it to any legitimate shooter on that target - it is therefore essentially ignored (so no concept of two or more spotters being shown). This is because of the unique feature of Ozscore that allows for multiple shooters per physical target;
2) provided visual sensor status on both shooter and target computer displays - orange for bad, light green for good;
3) provided an "Optional Sighter" feature. The shooter is prompted to take the shot and once a result is available, decide whether they want it or to discard it;
4) provided a listing of the shots in the order fired.It also has available to those who want it the time of discharge, the time of arrival at the target and therefore (also displayed) the time of flight (TOF). TOF is a very useful number in load development and in some cases post-shot diagnostics;
5) provided an ability by way of a comprehensive chronological log - or "audit trail" - to millisecond resolution - a way to analyse exactly what has gone on during a shooting exercise. I lost count years ago how many times this "log" has allowed me to defend (if you like) the target system when a shooter got a result he didn't like (most often a miss). Shooters don't ever miss you know! Just ask them!!! (a poor attempt at humour here I suppose);
6) since about 2014 provided an optional and variable delay between discharge and result being displayed. No-one however uses this in Australia - I added it when the idea was being discussed but it has since been discarded. But the delay feature is still there should anyone want it.
7) provided a "system test" facility intended to be used prior to serious shooting commencing. There are two parts to it. One is the physical target test to ensure all sensors are correctly fitted and functional. The best way to do this is to fire a small bullet (.22) through the target at point blank range (like off a mantlet) but tapping the sensors can also do this (and is what most people do). The second pre-activity test is the test of the complete system from the mound - all firing point displays exercising the muzzle blast detectors, the mound network (be it wireless or wired), the main system controller software, the mound to target telemetry system (be it radio of wireless LAN wifi based), the target computer software, the subsequent shot result processing software (back in the system controller), and finally the display of the shot and its score on the shooter display.
What these two steps do is provide a high degree of confidence in the integrity of both the target electronics (including senors) and the rest of the system prior to serious shooting getting underway by exercising the entire suite of sub-systems. The tests essentially simulate what happens with a actual shot, without having to fire a shot.
The reality seems to be - here in Australia anyway - that regardless of the fact that the target system is dismantled and reassembled each time it is used, little testing is preformed and the first shot fired is a scoring shot. Should it not work things can become unpleasant on the mound. DO you dismantle and reassemble your TV and sound systems at home each time you want to use them? How long do you think they would last if you did?;
8) provided a means to gauge the target condition by measuring the errors (numerically) of each shot on the target and monitoring the trend of increasing errors. As the target degrades (with each shot fired) eventually a point is arrived at where the target is not really performing properly and requires some TLC (maintenance). Once a target starts getting too many holes in it sensors can stop working - especially with slow light bullets fired from a long way away on a hot day at altitude - resulting in lost shots. Using the error values, it is possible to determine if the target frame has been hit (and that happens more often than you might think!). I think this is how Dimtri does it also. The point is, this individual shot measurement of errors has always been available in the Ozscore system and primarily of purposes of maintenance planning of a target;
9) provided a way to dismiss some "misses" should an RO deem this action to be appropriate. A miss resulting from a crossfire or "out of scoring area" (including a frame shot) cannot be discarded;
10) provided an error or state feedback mechanism to the shooter by way of a dialog window. The messages shown attempt to convey what error has been detected. An attempt has been made to make these messages meaningful to shooters but I do accept that some of them may appear a little cryptic. But if conveyed to me then I can have some chance - if required - to hunt down the source and cause of the error/fault, or whatever, post match;
11) provided on-mound spectator display of firing points by browser connections into a small web server maintained by the system. This feature is typically used at most sites using my system for scoring purposes. The entire firing line can be displayed concurrently (up to eight at a time if need be);
12) provided the ability to employ wired (copper) or wireless LAN (network) techniques on the mound. Wireless (wifi) networking on the mound seems to be more trouble than it is worth for various reasons so a lot of my system now use a wired LAN. The system performs much better for shooters with the wired LAN. No-one has ever complained to me about the need to lay out extra cables (in addition to power);
13) A central power supply system. I decided to not power the various computer (and other) devices with individual batteries but rather provide power from a central source. In some places this is a battery (or two). Some now use a portable generator. For technical reasons I prefer the mound to be powered by 24VDC but 12V is OK until a battery starts flattening or failing - which they tend to do. Why do I not favour individual batteries? Well, I discovered that people have trouble properly maintaining single batteries so I wasn't prepared to push the boundaries by asking them to look after lots of them!
Some other features provided that perhaps some of you haven't yet thought of but were asked for by those using my system include:
1) colours optimised for colour blind shooters. Typically red has become orange, green has become light green, and blue a light blue;
2) the provision of a dedicated large (12") and bright colour touchscreen for the shooter. These displays are daylight readable and can be used in all weather conditions. They can be viewed from some metres (yards) away. Shooters do not required any keyboard to use the system. System administrators do require a keyboard however - one day I might implementing a "virtual" keyboard but that day hasn't com yet;
3) the display of the last shot only. This was requested by scope shooters (F-class) who at short ranges tend to maintain tight groups and the resulting spotters on the screen cluttered it up;
4) group size (in particular height) and position (MPI);
Some more features, provided more recently (like within the last five years or do), include:
1) realtime presentation of shots on the internet (Dimtri does this also and has done so for a long time). This obviously requires appropriate hardware and a usable internet connection from the mound or elsewhere on the range;
2) presentation of club shoot results (plots) on a web site (non-realtime) for shooters to view after the event. Again, Dimtri also provides this facility. I am not sure who else does.
3) the ability for me (or anyone else with the appropriate tools) to access the system remotely across the internet for diagnostics or general monitoring purposes - including software updates if required). It is possible for me to control any display or other computer in this way. I have been able to use this feature to sense a change in ammunition batch midway through a string (using the TOF values) as well as detect the cause of a high error due to a faultly sensor (covered by debris) - with me being 1000 miles away.
There are more but I think I can stop here - a point I want to make is that all these features have in some way been provided as a result of feedback and requests from those who use my system.
Things I am working on - as time and finances allow:
1) Shooter displays optimised for team shooting. Basically, the coach has the display with a muzzle blast detector going to each shooter (located under and slightly forward of the muzzle). The coach can manage each shooter with the shots of each shooter manageable (and recorded) under the rules of team shooting;
2) Bisley style shooting with all of the timing functions managed by the computers (not humans). While Bisley style shooting (2 or 3 shooters sharing a target in a round-robin fashion) is a natural fit for Ozscore, implementing Bisley rules under computer control is an interesting exercise and is definitely an area that I wouldn't mind discussing woith shooters who are interested in this approach.
Finally, a couple of other points, or observations:
Electronic target systems such as Ozscore and Hexta involve the use of some pretty sophisticated hardware and software techniques. They are not simple devices. The performance of any acoustic target is driven by the laws of physics, and we are fighting a bit of a battle with such physics. Ultimately, shooters don't see what is being done behind the scenes to provide them with a meaningful result. Shooters tend to think in binary terms: a shot result is either a miss or not a miss. Shooters (whatever they say to the contrary) tend to focus only on misses and seem quite happy to accept any other result - regardless of what it is so long as it's not a miss. Am I wrong??? The fact is that if I am spending time analysing target data, it is to work out why a miss has occurred because shooters generally always want to know. I can't remember the last time I had to analyse a non-miss shot result (except for my own purposes).
The software and hardware used by both myself and Dimtri does not come cheap. I am however always looking to find ways to cut down these costs and am doing this right now. In my case, I build all my own hardware and write my own software- call it "boutique" if you like. For those who might be interested the Ozscore system is written entirely in C++ on a UNIX like operating system (not LINUX) with no dependency on so called "web browser/server" techniques outside of spectator displays. But it allows me great flexibility and control over what I do - and I am not subjected so much to consumer computer products suddenly (and inconveniently) reaching end of life (EOL) and becoming unavailable. As a result, the system is considered expensive but it is after all what it is because of the effort and labour put into it over ten years or so (same for Dimtri). Why should we do this for free? This thread (and the other one running) has put forward a lot of ideas for "features" but seemingly without much thought given to how providing such features might cost to develop, test, and deploy. As it happens, as I started this long post saying, a lot of them have already been implemented. Ten years of my life plus countless dollars have been spent putting the features mentioned in these threads together only to have people say directly that regardless of what they want, they will simply go out and purchase multiple $1k (or cheaper) personal systems slapped together that simply allow them to fire a shot and get a result, displayed on a user provided generic tablet or mobile phone, and expect them to perform adequately in a high stakes competition environment. What do you guys really want and to get it, how much do you think it should cost?
I think I can speak for Dimtri as well as myself when I say that we have always tried to deliver what shooters want - and to a great extent successfully (even if not recognised). But we do have to eat. How do we do this when few want to actually purchase what we produce because much simpler and cheaper open face systems (a different topic) that DO NOT provide anywhere near the same arrays of requested features listed on this forum appear for $1000 or less. How can we compete with that?
It is really hard justifying to myself (not to mention my wife) how I should keep going when no-one wants to pay for what I can provide as a result of their requests - or ideas such as those listed here? If it's not dollars driving us, then perhaps all that is left is passion.
Geoff Roberts
Ozscore.
