From a database perspective, I think we'd need to have a table for motors used that would be linked from the flight record table via a unique ID as a one to many relationship from the flight record. I think from an entry perspective, you could have a button to "Add Motor" and "Add Stage" which would add one or more records in the motor_used table. As for propellant type, it is pretty much implicit in the motor record from thrustcurve - I believe they have hybrid motors and BP motors indicated. A more detailed look at the data structures available for remote query is next I think on this.

One thing I really don't want to have if we can help it is a motor database that we would have to maintain as we have - it plainly is a bit more maintenance than we're capable of given the numbers of motors coming out the last couple years.

By the way, the link Joe mentions in the old site to Thrustcurve.org wasn't to pull data, but a link to the individual motor .eng files so they could be pulled down for use in Rocksim. It didn't figure into the AP Bonfire or any other contest or launch log data entry validation.

Why are you avoiding the issue? Although the post was originally under the launch logs topic, both Scott and Edward were asking why the AP Bonfire Contest does not accurately reflect what they burned. I brought this up last year and I suspect it will be questioned every year until it gets fixed.

I proposed a very reasonable solution that actually reduced to work for anyone running the contest and it fell on deaf ears. Only after more and more members complain why the AP Bonfire Contest is a joke will it possibly get changed.

Doug

I don't recall what your solution was - I'll look for it on the forums. Fixing it would be great. We don't me to avoid or ignore the issues - we may just be naively oversimplifying.

Ah - found it.

AP Bonfire 2008

Thanks, Doug - I'll read thru that and will be talking with Warren this week.

As I've said before Doug, it has ALWAYS been a function of programmer bandwidth. The AP Bonfire as well as pretty much all the other contests run automatically once we set them up. If they require much human intervention, they just won't happen at all due to their quantitative nature rather than one-off nature.

We have been working to find a fix and a fix will be had eventually. End of story. In the meantime, we're trying to generalize and resolve a much deeper problem in the launch log system that doesn't allow for clustered and staged flights. By solving that we solve the other.

Warren

Warren - I agree: the current thrustcurve links are deep links into the site for motor data. There is now a service interface to actually pull the motor attributes. We could almost transparently drop our motor database and replace it with a cache of service calls to thrustcurve. We'd have the same issue as we do now because propellant on TC is more than AP but maybe we can address that based on Doug's suggestions or a supplemental DB that has more detail for those motors that aren't simple AP motors.

it has ALWAYS been a function of programmer bandwidth

Warren quit being such a nay-sayer and pull the crap out of your ears and open you mind. The AP Bonfire contest does NOT require "programmer bandwidth". It never has.

we're trying to generalize and resolve a much deeper problem in the launch log system that doesn't allow for clustered and staged flights. By solving that we solve the other.

Once again your are wrong. Even if you fix the data base issue so all motors in thrustcurve.org are available AND you make multiple motor flights to be entered into the flightlogs, the contest would still not include the original fundamental concept of a contest to determined who burned the most AP since you won't allow experimental motors.

Doug

Allowing EX motors is an intrinsic part of this Doug. We want to allow for EX motors as well as arbitrary clusters and staged birds. There even is a good plan for how to do this - the dilemma is that this is beyond my personal PHP skills to program, perhaps primarily out of personal laziness and my own focus on C/C++ programming to the exclusion of other languages, but nonetheless comes down to a bottleneck of available programmer man hours.

Any manual process other than entering launch card data is utterly out of the question so a programmatic solution has to be created. There is a general high level design for accomplishing this and there has been for a couple years. The main obstacle to this has been the availability of someone of Jeremiah's capabilities to focus on the problem at the level of actually implementing it in PHP code on the site. Jeremiah now seems to have some time to devote to this project so I expect we'll see a fix for the issue you're complaining about.

Jeremiah, I have time all this week to get together and work this out - we can combine it with a session of glassing on your project. I have plenty of time this week and my shop is already set up as we just did John Wilke's project. I'm gone all the week of the 17th through the 24th. Give me a call.

Warren

it has ALWAYS been a function of programmer bandwidth

Warren quit being such a nay-sayer and pull the crap out of your ears and open you mind. The AP Bonfire contest does NOT require "programmer bandwidth". It never has.

we're trying to generalize and resolve a much deeper problem in the launch log system that doesn't allow for clustered and staged flights. By solving that we solve the other.

Once again your are wrong. Even if you fix the data base issue so all motors in thrustcurve.org are available AND you make multiple motor flights to be entered into the flightlogs, the contest would still not include the original fundamental concept of a contest to determined who burned the most AP since you won't allow experimental motors.

Doug

Keep in mind... this is all voluntary on thier part. 8)