I'm in the verge of finishing a new version of my software LoadBase. Some of the members might remember version 1.0, for which fortunalety I received very good feedback

My question is, can anyone estimate the possible market size for this type of software ?

Is it marginal the interest and use of such a tool for the average shooter?

In short any feedback regarding this issue is welcomed!

tks!

Gustavo:
Many factors need to be evaluated: Cost , ease of use, how encompasing it is, i.e. lowest cal through highest, hardware platform...windows / Apple, features/benefits, ect
I for one use an Excel database for my balistic data, but would evaluate whatever comes to market to see if it adds anything to the mix. Hope it helps, buena suerte.
Taz

Can it be used with a Palm or other portable device and can you print range cards? Just some thoughts.

You write it, I'll help distribute it on my website...

1) The software is developed to run under Windows (many versions including XP Pro)

2) It's not in my near plans to port the software to a Palm or Pocket PC platform

3) Modules will include :

Library : a reloading database (more than 20000 loads), bullets database( more than 2200), cartridges database (about 1300)

Ballistics : full solution of up to 6 tracks, including a special section to generate MilDot charts, field charts for wind, trajectory, graphs, and of course absolute interchange of units for both input and output ( a really needed touch)

Analyzer : Powley computer, BC calculations, etc

Recoil : full solution for up to 2 guns (multiple use of units)

Agenda : a full featured agenda, to store and retrieve reloading data, target data, vel data, etc

4) All outputs in HTML for both printing and to share with others in an easy manner and computer format

Ease of use, well...this in an area where the software excels, and where much care was taken. Users of the previous 1.0 version could giuve credit to this. In short the goal was to COMPLETELY AVOID any WRONG OUTPUT caused by wrong operation. In simply terms the SOFTWARE WILL NOT ALLOW THAT.

5) New database, larger and updated

6) Separate user database

7) price, nod defined but I guess it'll be about $ 49

Please any feedback is welcomed, especially about what do you think about the market potential and interest

tks!

Hey Gus, Do you have a Web page up and running with some examples of what it looks like?

If you have one example of each page so we could see what it actually looks like, might be enough to generate some interest.

Just a regular old 30-06 taken through all the steps from beginning to end would be nice. It would be a good cartridge to choose, because of all the data already available for it, people can see how close your Program comes to the information they are familiar with. Plus, since there is so much data available for the 30-06, you really aren't giving anything away that would keep people from buying your Software.

I have Wayne Blackwell's Load From A Disk and it has brought me many hours of pleasure doing "What if I try this..." kind of exercises.
---

If you have not considered how you are going to "Track and Resolve" the inevitable typos and minor goofs that are sure to happen, I can recommend that is something you will want to control extremely well. After you get a number of the Programs in Users hands, they are sure to find a few things that just got missed.

Then you need to decide if you want to provide the changes to eliminate those goofs as Downloadeable Updates, which is what I'd recommend.

When you treat your Customers properly, word spreads.

The market has room for good ballistic software of this type. The long range target and varmit guys for sure. But with the number of very good range finders out there, I think it would be a shoe in for the hunter. A reloading database is great if you can do graphic load comparisons. Just my .02

Gustavo,

I would like to thank you again for Loadbase and compliment you on it.

The thing is that today there is the free Pointblank and the Powley formula is freeware. If one goes beyond Powley then a lot of testing and checking would be required. For instance "Calculoader" did not check and it hurt them.

This is not to say that an inexpensive system would not sell. But then there may be liability questions.

If you do it I would stay away from interior ballistics.

Thanks again.

I am using the freeware PointBlank also. I like it a lot but do wish it was a little more "customizeable". I'd be happy to volunteer to be a field tester for your new product and I won't charge you a dime.

Dear all,

I'll try to address some of the points discussed, and first of all many thanks for the feedback! Without it is almost impossible to make REAL progress

1) On Interior Ballistics : I think the same as Savage99, so I have no intention of providing more than a Powley calculator. It's out of my scope to produce other type of solutions, like Calcloader or QuickLoad.

2) In fact, that's the reason a huge reloads database (from reliable sources as indicated) is part of the software and on the hand a feature uncommonly found to say the least.

3) Sorry, for the moment no web page is available, but I have no problem in sending bitmaps of the different screens to anyone asking for it. Just give me an email address.

4) I guess the "User experience" is of paramount importance, so as stated before the ystems is almost bomb proof and at the same deals with any typo or other error that could cause unexpected results or errors. Simply put THIS COULD NOT HAPPEN. Of course if the entered parameters are feasible you could obtain, in some instances, an undesired outcome.

5) as Dick mentioned, the software has a full developed ballistics module, with certain features oriented to the LR guy.

6) Also by Dick. Graphical comparison of loads, is an interesting feature I've played a lot with, but in order to be honest, never figured out which is the way to present the information in a manner that is both useful and suitable. For example, many loads came from different sources, whereas the test firearm is different with different barrel length, etc. In short my thought was that this could be very confusing and worst, inaccurate

Please let me know any other thoughts you might have and don't forget for asking any additional info by email

tks!

quote:

Originally posted by Gustavo:
...the ystems is almost bomb proof and at the same deals with any typo or other error that could cause unexpected results or errors. Simply put THIS COULD NOT HAPPEN. ...

Hey Gus, You do sound like a Software Developer. It is extremely difficult to see problems or typos in something you have written yourself. I do it all the time just whamming in posts here. Not picking on you at all, but I just noticed an "s" missing(typo) in your above reply. Happens all the time to me too, but they are typos.

Your quote took me back to when I was a young Product Evaluation Engineer. Had to Evaluate a lot of Software and Hardware over the years to Functional Specifications. None were perfect.

I've wrestled with so many errors in Software that I just know the odds of it happening are very rare.
---

Quick funny Hardware story. I was doing a Beta Test on a new Mother Board and happened to locate a piece of Bootlegged QE Software I'd not used before which ran data through all the DMA Ports. All of a sudden it Failed when it hit the last DMA Port. Huuummm!

Went to the QE guy that Bootlegged the Software and asked him if it was possible he had any problems getting through the last Port on the Simulator. "No indeed, why do you ask?", was his reply. We went through the issue and we figured it had to be a Board problem.

So, back to the QE Lab I go and start doing some good old circuit tracing. And in fact found(I had that spelled "find") a "trace missing". I write up the ECR and in about 4-weeks go to the Change Control Board meeting.

The Engineer that had originally Designed the Mother Board and Released it for Beta Testing had an entire new Layout and was ready to go straight to Gamma Test. I told the Board we would nee dto(see that typo) re-run this new Board through Beta Testing and see what we found before Signing Off to go to Gamma Testing.

The Designer nearly came unglued. He turned red and said(which I remember so clearly), "There is no need to waste time repeating the Beta Test - I DESIGNED THIS TO WORK!!!"

It got real quiet and all the CCB members looked over at this young rookie QE(me). I then asked the 3-piece suit guy the following, "Since you also Designed the first Mother Board layout, does that mean you intentionally Designed it to FAIL???"

We reran the Beta Test.

Hi HotCore!

Yes...I know .. I sounded like one!

What I meant is that every input is checked, without letting the user to go forward is the parameter is incorrect. For example trying to enter an alpha character instead of a numer or going out of range.

In the database section, as another example, the input sequence forces you tho choose from predetermined values in a "cascade" fashion.

The net result : You cannot the annoying message "..no matches..."

It's in how the user input dynamic is treated by the program.

Another example, you don't have a RUN button or something like that. This assure that every time you change a parameter YOU WILL HAVE the exact results matching the input. No way to make a mistake.

Of course and as stated before. Some parameters might be into the allowable range, so a solution is presented (in exterior ballistics for example) and here there is no way to prevent a user bad input.

The goal is to avoid wrong output as a result of wrong (not permitted) input.

Please, keep coming with more feedback!

tks!