Magnox Roulette Extreme Tutorials

[lucky_strike]

Nothing new there...

Now we need to set up the system in the 'Init' method - what do we need to do.... well, we need to decide what colour we're betting on, set the units bet to 1 and the spin counter to zero.

Why ? Well, if you remember from a previous example, when we'd won we could simply call a certain part of the 'Initialisation' method to reset the table, and we'll do exactly the same again. The only thing we don't want to do is reset the colour we bet on, otherwise we'll always be betting on the same even bet.

Code:
method "init"
begin

set flag "Bet on Red" to true;
call "reset";

end


method "reset"
begin

put 1 unit on record "Units" data;
put 0 units on record "Spins" data;
put 100% of bankroll on record "Bankroll" data;

end


I've decided to start betting on Red, so I've set a flag to do this. If this flag is true, we're betting on Red. If it is false, we're betting on black. This is by far the easiest method of setting up a system which has different betting conditions... if something has happened, set a flag. If that flag is true, bet on something else - if we win, set the flag to false, start betting on the original condition. You can use multiple flags for multiple conditions but it can start getting very complicated.

Note, again, that we've split the 'Initialisation' method into those bits that need to be done once (setting the flag to bet on Red), and those bits that need to be done once we've won / maxed the progression. In this case there is no progression, but I'm sure you see what I mean.

Here's the (mildly) clever bit - in the 'reset' method, we copy the current bankroll to our data record. This means that whenever we call this routine, our (hopefully) increased bankroll is stored away and used as the basis for future profit/loss comparisons. By doing this, you lock away what you have already won, forcing the system to make future profit/loss determinations on the new, higher, value.

Now all we have to do is place the bets:

Code:
method "place bets"
begin

if starting a new session
begin
end
else
begin
add 1 unit on record "Spins" data;
end


if record "Spins" data = 10
   begin
   call "check bankroll";
   end


if flag "Bet on Red" is true
   begin
   put 100% of record "Units" data on Red;
   end
else
   begin
   put 100% of record "Units" data on Black;
   end
   
end

[lucky_strike]

Now the first thing to look at is the 'dummy' begin/end at the start of the routine. What we want to do is place a bet *before* any spins are made - when RX starts a new session it will run through the 'Place Bets' code and add 1 unit onto the spins counter before we've spun anything. Because you can't say 'if not starting a new session', I've had to do this to prevent the spins counter from being one higher than the actual number of spins.

There are other ways around this....

You could, in the 'main' method, go for this :

Code:
method "main"
begin

if starting a new session
   begin
   call "init";
   end
else
   begin
   call "place bets";
   end


end


But... you won't place a bet before the first spin...the system will wait until spin #2 before placing a bet - horses for courses - whichever suits you.

What we're saying is - add 1 onto the spin counter, as long as we're not starting a new session.

Then we check to see if we're up to 10 spins - if we are, we go away and decide whether or not to switch bets, up the units, *before* the bets are placed.

If we're not up to 10 spins, or we've completed the 10-spin 'check', we place the bets according to the flag. If it's true, we bet on Red - if false, we bet on Black.

Now all we need to do is check the bankroll if we're at 10 spins. Remember - if we're up, we set the new bankroll as our minimum, set the units to 1 and start again. If we're down, we stay on the same colour and double the bet. If we're even, we stay on the same colour with the same units.

Code:
method "Check Bankroll"
begin

if bankroll > record "Bankroll" data
   begin
   call "reset";
   
   if flag "Bet on Red" is true
       begin
       set flag "Bet on Red" to false;
       end
   else
       begin
       set flag "Bet on Red" to true;
       end

   end
   

   
if bankroll < record "Bankroll" data
   begin
   multiply by 2 units on record "Units" data;
   end
   
put 0 units on record "Spins" data;

end


If we're up, this code calls the 'reset' method - again, this locks in our bankroll, sets the spin counter to zero and the units to 1. Then we check which colour we're betting on... if it was red, we switch to black and vice-versa. I originally programmed it like this, and wondered why it wasn't working (I was always betting on Red)... Can you see why ??


Code:
method "Check Bankroll"
begin

if bankroll > record "Bankroll" data
   begin
   call "reset";
   
   if flag "Bet on Red" is true
       begin
       set flag "Bet on Red" to false;
       end
       
   if flag "Bet on Red" is false
       begin
       set flag "Bet on Red" to true;
       end

   end

[lucky_strike]

If we were betting on red (as we will be at the start of the system), and we're up, we set the 'Bet on Red flag' to false. Then, in the next section, we check to see if the 'Bet on Red' flag is false (well - it will be because we've just set it to false !) and it's set back to true. We will never have this flag set to false.


The 'Else' command takes care of this... if the flag true ? Yes... set it to false... No ? set it to true....


Anyhow - if the current bankroll is less than the saved bankroll, we double the unit.

If we're even, we do nothing - except zero the spin counter at the end there, which works for all conditions. This means we carry on betting on the same colour (we haven't changed the flag condition) and we carry on using the same units (not reset to 1 using the 'reset' method).

Whole program:

Code:
system "10 Spins"

method "main"
begin

if starting a new session
   begin
   call "init";
   end


   call "place bets";
   
end




method "init"
begin

set flag "Bet on Red" to true;
call "reset";

end


method "reset"
begin

put 1 unit on record "Units" data;
put 0 units on record "Spins" data;
put 100% of bankroll on record "Bankroll" data;

end





method "place bets"
begin

if starting a new session
begin
end
else
begin
add 1 unit on record "Spins" data;
end


if record "Spins" data = 10
   begin
   call "check bankroll";
   end


if flag "Bet on Red" is true
   begin
   put 100% of record "Units" data on Red;
   end
else
   begin
   put 100% of record "Units" data on Black;
   end
   
end


   
   
method "Check Bankroll"
begin

if bankroll > record "Bankroll" data
   begin
   call "reset";
   
   if flag "Bet on Red" is true
       begin
       set flag "Bet on Red" to false;
       end
   else
       begin
       set flag "Bet on Red" to true;
       end

   end
   

   
if bankroll < record "Bankroll" data
   begin
   multiply by 2 units on record "Units" data;
   put 0 units on record "Spins" data;
   end
   
put 0 units on record "Spins" data;

end

[lucky_strike]

Does it win ? Ermm.... ' not in the long term', is the kindest way to put it, but it is an interesting idea. One worth coding in RX, and if you have ideas like this, the best way to test them out is with this program, rather than running through hundreds of Hamburg spins by hand. If it works, great... if it doesn't, all you've lost is 60 minutes writing the program.



Anyway, lets look at the front-end system built into RX. SnakeEyes says 'bet on 10 spins' and then check the result. Why not bet on 5 spins, 15 spins, or 50 spins ? Each time you want to check this out, you would have to go into the program and change this line:

Code:
if record "Spins" data = 10


Can't be doing with that..... Also, why not see how you would do with a bet unit of $5 instead of $1. Or a bankroll of $200 instead of $1000 ? What if you play at a casino that has an American Wheel and a European Wheel - we can set RX to the wheel of our choice at the start of a session.

Obviously, this needs to be done from our 'initialisation' method, because we only want to do it once. Let's make a method called 'user choice' and call it from there.

RX has three basic commands:

input checkbox

input data

input dropdown




input checkbox allows you to tick a box and set a flag accordingly. You could use it to bet on 'High/Low' instead of 'Red/Black' in this system, for example.

input data allows you to type in a numerical value - like the cash value of a unit, for example.

input dropdown allows the user to select from a number of predetermined options, say 'American Wheel', 'European Wheel' and 'Izak's Wheel'. Izak's Wheel has a payout ratio of 38:1 and no zeros. If the user selects this option, let's tell them to 'Don't Be Silly' and end the session.





The input checkbox option can only be used to set a flag.

Code:
input checkbox "Bet on Colours" to flag "colours";


If you check the box, the flag will be set to true, otherwise it will be set to false. We don't really have much use for this in this particular system, although you will find it useful for applying 'optional' rules - for example, Turbo's 123 Street System where he bets on the straight-up numbers, the splits and the street - you could set this flag to only bet on the street, as per his 'low risk' suggestion.


The input data command takes a value and puts it on the data section of a record, or on a standard RX variable like' bankroll'

Code:
input data "Enter your Bankroll" to bankroll;

or
Code:
input data "Enter Cash value of Unit" to record "Cash" data;




The input dropdown is a little bit more tricky - each entry needs to be on a new line with the format:

Code:
input dropdown "Wheel Type
1:=American Wheel
2:=European Wheel
3:=Izak's Wheel"
to record "Wheel Type" data;


Each entry is signified by 1:=, 2:=, 3:= etc.

Note that the last quote (") is after the end of the last option, and then the record the option is to be written to is stated. What happens is that the choice is written to the record data entry as a number. I.e., if you choose, European wheel, the number 2 is recorded in the 'Wheel Type' record data section.

Let's program this:

Code:
method "user choice"
begin

   input data "Enter Your Bankroll" to bankroll;
   input data "Enter Cash Value of Units" to record "Cash" data;
   input dropdown "Wheel Type
    1:=American Wheel
    2:=European Wheel
    3:=Izak's Wheel"
    to record "Wheel Type" data;


end


And, of course, we need to call this from our 'init' method:

Code:
method "init"
begin

set flag "Bet on Red" to true;
call "user choice";
call "reset";

end

[lucky_strike]

Set this up and see what happens - obviously, we're not yet changing our program parameters based on any input (apart from bankroll - that is actioned because it is a system value), but you can see that you get 3 different boxes for each option. What would be more user-friendly would be one input box that had all of these options. Note that we have to call our 'user choice' method before the 'reset' method - the reset method will want to know what the value of the unit is - if we reverse them, the 'reset' method will always use zero as the value of the unit - no good !

Anyway, the answer to the question is very simple - all you do is add the command 'Group' to the start of the inputs. This has its own begin/end, just like an 'if', and makes all the inputs appear in one window:

Code:
method "user choice"
begin
   Group
   begin
   input data "Enter Your Bankroll" to bankroll;
   input data "Enter Cash Value of Units" to record "Cash" data;
   input data "Number of Spins to Bet" to record "Spins to Bet" data;
   input dropdown "Wheel Type
    1:=American Wheel
    2:=European Wheel
    3:=Izak's Wheel"
    to record "Wheel Type" data;
   end

end


So all we have to do now is adjust the system to the inputs - bankroll is taken care for us so...

The new command are:

load single wheel

load double wheel, referring to the number of zeros.



Very straightforward. Plus, all we do is check our spin count against our input and we're done. The display command is a new one - all it does is pop up a window with a message - I like to use it to display 'lose' when one of my law of the third ideas crashes out spectacularly - use it as you see fit !

Code:
system "10 Spins"

method "main"
begin

if starting a new session
   begin
   call "init";
   end


   call "place bets";



end




method "init"
begin

set flag "Bet on Red" to true;

call "user choice";
call "reset";

end


method "reset"
begin


put 100% of record "Cash" data on record "Units" data;
put 0 units on record "Spins" data;
put 100% of bankroll on record "Bankroll" data;

end

method "user choice"
begin
   Group
   begin
   input data "Enter Your Bankroll" to bankroll;
   input data "Enter Cash Value of Units" to record "Cash" data;
   input data "Number of Spins to Bet" to record "Spins to Bet" data;
   input dropdown "Wheel Type
    1:=American Wheel
    2:=European Wheel
    3:=Izak's Wheel"
    to record "Wheel Type" data;
   end
   
   
if record "Wheel Type" data = 1
   begin
   load double wheel;
   end

if record "Wheel Type" data = 2
   begin
   load single wheel;
   end
   
if record "Wheel Type" data = 3
   begin
   display "Don't be Silly";
   stop session;
   end


end

method "place bets"
begin

if starting a new session
begin
end
else
begin
add 1 unit on record "Spins" data;
end


if record "Spins" data = record "Spins to Bet" data
   begin
   call "check bankroll";
   end


if flag "Bet on Red" is true
   begin
   put 100% of record "Units" data on Red;
   end
else
   begin
   put 100% of record "Units" data on Black;
   end
   
end
   
   
method "Check Bankroll"
begin

if bankroll > record "Bankroll" data
   begin
   call "reset";
   
   if flag "Bet on Red" is true
       begin
       set flag "Bet on Red" to false;
       end
   else
       begin
       set flag "Bet on Red" to true;
       end

   end
   

   
if bankroll < record "Bankroll" data
   begin
   multiply by 2 units on record "Units" data;
   put 0 units on record "Spins" data;
   end
   
put 0 units on record "Spins" data;

end

[lucky_strike]

By Magnox from VIP

In this edition, I won't be introducing many new RX language commands. Instead, we'll be looking mainly at how to think through translating a system idea into RX code.

So far we've got a system that randomly bets on 2 dozens, with a 5-step progression and a stop/loss point. That's not really a 'system' and most of you who want to use RX have much bigger ideas.

Let's consider an idea - how many times does a single dozen hit in a row ? It could hit 200 times in a row, theoretically, but in practice, what is a reasonable value to expect ? As a system designer I might think 'well, I've seen it hit 5 or 6 times, maybe as many as 8 or 10 times in a row, but mostly they hit 2 or 3 times'.

Using this idea, I could make the system wait until, say, 3 same dozens have hit in a row then start betting the opposite 2 dozens with my 5 stage progression. To lose, I would need the same dozen to hit 8 times in a row. Some of you may not agree with this philosophy (personally, I like to look at roulette numbers as a series of events, rather than looking at each number individually), but the aim is to code a system 'idea' and see how it works. So my system 'concept' is this - yes, I know that on each bet I have a roughly 2/3 chance of winning, yes I know a single dozen could hit 1000 times in a row, but as an 'event' I think it unlikely that any dozen will hit more than 8 times in a row during my session at the table.

So that's what we'll do - we'll make the system wait until 3 of the same dozens have hit in a row, then bet the other two dozens with the progression. If we lose the progression, we'll reset the count on each dozen and try again.

RX has a set of commands which allow you to check how many times a certain bet has hit, or not hit. They all follow this format:

if 1st dozen has hit each time - will be true everytime a dozen hits.

if 1st dozen has not hit each time - the reverse.

if 3rd dozen has hit more than 6 times

if 2nd dozen has hit exactly 5 times

if number 4 has hit between 1 & 6 spins

You can reverse any of those conditions by simply adding 'not' in front of the 'hit'. In order to make your program more readable, you could also use the following:

if 1st dozen has hit more than 6 times in a row

You don't need 'in a row', but it reminds you what's going on and might be helpful to your mate who's helping you design the system as well !

So we could do this on our 'place' bets method:

Code:
if  1st dozen has hit more than 3 times
   begin
   put 100% of record "Progression" data on 2nd Dozen;
   put 100% of record "Progression" data on 3rd Dozen;
   end

if  2nd dozen has hit more than 3 times
   begin
   put 100% of record "Progression" data on 1st Dozen;
   put 100% of record "Progression" data on 3rd Dozen;
   end

if  3rd dozen has hit more than 3 times
   begin
   put 100% of record "Progression" data on 1st Dozen;
   put 100% of record "Progression" data on 2nd Dozen;
   end


But will this work ?

[lucky_strike]

The answer is 'NO', and you're probably wondering why not. This is why you have to start thinking through your systems, both from a gambling viewpoint, and a programming viewpoint.

Consider this - let's say that the 1st dozen hits 14 times in a row. We skip the first 3 hits, then bet on dozens 2 & 3 for five progressions. Lose. In our program we reset the progression.

However, on the next run through the condition is still true - the 1st dozen has hit more than 3 times in a row, so RX will bet on dozens 2 & 3 again for a further 5 progressions. - what we wanted to was reset the count and wait for *another* 3 dozens to hit in a row before playing. Instead we dived straight in and carried on betting, losing two progressions.


If we had waited for another 3 hits in a row, we would have won on spin 12.

That's not to say the 'hit' commands are not useful - they are, but consider carefully what you want to happen.

As an aside example, let's say your system waits for the any dozen to miss 3 times in a row and then bets on it....

Code:
if 1st dozen has not hit more than 3 times
    begin
    bet 1 unit on 1st dozen;
    end

if 2nd dozen has not hit more than 3 times
    begin

    bet 1 unit on 2nd dozen;
    end

if 3rd dozen has not hit more than 3 times
    begin
    bet 1 unit on 3rd dozen;
    end


Will this do what you want ? Again, no... Why ? Consider what happens if you get four zeros or double zeros in a row - all of the conditions will become true and the system will start betting on all three dozens at once ! Result - Lose !!!! Consider carefully the impact of '0' and '00' on any of the hit and not hit commands.

What we'll do instead is set up 3 counters that keep track of the number of times a dozen has hit in a row - every time a dozen has hit, we add one onto the counter. Every time it misses, we set the counter back to zero. What about the zeros ? OK - if a zero hits, by using the above method, we have reset ALL the counters to zero, because NONE of our dozens have hit. Hopefully you are starting to see what I mean about thinking a system through before you start programming it.....

There is a further benefit from using a 'counter' - we could set up a 'front-end' that pops up at the start of the session and asks how many times we want any dozen to hit before we start betting on the other 2. This way, we can find out how profitable (or not) waiting for any particular number of hits is. We'll be doing this in the next tutorial. If we just use the 'if 1st dozen has hit more than 5 times' method, we can't adjust the number of hits we wait from a user input - we'd just have to go back into the code and change the value of '5' to whatever we wanted for each dozen. Tedious.

Remember our basic system template:

Initialise
Qualify
Check Win/Lose
Place Bets

So far we haven't used the 'qualify' part of it, but now we are.

Thinking it through, what we need to do is qualify the table, based on any dozen hitting 3 times in a row. Whilst we're checking this, we don't want to be checking win/lose conditions or placing bets. Once the table *is* qualified, we don't want to be qualifiying it again until we have won or lost our bets.

The modules, then, are mutually exclusive - i.e., we are either qualifying, or we're placing bets and checking the results.

RX has a great way of doing this. It has a system of 'flags' which you can name, just like data records. You can set them to true or false, and then check if they're true or false.

So - all we need to do is set a flag called "Table Qualified" to FALSE, in the Initialisation section, and then test it in our method "main" section to determine which of the modules we are going to call.


The format is:

set flag "Table Qualified" to false;

You can also set a flag to be true, using the same syntax.

Again, note the semi-colon and beware of typos - if you subsequently check to see if a flag called "Tabl Qualifid" is true or false, RX will create a new flag with that typo-d name and your program won't work !

[lucky_strike]

We also need to set our counters to zero for each dozen - you don't have to do this, but it is good practice and will help us out later on, as you will see.

Code:
method "Initialisation"
begin

set list [1,3,9,27,81] on record "Progression" data;
set flag "Table Qualified" to false;

put 0 units on record "1st Dozen" data;
put 0 units on record "2nd Dozen" data;
put 0 units on record "3rd Dozen" data;

put 100% of bankroll on record "Starting Bankroll" data;
subtract 300 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Lower Limit" data;
add 1300 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Upper Limit" data';

end


(Note that I have changed the stop/loss limit to -300/+1000... I'm very confident !)

Now we can change the main part of our program to look like this:

Code:
system "Two Dozens"

method "main"
begin

if starting a new session
   begin
   call "Initialisation";
   end
   
if  flag "Table Qualified" is false
   begin
   call "Qualify";
   end
else
   begin
   call "Check Win/Lose";
   call "Place Bets";
   end

end


Now all we need to is add a method called 'Qualify' and remember to set the flag to TRUE when any dozen has hit 3 times in a row, otherwise we'll never place any bets ! The conditions are now mutually exclusive as we wanted - if the flag is false, we continue to qualify the table - if it is true, thanks to the 'else' command, we will not execute the 'qualify' method and will instead start checking and placing bets.

We now have a template for *any* system that uses qualifying....

Now let's have a look at the new method section - 'Qualify'. You should be able to easily understand this by now.

Code:
method "Qualify"
begin


if  1st dozen has hit each time
   begin
   add 1 unit on record "1st Dozen" data;
   end
else
   begin
   put 0 units on record "1st Dozen" data;
   end


if  2nd dozen has hit each time
   begin
   add 1 unit on record "2nd Dozen" data;
   end
else
   begin
   put 0 units on record "2nd Dozen" data;
   end


if  3rd dozen has hit each time
   begin
   add 1 unit on record "3rd Dozen" data;
   end
else
   begin
   put 0 units on record "3rd Dozen" data;
   end


if record "1st Dozen" data = 3
or record "2nd Dozen" data = 3
or record "3rd Dozen" data = 3
   begin
   set flag "Table Qualified" to true;
   end


end

[lucky_strike]

We have set up 3 records which store the number of times the appropriate dozen has hit - if it hasn't hit, it gets set to zero. Once any record (note the use of 'or') is equal to 3 (a dozen has hit 3 times in a row), we set the flag to true.

Let's think this through - we need to requalify the table when we've either won, or maxed-out the progression. In order to do this, we need to reset all the counters to zero, and set our 'Table Qualified' flag to false.

But hang on.... we've programmed all this once in our 'Initialisation' section. Why not just call 'Initialisation' again ?? Well, we could but it also includes code to set our stop/loss limit which will be messed up if we do this. But but but.... why not separate the Initialisation routine so that it calls a 'reset' routine and a 'table limit' routine ? Then we can just call the 'reset' part when we've won/maxed-out.

Code:
method "Initialisation"
begin

set list [1,3,9,27,81] on record "Progression" data;

call "Reset Table";
call "Set Limits";

end


method "Reset Table"
begin

set flag "Table Qualified" to false;
put 1 unit on record "Progression" data index;

put 0 units on record "1st Dozen" data;
put 0 units on record "2nd Dozen" data;
put 0 units on record "3rd Dozen" data;

end


method "Set Limits"
begin

put 100% of bankroll on record "Starting Bankroll" data;
subtract 300 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Lower Limit" data;
add 1300 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Upper Limit" data';

end


Note that we have set the progression index to 1 on the reset.... that makes sure we start betting from the beginning of the progression and not where we left off on the last winning or losing spin.

We can also use the 'set limits' routine at sometime in the future to lock-in our winnings. Let's say we're up 100 units - we just call this routine and it will set our new stop/loss based on our current bankroll. You can have a go at this yourselves, but I'll post how to do in the next tutorial anyway.

Very efficient code now - we have all these little routines that can be called as and when they are needed, and not duplicated for starting a session, winning, etc... Also, by using this modular method, it is very easy to track down mistakes, or bugs, in the program. All you need to do is identify which part of the system is failing (placing bets, qualifying etc) and then look in the appropriate 'module'.

Now we need to alter our check/win lose section.... if we lose or max the progression, we just call the 'reset' routine.

Code:
method "Check Win/Lose"
begin

if net amount > 0
or record "Progression" data index > record "Progression" data count
   begin
   call "Reset Table";
   exit;
   end

if net amount < 0
   begin
   add 1 unit on record "Progression" data index;
   end
   

if bankroll > record "Upper Limit" data
or bankroll < record "Lower Limit" data
   begin
   stop session;
   end

end


Note the command 'exit;' - EXIT dumps out of the method we are currently in and goes back to where it was called from. As we have reset everything, no bets will be placed and we will start to qualify again.

Note also, that we have to separate the checks on the win/lose using the net amount command. If we carried on using the 'else' command, from the original program, 1 gets added to the progression index before the bets are placed and we would start betting on 3 units per dozen, instead of 1. This is because the last spin did not result in a win.... in the old program we bet on every spin, so all we did was add one to the progression on a lose. In this system we don't bet on every spin, so we only add 1 onto the progression when we've lost *after placing a bet*. This will make sense once you think about it !

And finally, in the 'place bets' section, we remove the random number generator and place the bets on the results of our dozen counters:

Code:
method "Place Bets"
begin


if record "3rd Dozen" data >= 3
   begin
   put 100% of record "Progression" data on 1st Dozen;
   put 100% of record "Progression" data on 2nd Dozen;
   end
   
if record "2nd Dozen" data >= 3
   begin
   put 100% of record "Progression" data on 1st Dozen;
   put 100% of record "Progression" data on 3rd Dozen;
   end


if record "1st Dozen" data >= 3
   begin
   put 100% of record "Progression" data on 2nd Dozen;
   put 100% of record "Progression" data on 3rd Dozen;
   end
   
end


Because we don't carry on qualifying when we're placing bets, the '>=' is slightly overkill - we could use just '= 3', but you might want to change something in the future.... who knows... build in the redundancy at the start.

[lucky_strike]

The whole program looks like this:

Code:
system "Two Dozens"

method "main"
begin

if starting a new session
   begin
   call "Initialisation";
   end
   
if  flag "Table Qualified" is false
   begin
   call "Qualify";
   end
else
   begin
   call "Check Win/Lose";
   call "Place Bets";
   end

end




method "Initialisation"
begin

set list [1,3,9,27,81] on record "Progression" data;

call "Reset Table";
call "Set Limits";

end


method "Reset Table"
begin


set flag "Table Qualified" to false;
put 1 unit on record "Progression" data index;

put 0 units on record "1st Dozen" data;
put 0 units on record "2nd Dozen" data;
put 0 units on record "3rd Dozen" data;

end


method "Set Limits"
begin

put 100% of bankroll on record "Starting Bankroll" data;
subtract 300 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Lower Limit" data;
add 1300 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Upper Limit" data';

end


method "Qualify"
begin


if  1st dozen has hit each time
   begin
   add 1 unit on record "1st Dozen" data;
   end
else
   begin
   put 0 units on record "1st Dozen" data;
   end


if  2nd dozen has hit each time
   begin
   add 1 unit on record "2nd Dozen" data;
   end
else
   begin
   put 0 units on record "2nd Dozen" data;
   end


if  3rd dozen has hit each time
   begin
   add 1 unit on record "3rd Dozen" data;
   end
else
   begin
   put 0 units on record "3rd Dozen" data;
   end


if record "1st Dozen" data >= 3
or record "2nd Dozen" data >= 3
or record "3rd Dozen" data >= 3
   begin
   set flag "Table Qualified" to true;
   end


end



method "Check Win/Lose"
begin

if net amount > 0
or record "Progression" data index > record "Progression" data count
   begin
   call "Reset Table";
   exit;
   end

if net amount < 0
   begin
   add 1 unit on record "Progression" data index;
   end
   

if bankroll > record "Upper Limit" data
or bankroll < record "Lower Limit" data
   begin
   stop session;
   end

end




method "Place Bets"
begin


if record "3rd Dozen" data >= 3
   begin
   put 100% of record "Progression" data on 1st Dozen;
   put 100% of record "Progression" data on 2nd Dozen;
   end
   
if record "2nd Dozen" data >= 3
   begin
   put 100% of record "Progression" data on 1st Dozen;
   put 100% of record "Progression" data on 3rd Dozen;
   end


if record "1st Dozen" data >= 3
   begin
   put 100% of record "Progression" data on 2nd Dozen;
   put 100% of record "Progression" data on 3rd Dozen;
   end
   

end



The programming is starting to get complicated now ! If you have any questions, please post them and I'll try my best to help you out. Next time we'll add that front end and look at some more commands.

Cheers

[lucky_strike]

By Magnox from VIP

Right then... here we go. One of the hardest things to do in any incarnation of RX, but the guys at UX Software have been pretty clever with this release - progressions are now very simple, as long as you understand the concept of a data record from the last tutorial.

There are systems that use multiple progressions - i.e., bet 1,2,3,4 on some numbers.. if you win, immediately change the progression to 2,7,9,13 and carry on betting. If you lose the first progression, call it a day and start again. Also systems that are running progressions on multiple bets - say... an independant martingale of 1/2/4/8/16 on each of Black / High / Odd until they win or max-out on the progression - you can end up betting 2 on Black, 8 on High and 16 on Odd for example - you know the kind of system. Yes... we can do this.

No, not today !!

All we're going to do is add a 1/3/9/27/81 progression to our 2-dozen system from the last couple of tutorials. If we don't hit either of our dozens, we'll up the units bet on each dozen, based on the above progression.

In the next tutorial we're going to get even cleverer - we're going to design a program that runs through thousands of spins to see how many times a single dozen is likely to hit in a row. It's not going to bet anything, and it won't be a system - it will just tell us some information about the likelyhood of any given dozen hitting x-times in a row. Armed with this knowledge we will then wait until any dozen has hit x-number of times in a row (based on what we found out from that program) before we start betting with a progression on the 2 remaining dozens.

Bear in mind that you can run RX2 through all, yes all, of the Hamburg spins automatically if you want to. So it's not just a case of checking the results against an RNG, we can check the results against a real wheel - the only caveat being that the Hamburg data doesn't tell us when a dealer has changed, so you can't use signature based systems. Umm.. I can live with that...  

Down to business...


In the last tutorial we stored the initial bankroll into a record, subtracted 100 from it, stored the result in a new record, added 150 to that number and then stored that in a 3rd record.

What you can also do in RX is store more than one number into the data or layout section of a record.

What does this mean ? It means we can store a progression into one data record (or 'file'), call it 'Progression' or similar, and then start using it for our bets.

The command to do this is set list [number,number,number,etc] on record "Progression" data;

Remember that when we put some data to a record that doesn't exist (In this case 'Progression'), it is created for us. The numbers are cash values, so they need to go to the 'data' section of the 'Progression' record, which is why we add the word 'data' at the end, there. Call the record anything you like, but the simpler it is, the less likely you are to make mistakes later on.

Where does this command need to go ? In the Initialisation section of our program. We only need to set up the progression once, so that's where it goes.

Code:
set list [1,3,9,27,81] on record "Progression" data;


Shut down the editor and have a look at your data records - you will see a new record called 'Progression' with all the numbers above in it, separated by commas, as long as you have placed the command in the right place ! At this point, note that the value of 'Data Index' is 1.

This value 'Data Index' tells us which number in our sequence is going to be used. If we increase the value of 'Data Index' by 1, the number we will use will be '3'. See where this is going ??!! The value of 'data index' tells us which number in the record data is active - i.e. the one that will be used when we place the bet.

So onto practicalities;

If we lose, we need to increase the progression. If the progression goes beyond the limit of 81 (i.e. the 5th number in the list), we need to make a decision - do we pack it in and walk, or do we reset the progression and start again ? In this program we'll reset, but you could always use the command stop session; (as we used before on the bankroll check) to end your misery there and then. Your call.

This code needs to go in the 'Win / Lose' section.... it's checking what happens if we have won or lost......

If we win, all we need to do is reset the progression to start betting at 1 unit - i.e, set the data index to 1 - the start of the progression.

Let's look at how we know if we've won or lost....

RX has a command:

if net amount....

Net amount checks the total profit from all the previous bets - we might have won on the 1st dozen, but we will also have lost on the 2nd or 3rd dozen. Let's say we bet 3 units on Dozen 1 and 3 Units on Dozen 2, and the number that came up was 6. 'Net amount' takes the win from the 1st dozen, +6, and subtracts the loss from the 2nd dozen, 3, to give us a net amount of +3. If we lost both bets, then 'net amount' would give us the loss from the 1st dozen (-3) and the loss on the 2nd dozen (-3) to give us a total of -6.

The companion commands are 'win' and 'loss'....
if win amount.... or if loss amount....

These commands show the total win amounts from all bets placed or total loss amounts from all bets placed. If we are interested in the net result (i.e. wins - losses), then the net command is the one to use. If we used 'win amount' in the above example, it would give us a result of 6 units.... yes, we won 6 units on one dozen, but we lost 3 units on the other dozen which the 'win' statement does not take into account. So 'win amount' would give us +6, 'loss amount' would give us -3 and 'net amount' gives us +3 - the true total after all bets are placed.

You are more likely to be interested in the 'net amount' than any of the other amounts, but it is worth knowing the other commands - especially if you don't mind betting a sequence at a net loss, if your system suits it, as long as you have won the bet.

However, in this case, we want to reset the progression if we have won (or not lost anything, to put it another way):

Code:
if net amount >= 0
begin
put 1 unit on record "Progression" data index;
end

[lucky_strike]

Self-explanatory - on any bet we are up zero units or greater, we reset the data index on record "Progression" to 1. Remember the 'put commands overrides any previous value.

If we have lost though, we want to increase to the next value in the progression. All we have to do is add 1 on to the data index value and it will point to the next amount we have to bet - i.e. $3.

We could do this:

Code:
if net amount <0
begin
............


but we can be smarter than that.

If the first condition is not true, then we can use the command 'else' to do something different.

Code:
if net amount >= 0
   begin
   put 1 unit on record "Progression" data index;
   end
else
   begin
   add 1 unit on record "Progression" data index;
   end



The 'else' command means 'the first statement wasn't true'. So looking at in English - if we have won something then reset the progression, but if we haven't, use the next number in the progression.

'Else' is like 'If' - it needs it own 'begin/end' sequence'.

Now we need to check if we have reached the limit of our progression:

RX has a built-in value for each record called 'count'. There is a separate value of 'count' for the data and layout sections. Basically, it stores how many items there are in each section.

All we need to do is check that the 'index' value has exceeded the 'count' value for the data record, and we have bust our progression. I.e., there are 5 items in the data record (1,3,9,27,81) and the 'count' value is therefore 5. If we are trying to place a bet on the 6th value (which doesn't exist), we've bust the progression.

So..

Code:
if record "Progression" data index > record "Progression" data count
   begin
   put 1 unit on record "Progression" data index;
   end


I'll leave you to see how we can tidy up the code here - IF we win OR we lose the progression, reset the data index to 1. Exactly the same as the previous bankroll example - we are doing the same thing for 2 different conditions - use the 'OR' command and tidy the program up.

The only thing left to do is change our 'put' commands in the 'Bet' method, to reflect the progression. At the moment, all we are doing is betting 1 unit regardless of the last result.

We can leave the random number generator in place......

In order to bet the progression, we need to use the 'put 100%" command again.

put 100% of record "Progression" data on.... will do the trick.

This places the number from our list, using the index (i.e. an index of 1 will place a $1 bet, an index of 2 will place a $3 bet, and index of 3 will place a $9 bet) on the bet of our choice - a random dozen.

Your final program should look similar to this:

Code:
system "Two Dozens"

method "main"
begin

if starting a new session
   begin
   call "Initialisation";
   end

call "Check Win/Lose";
call "Place Bets";

end




method "Initialisation"
begin

set list [1,3,9,27,81] on record "Progression" data;

put 100% of bankroll on record "Starting Bankroll" data;
subtract 100 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Lower Limit" data;
add 150 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Upper Limit" data';

end




method "Check Win/Lose"
begin

if net amount >= 0
or record "Progression" data index > record "Progression" data count
   begin
   put 1 unit on record "Progression" data index;
   end
else
   begin
   add 1 unit on record "Progression" data index;
   end
   

if bankroll > record "Upper Limit" data
or bankroll < record "Lower Limit" data
   begin
   stop session;
   end

end





method "Place Bets"
begin

generate random number between 1 & 3 on record "Bet Decision" data;

if record "Bet Decision" data = 1
   begin
   put 100% of record "Progression" data on 1st Dozen;
   put 100% of record "Progression" data on 2nd Dozen;
   end
   
if record "Bet Decision" data = 2
   begin
   put 100% of record "Progression" data on 1st Dozen;
   put 100% of record "Progression" data on 3rd Dozen;
   end


if record "Bet Decision" data = 3
   begin
   put 100% of record "Progression" data on 2nd Dozen;
   put 100% of record "Progression" data on 3rd Dozen;
   end




end


Now then... our original stop/loss limit of -100/+50 isn't going to work with this progression because we can bet 1+1+3+3+9+9+27+27+81+81 units on any given progression.

Either remove the stop/loss code or adjust it to reflect our new 'high-roller' status  Your call... from now on, I don't think I need to walk you through minor adjustments to the program - you should be proficient enough to see what it going on yourselves.

At the end of the day, break down your system into manageable chunks - Initialise, Qualify, Check Win/Lose, Bet. You can't go wrong with this and you will start to really reap the benefit of this fantastic software.

Cheers

[lucky_strike]

By Magnox from VIP
Hopefully, having waded through Part 1, you should be confident enough to program basic systems. It does take a bit of practise, and discovering where those semi-colons go is a painful trial and error process. (UX Software - hint, hint !)

Firstly, let's tidy up the basic system - in the "Check Win/Lose" method, we are doing the same thing twice for two different conditions.... we are ending the session IF our bankroll is less than 400 OR more than 550.

Code:
if bankroll > 550
   begin
   stop session;
   end

if bankroll < 400 units
   begin
   stop session;
   end


This is a bit tedious, and slows the system down as well. We can program it exactly as we say it in English. Replace those chunks of code with this:


Code:
if bankroll > 550 units
or bankroll < 400 units
   begin
   stop session;
   end


The companion command is 'and'. If we replace the 'or' with an 'and',in this case, the session will never be stopped because the bankroll cannot be both greater than 550 units AND less than 400 units at the same time.

However, we said we wanted to be able to stop the session, regardless of our starting bankroll when we are 100 units down, or 50 units up. To do this, we need to save the value of the starting bankroll somewhere and create values that are 100 lower and 50 higher, for the program to compare.

RX2 uses a concept they call 'data records'. A data record is basically like an entry in a filing cabinet. Each data record has a name, and you can check what is in these data records by simply referring to them by name.

Each data record (or file) has 4 areas you can put information in. If you close down the editor, and select 'statistics' then 'data stores' from the main RX menu, you can see the areas - Data Index, Data, Layout Index and Layout. At the right hand side is the name.

For the moment, we will forget the indexes and look at the Data section. In the Data section you can store numbers - things like progressions, bankroll values, that kind of thing. In the Layout section you can store Roullette wheel numbers, streets, dozens... anything that is physically represented on the wheel.

Think of it like this - the Data section contains cash values, the Layout section contains wheel values. You cannot mix the two.

What we need to do then is copy the starting bankroll into one of these data sections. We then need to subtract 100 units from it and store the result in a 2nd location, add 50 units to it and store that value in a 3rd location. We need to do this because you *can't* do this in RX;

Code:
if bankroll < (Starting Bankroll - 100)

[lucky_strike]

The code for storing numbers and spins into the data store looks complicated initially, but is quite straightforward. We use the 'put' command, but change the format slightly.

put 100% of bankroll on record "Starting Bankroll" data;

Let's look at this step by step.... 'put 100% of bankroll' is straightforward enough. Note that you can't have 'put bankroll on record... etc'. It's just the way RX2 works.

on record "Starting Bankroll" data;

This means - use the record called "Starting Bankroll" - if there isn't one, RX will create one for you. Beware of typos - if at some point later on in the program you refer to the record as "Starting Banroll" for example, RX will create a brand new record for you !

The last word - data - means store the information into the 'data' section - the cash values. The word 'data' can be changed to the word 'layout' to store wheel numbers into the layout section. RX will not allow you to put normal numbers or bankroll balances into the layout section. Change the word 'data' to 'layout' and see. It will validate OK, but when you run the system there will be nothing in the layout section.

Data - Cash or any mathematical number
Layout - Roullette Wheel Numbers / Groups

Now we need to subtract 100 units from this value and store it in another data record under a different name.


This does the subtracting:

subtract 100 units on record "Starting Bankroll" data;


This does the storing:

put 100% of record "Starting Bankroll" data on record "Lower Limit" data;

All we're doing there is copying that value into a record called "Lower Limit" - which is a new one, so RX creates it for us.

Now we need to add 150 units onto the starting bankroll record. Why ? Because our starting bankroll record has been depleted by 100 units already and we need it 50 higher than we started with.

Code:
add 150 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Upper Limit" data';


So.. the whole lot should look like this :

Code:
put 100% of bankroll on record "Starting Bankroll" data;
subtract 100 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Lower Limit" data;
add 150 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Upper Limit" data';



But where to put it ?


This is really 'initialisation', and if you remember from Part 1, we used a 'method' section for each of our 4 possible modules in the system.

Open up the part 1 tutorial file and add a call to a 'Initialisation' or 'Start' method - whatever you want to call it. Then add the method itself - probably a good idea to do it above the 'check win/loss' method, just to keep things easy to follow.

Put the bankroll storing code inbetween the begin/end for this method and you should have something that looks like this :

Code:
system "Two Dozens"

method "main"
begin

call "Initialisation";
call "Check Win/Lose";
call "Place Bets";

end




method "Initialisation"
begin

put 100% of bankroll on record "Starting Bankroll" data;
subtract 100 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Lower Limit" data;
add 150 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Upper Limit" data;

end




method "Check Win/Lose"
begin

if bankroll > 550 units
or bankroll < 400 units
   begin
   stop session;
   end

end





method "Place Bets"
begin

put 1 unit on 1st Dozen;
put 1 unit on 2nd Dozen;

end



If you close the editor and go back to RX, open up the data records, you will see that we have 3 records - Starting Bankroll, Upper Limit and Lower Limit. Starting Bankroll and Upper Limit are the same, but it will be a lot easier to use a record called "upper limit" than one called "starting bankroll" when that record doesn't now contain the starting bankroll at all !

However - one problem with what we've done. This 'Initialisation' routine will be run on every spin and mess everything up. What we need to do, is run this once, when we start a sesssion.... piece of cake.

All we do is say 'if we're starting a new session, call the initialisation routine.' Remember, each 'if' has a begin/end as well.

Code:
system "Two Dozens"

method "main"
begin

if starting a new session
   begin
   call "Initialisation";
   end

call "Check Win/Lose";
call "Place Bets";

end




But... we still have the number 400 and 550 hard-coded into the system. We need to get it to check our values in the 'upper limit' and 'lower limit' data records.

Instead of the numbers all we need to do is refer to the upper limit data and the lower limit data;

Code:
if bankroll > record "Upper Limit" data
or bankroll < record "Lower Limit" data


Note that you don't need a bloody semi-colon on either of these statements - if you put one in, you get a compiler error !

[lucky_strike]

So.. the new program looks like this :

Code:
system "Two Dozens"

method "main"
begin

if starting a new session
   begin
   call "Initialisation";
   end

call "Check Win/Lose";
call "Place Bets";

end




method "Initialisation"
begin

put 100% of bankroll on record "Starting Bankroll" data;
subtract 100 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Lower Limit" data;
add 150 units on record "Starting Bankroll" data;
put 100% of record "Starting Bankroll" data on record "Upper Limit" data;

end




method "Check Win/Lose"
begin

if bankroll > record "Upper Limit" data
or bankroll < record "Lower Limit" data
   begin
   stop session;
   end

end





method "Place Bets"
begin

put 1 unit on 1st Dozen;
put 1 unit on 2nd Dozen;

end




Now, finally, before I go on to progressions, let's make our bet selection of the dozens random.

There are 3 possible ways of placing a bet on 2 dozens... 1st and 2nd, 1st and 3rd, 2nd and 3rd,

If we generate a random number from 1 to 3, we can do this:

1 - Bet on 1st and 2nd Dozen
2 - Bet on 1st and 3rd Dozen
3 - Bet on 2nd and 3rd Dozen.

So, we need to generate a random number and then store it in one of our data records which we'll call "Bet Decision".

Obviously this code needs to in the 'Place Bets' method:

To generate a random number, we do this:

Code:
generate random number between 1 & 3 on record "Bet Decision" data;


Note the word 'data' again, after the name of the record store - because it's just a 'number', not a roullette wheel bet, then it has to go in the data section.

Now all we have to do is make the bets based on what number is stored in the 'Bet Decision' record:

Code:
if record "Bet Decision" data = 1
   begin
   put 1 unit on 1st Dozen;
   put 1 unit on 2nd Dozen;
   end
   
   if record "Bet Decision" data = 2
   begin
   put 1 unit on 1st Dozen;
   put 1 unit on 3rd Dozen;
   end
   
   if record "Bet Decision" data = 3
   begin
   put 1 unit on 2nd Dozen;
   put 1 unit on 3rd Dozen;
   end

[lucky_strike]

-