[url removed, login to view]
Every Page is its own event and has its own list of tickets on it.
There is an interactive map on the right which we do not care about and will only slow things down if we put it into play. The key here is speed. The first one to buy the tickets gets them, so speed is extremely important when tickets pop up and become available.
Tickets become available as this program will be constantly refreshing an event and waiting to purchase tickets that fit our "search criteria".
The left hand side has a list of tickets and the prices they cost. This list and its prices are changing throughout the day and can change on a seconds notice or new tickets may be put onto that list which may fit our search criteria.
One there are tickets in our search criteria that are available, we need this program to place the order for me....before anyone or any other program beats me it to it.
We need to be able to let the program know is a range of sections, rows and prices that fit our needs for what we would like to order, and the max dollar we are willing to pay on that order.
The way we would like to enter it into the program is a range of section numbers, (optional row range). For example: sections 104 - 109, between rows A-D that are priced at a maximum of \ per ticket, we would like to order. Meaning at the time we enter the information into the program, there may very well be tickets avaiable on that event, for example section 105 row B, however more than likely, itll be priced at more than what we are willing to pay. The program should constantly monitor all listings with section numbers 104 through 109, and rows A through D. and when it sees something available in our "budget", itll go straight to placing orders.
Rows should be an optional field, and that if its left empty, it should consider all rows in those sections under our budget
We also need to be able to create MULTIPLE search criterias at the same time within an event. so for example (sections are the first ones, in the hundreds, some venues use lettered rows, and some use numbered, so a range would need to be alphanumerical, and some even use double letters, and some use double and single letters in the same secitons. those who use that may work as row A-z coming before AA-ZZ, and other venues start AA-ZZ and then have row A-Z, so a letter "r" row should not be included in a search for rows AA-WW ), and is a ticket that is available fits ANY criteria listed, it should buy it and not hold back because of what may look like a contradiction
235-340, rows 1-15 \
235-240, rows 16-20 \
235- 240, \ (this means ignore the row and just fit the price) \
115-119, rows AA-FF \
So if after 2 hours of the program refreshing a ticket pops up (for example in this set of criterias) in section 503 Row Z, at \, the program should grab it because it fits cretiera 3, which the section is between the range of 502-508, and there was no specified row, and the listed price is less than or equal to our \ budget on that seating range.
Here is a list of options defining a search criteria:
-autobuy option (defualt on)
-minimum quantity (defualt 2)
-even and odd sections range
-ignore prefixed sections
-Bulk price reductions
the program should log the tickets it misses buying (tickets that other programs beat it to)
Source code is required. please post in your answer the following word: ragnarok at the end y you do not do it you will not be considered.
8 pekerja bebas membida secara purata $1750 untuk pekerjaan ini
Hi We are interested in your project and read your [url removed, login to view] have completed 150+ big projects in .NET,PHP and Java in last 5 years. Please check private message board for details.