Logging EVERYTHING that a trigger does

Hi
The setting for the market sorting order is:
Settings > General Options > Market Settings > Default sorting order

Shouldn't be any problem with having the text file on Dropbox etc. but clearly for this purpose, and for the operation of MFP in general, your internet connection should be solid. For testing start with the text file on the local drive, and if that works, then change to dropbox and test again.

It does sound like you could be having some issues with your machine. The initial login to MFP and Betfair takes around 10secs and after that all should be ready to go, no popups, and your earlier problems with reading the logs doesn't sound right, you should be able to view all logs easily in the browser, and being able to look at the trigger logs is paramount in developing a working trigger.

Perhaps do a re-install of MFP, start with a new profile, and use a simple known working example trigger in test mode to check all is operating ok. Once you are happy with that, then get started on your own triggers, and please use test mode until you are confident with your set-up and the functioning of your trigger.   

Hi,

MarkV, thanks again for your help and responses.

There has been a somewhat interesting development...

I decided to just look to do a back bet, once there was an entry in the file that was written to by MFP. As usual, this did not work. So, I then decided to just make sure the lay at SP goes in, by setting the price to 500, so I have more opportunities to do the back bet. and then write an entry to the SP text file via an action in the trigger that does the Lay at SP, the file was written to, but again, this check for the selection failed.

BUT, when I swapped the file that is queried, to the SOURCE file, rather than the 'dynamic' SP file, then the back went in, no problem. I even added in an extra complication for the price, such that the bet gets placed at r_ticks(actual_sp, 1). No problem with that, and if the price reached that far, the bet was placed.

RESULT!

This has established that the back execution does indeed place a back bet.

But of course, this does not solve my problem, because I ONLY want to get the selection that was written to the 'SP' file...

Rather than look at the logs using the raw format, I looked at the trigger log through firefox, and I usually get this by clicking the trigger itself.

Now, there was a selection named Hitherjacques Lady in the SP text file, BUT, as you can see from the image, the trigger log is showing the condition to be false.

So, this means that the trigger is not able to read the SP text file, and maybe that is because this is updated, and MFP cannot 're-read' it, even though I am setting re-read to be true.

Hopefully, you can see quite clearly from the image that the condition is declared as FALSE, at which point, the trigger exits.

So, how do I resolve this problem?

Not sure to be honest, but my first try for this is to look at opening up a new profile, and having a simple trigger to query the SP text file only, in-play.

I am pretty sure this is the problem, but, if my new profile still cant 'see it', then, I suspect that perhaps MFP is faulty?

Perhaps a bold statement, but as per the discussion yesterday, I have placed the files' location on my local hard drive. My internet is not slow, or problematic.

Mark.

Hi
Attaching screenshot of the log here.

If we compare the logs, I would say MFP is unable to read anything from your file in it's current location. Either it's empty at the time of checking, or something is blocking MFP from that file. Try putting the file in the documents folder on C: or in the MFP triggers folder, change the file path in the trigger condition, and test again.

hi MarkV,

Thanks again...

Here is another development...

I ran a test profile to Lay at SP, from the SOURCE file, and within the trigger, it has an action to write to the SP file. The BACK part of that trigger is not working, as has been discovered.

BUT

I also decided to create another test profile, with a BACK trigger (without the condition number of lays > 0), and I set the SOURCE text file, to that of the SP file.

And, after the LAY bets were placed, and entries were made into the SP text file, the BACK trigger, in the other profile, spotted the selections, and placed back bets. So, the trigger that backs them, does work, as expected, BUT, if I put them both together, i.e. the Lay and the Back, then it doesn't work.

As per your suggestion that something is blocking access to the SP file, then I would have to question that, because the Lay trigger is able to write to the SP file, no problem, and the OTHER profile's Back trigger is able to read the SP file.

I have no clue how I am going to resolve this.

The problem doing a test scenario, is that by having 2 separate TEST profiles, the Back trigger in profile 1 cannot check any number of Lay selections from profile 2

Hi
You really should be able to do all within one profile.

It's clear from your log that when the condition "is in file" is checked, it does not find any values at all in the file, in the log of the test that I did, it shows values from the file.

I downloaded the T2R456_A4A5A6D4D5D6WLSP00 file you posted in Reply #5
This file has Read Only permissions for two user accounts (see attached screenshot)

In the test text file I used to test, there are no similar Read Only permissions.

My gut feel is this is where your issue is, though I'm afraid I do not know how to correct it.

Hi MarkV,

Again, I owe you a LOT of thanks for putting so much time into this, Thank you!

After reading through and looking at your attached image, I decided to create a new folder on my hard disk, and took out ALL users, except me, 'mark'

I decided to use a new strategy I am trialing, and use the same actions I have been trying in the 'not working' trigger.

I appreciate the annotations may be slightly confusing, so I will explain the image...

Stage 1 = 'SP 456 V1' - this will lay bet at SP, anything that is contained in the SOURCE file. This file is in SYNC (Cloud Server). After inspection, I looked at the properties of this file, and it has those 'extra' users, AND it is read only. So, this should not be a problem, because the trigger is only reading the file anyway. This part of the trigger works fine, and places the lay at SP bet - no problem.

Stage 2 = 'Write_To_File' - this writes to the SP file. Now, as you can see from the file properties -> security, full control is allowed to 'mark'. As you can see, within the trigger conditions, it checks that Matched Lay Bets > 0, and, in a new block, contains an 'OR' statement, which checks whether the SP is either below or above the values shown (6.01 to 7.59) - if you look at the opened text file, this trigger has written to the file, the 2 entries "Next Destination" and "Cracking Smart" - no problem there. The SP file is NOT in the SYNC system, and is owned by 'mark'

Stage 3 = 'SP_Back' - this is the check to see if there are entries in the SP file, which there are, and given that the writing of the file, in stage 2 satisfies the criteria, as in below 6.01 (in this instance), then the next stage is to place a back bet.

And, of course, it hasn't done this.

So, I have now satisfied all of the conditions to expect to have success, but sadly, no joy.

Thanks again

Mark.

OK, given that we have seen that the Lay at SP trigger works every time, using selections present in the source file T456.txt, it has a price limit, so it wont bet over the price, and the tricky part comes, when/if at some point before in play, the price drops below the level given. As we have placed this using a Lay at SP, we cannot cancel the bet, due to the SP rules of betfair....

So, if we have a bet that has an 'in play' price below the set level, the bet will still get placed because we cannot set a minimum value through betfair, on a Lay bet, because the idea is that a lower price is a 'better' price. Same goes for Back bets, where a higher price is a 'better' price.

hence the need for the trigger to deal with this, which will check the SP, and if its below, it will place a bet.

Nothing new here...

So, as per my trigger system, I am writing to a text file, which has the ending 'SP', as in T456SP.txt, and this checks that the previous trigger has a number of runs > 0, AND also checks that the number of matched lay bets > 0, and if so, it places that selection in the SP text file.

Again, as before, nothing new...

Next part, which is failing, my trigger has the condition that the selection is contained in the SP text file. Of course, as we know, this is not working for me, and given that MarkV has gone to great lengths to help me sort it, I am still no further.

You may ask why I insist on writing to a text file, and reading from this text file?

Well, I have a number of strategies, let's stick with 2, and occasionally, more often than not, they will BOTH have the same selection in their respective source text file.

You could suggest that I just simply observe number of Matched Lay Bets > 0, and then check that the Actual Starting Price is below my level, and if so, place a back bet.

Using this approach, the trigger WILL work, because it is interacting with MFP, rather than an externally created text file, and as we know, MFP does its work perfectly.

BUT, as I want to use a number of strategies, each of which have their own price ranges I want to use, then, if the price is say 16, and this satisfies strategy 1 conditions, and a Lay at SP is placed, the races starts, and the Actual Starting Price is 16.5, which means that strategy 1 has had a successful bet. Now, if we look at strategy 2, whose minimum odds are 19, and given we are lucky enough for the selections price to not to reach, or go above 19, during the waiting phase before the off, then the Lay at SP part will not trigger. The problem is, the selection has had a successful lay bet matched, using strategy 1, so, if I then check the number of matched lay bets > 0, this condition will be satisfied, and a corresponding check to see if the SP is below 19, will come back as true, and so, a back bet will be placed.

Hopefully, given that anyone reading understands the whole process, you can see that strategy 2, will not have placed a Lay at SP bet, but, in its check, it will see that there is a lay bet matched for this selection, which was provided by strategy 1. As we know, the check does not know which part actually placed the Lay bet, and if the Back part spots this lay bet and the SP is below the expected level, a Back bet will be placed, which, in this case, is an unavoidable mistake.

Hence the reason why using a text file is essential, where Strategy 1's text file will be in a different location to Strategy 2's text file, and so, the checks done by each strategy, will be specific to location of its text file.


There may be a 'better' way to do this, such that each of these selections will not get mixed up in the process, and ALL of the rules are adhered to, but at this time, my setup looks to be the best one?

I will be happy if anyone is still awake at this point, reading my long text, and I will be even happier to discuss a maybe better solution?

Thanks for reading

Mark.

Hi
Please can you attach your trigger file, I would like to test it here. Thanks. 

Hi MarkV,

I am also attaching 2 images, which are a couple of days bets, which shows all bets, including a few that have gone below my criteria. Fortunately they all lost, so I made more profit. But, as you can see, some slip through, BUT, not that many. It does happen, but not very often.

Anyway, I have attached my trigger. I don't have the selections available yet, as I have to wait until just shortly before races actually start, as my system does ranking of horses, and it is best to do that as close to the first race, due to non runners...

I will attach the selection files, once I have them.

Thanks

Mark.

Got it thanks. I just want to test the back trigger mechanics, shouldn't need any selections. Will post back later this afternoon.

Hi
attached is a bare bones trigger that will:
read selections from T456.txt and lay at SP
write selections to T456SP.txt that have matched lay bets and SP is lower than lowSetMaxV1
read selections from T456SP and back at actual_sp

you will see I have stripped out everything except the reading, writing and backing. I also changed lowset... and highset...  and used bm_1_laya for testing. The screenshot attached shows the result.

I think you could use this trigger as your framework, start adding your formulae and conditions, and test the trigger in test mode after each new modification.