VLS Roulette Forum

By Magnox from VIP
Time to open up your RX 2.0, stop playing with the sample systems that came with it, and start making your own.
I have only just upgraded to this version myself, so it's as much of a learning curve for me as everyone else.
Which means - there may be some errors !
Hopefully, I'll be able to keep them to a minimum, but if anyone sees anything obviously wrong, or has a better way to do it, then don't be shy....

RX2 is very different from the previous incarnations - you are now faced with a fairly scary looking editor and a proper programming language.
However, don't be put off - you've paid the money for it, so let's use it !

RX2 now uses a language that promotes a system of 'routines' which, when assembled, complete your system.
This makes it very easy to build up your system in stages.

In my experience there are only ever four things you need to do build a system.
Sometimes less, but never more. Think of them as 'modules' that need to be programmed into your system.

All systems that I can think of have these 'modules':



Initialise - (set up progressions, lists of numbers to bet, etc - anything you only want to do once at the start of the system)

Qualify - (track numbers, wait for a certain amount of spins, whatever you need to to)

Check if we've Won or Lost the last spin (if applicable - there is no need to be doing this whilst we're still qualifying - more on that later.).
Decide what you are going to do if you have reached a progression limit, or a bankroll stop/loss point etc.

Place the Bets - the fun bit ! (Also - we won't be doing this if we're still qualifiying)


If you have a very simple system, then you might not need to qualify or initialise, but you will always need to track the win/loss and place the bets.
Notice that you have to track your win/loss before you place the bets. If you don't do it in this order, things will go awry.

So... let's start with a simple system again. How about betting on 2 dozens, with a loss point of -100 and a profit stop point at +50...

This system does not have any initialisation or qualifying to do - we're not using a progression or tracking spins,
so we only need two of our modules - 'check win/lose' and 'place bets'.

The first thing to do is to open up your editor and select 'file' then 'new'.
It brings up a default program which we are going to clear completely. Just wipe the thing out, so you are left with a completely blank screen.

The very first thing you have to do in RX is tell it what your system is.
This is compulsory in the programming language.
Very easy - simply type system "Two Dozens" and press Return. (Each command in RX needs to start on a separate line.)

You can call it anything you like, but this is always the first command on any new system.

The next thing we do is place the compulsory module. In RX, modules are called 'methods'.
Each 'method' has a name, and 2 commands that follow it :
begin and end. All you do is place your commands inbetween the begin and end, and RX will run through them.

You might find it easier to read if you double-space some of your programming,
but that's entirely up to you; you can leave as many blank lines as you like between one bit of code and the next.

So... we need to put in the compulsory bit - method "main" - This is the routine that RX runs through every time you do a spin.
It runs the code that you have put between the 'begin' and 'end' that every 'method' command must have.
If you don't have a 'main' method, the compiler will get very upset with you and sulk. Once you have that 'main' method,
you can add as many methods as you like. But...remember...
RX will only run the code inbetween the 'begin/end' of method 'main' so you will have to tell it to run off and execute your other methods.
Again, more on that later.

Add the 'begin' command below the 'method' command.

Now remember that we are going to use two modules from the system building 'kit' - check win/lose and place bets.
We are going to program these using the 'method' system, but we need to tell RX to run off and do them.

This is done using the call command. The structure is worth noting - you would use something like call "Check Win/Lose";.
You then have to add a 'method' with the name 'Check Win/Lose" somewhere in your program, complete with its own begin/end sequence.
Also note the semi-colon after the name of the method in quotes.
This will come to annoy you all as much as it annoys me - note that it is not required when you create a new method, but is required when you call one !

Now we need to add the call to the 'Place Bets' module.

call "Place Bets"

And that's it. Ah, but we've forgotten one thing. Each method has a begin, and an end.
This is all we want to do with our system on every spin, so let's end method "main" with the 'end' command.

Your code should look something like this :

Code:
system "Two Dozens"

method "main"
begin

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

end

Now just to see what happens, 'Validate' the system.
This is found under 'Options' then 'Validate Design'.
This basically scans your system for errors and, if none are found, it turns your system into ultra-fast machine code for kicking the casino's ass  

Aha though.... an error message. The offending line is highlighted in red and a message at the bottom gives us some clue as to what we've done wrong:

Method "CHECK WIN/LOSE" is NOT found in System, but is used in an Action 'CALL' statement.

Yep - it's telling us we haven't put the 'methods' in for the rest of the system. OK...., let's do it.

Add the "Check Win/Lose" method after the last 'end' statement. Again, very simple - method "Check Win/Lose" - it also needs its 'begin' statement too.

All we're doing here is placing our stop/loss code (there's no progression) so let's have a look at that.
RX has built in 'variables' which hold certain values. One of them is called 'bankroll' and, strangely enough, holds the value of the current bankroll.

If we were being advanced, we could store the starting bankroll at the start of the system and then compare it with the current value,
but for now we'll assume we start with a fixed bankroll of 500 units.

By Magnox from VIP
Time to open up your RX 2.0, stop playing with the sample systems that came with it, and start making your own.
I have only just upgraded to this version myself, so it's as much of a learning curve for me as everyone else.
Which means - there may be some errors !
Hopefully, I'll be able to keep them to a minimum, but if anyone sees anything obviously wrong, or has a better way to do it, then don't be shy....

RX2 is very different from the previous incarnations - you are now faced with a fairly scary looking editor and a proper programming language.
However, don't be put off - you've paid the money for it, so let's use it !

RX2 now uses a language that promotes a system of 'routines' which, when assembled, complete your system.
This makes it very easy to build up your system in stages.

In my experience there are only ever four things you need to do build a system.
Sometimes less, but never more. Think of them as 'modules' that need to be programmed into your system.

All systems that I can think of have these 'modules':



Initialise - (set up progressions, lists of numbers to bet, etc - anything you only want to do once at the start of the system)

Qualify - (track numbers, wait for a certain amount of spins, whatever you need to to)

Check if we've Won or Lost the last spin (if applicable - there is no need to be doing this whilst we're still qualifying - more on that later.).
Decide what you are going to do if you have reached a progression limit, or a bankroll stop/loss point etc.

Place the Bets - the fun bit ! (Also - we won't be doing this if we're still qualifiying)


If you have a very simple system, then you might not need to qualify or initialise, but you will always need to track the win/loss and place the bets.
Notice that you have to track your win/loss before you place the bets. If you don't do it in this order, things will go awry.

So... let's start with a simple system again. How about betting on 2 dozens, with a loss point of -100 and a profit stop point at +50...

This system does not have any initialisation or qualifying to do - we're not using a progression or tracking spins,
so we only need two of our modules - 'check win/lose' and 'place bets'.

The first thing to do is to open up your editor and select 'file' then 'new'.
It brings up a default program which we are going to clear completely. Just wipe the thing out, so you are left with a completely blank screen.

The very first thing you have to do in RX is tell it what your system is.
This is compulsory in the programming language.
Very easy - simply type system "Two Dozens" and press Return. (Each command in RX needs to start on a separate line.)

You can call it anything you like, but this is always the first command on any new system.

The next thing we do is place the compulsory module. In RX, modules are called 'methods'.
Each 'method' has a name, and 2 commands that follow it :
begin and end. All you do is place your commands inbetween the begin and end, and RX will run through them.

You might find it easier to read if you double-space some of your programming,
but that's entirely up to you; you can leave as many blank lines as you like between one bit of code and the next.

So... we need to put in the compulsory bit - method "main" - This is the routine that RX runs through every time you do a spin.
It runs the code that you have put between the 'begin' and 'end' that every 'method' command must have.
If you don't have a 'main' method, the compiler will get very upset with you and sulk. Once you have that 'main' method,
you can add as many methods as you like. But...remember...
RX will only run the code inbetween the 'begin/end' of method 'main' so you will have to tell it to run off and execute your other methods.
Again, more on that later.

Add the 'begin' command below the 'method' command.

Now remember that we are going to use two modules from the system building 'kit' - check win/lose and place bets.
We are going to program these using the 'method' system, but we need to tell RX to run off and do them.

This is done using the call command. The structure is worth noting - you would use something like call "Check Win/Lose";.
You then have to add a 'method' with the name 'Check Win/Lose" somewhere in your program, complete with its own begin/end sequence.
Also note the semi-colon after the name of the method in quotes.
This will come to annoy you all as much as it annoys me - note that it is not required when you create a new method, but is required when you call one !

Now we need to add the call to the 'Place Bets' module.

call "Place Bets"

And that's it. Ah, but we've forgotten one thing. Each method has a begin, and an end.
This is all we want to do with our system on every spin, so let's end method "main" with the 'end' command.

Your code should look something like this :

Code:
system "Two Dozens"

method "main"
begin

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

end

Now just to see what happens, 'Validate' the system.
This is found under 'Options' then 'Validate Design'.
This basically scans your system for errors and, if none are found, it turns your system into ultra-fast machine code for kicking the casino's ass  

Aha though.... an error message. The offending line is highlighted in red and a message at the bottom gives us some clue as to what we've done wrong:

Method "CHECK WIN/LOSE" is NOT found in System, but is used in an Action 'CALL' statement.

Yep - it's telling us we haven't put the 'methods' in for the rest of the system. OK...., let's do it.

Add the "Check Win/Lose" method after the last 'end' statement. Again, very simple - method "Check Win/Lose" - it also needs its 'begin' statement too.

All we're doing here is placing our stop/loss code (there's no progression) so let's have a look at that.
RX has built in 'variables' which hold certain values. One of them is called 'bankroll' and, strangely enough, holds the value of the current bankroll.

If we were being advanced, we could store the starting bankroll at the start of the system and then compare it with the current value,
but for now we'll assume we start with a fixed bankroll of 500 units.
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)


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 nor

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


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..  :-?

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 ?


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 !

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

Remember to change this in your Betting Options from the main RX screen or the program won't hit the stop/loss properly.
We'll move on to being cleverer with starting bankrolls later.

So... at 400 units, we stop. At 550 units, we stop.

In RX 1.5, they used the word 'while' to mean 'if'. Happily, in RX2, you can use either, but I prefer 'if' because it reads more like English.

Now each 'If' command also has a begin/end associated with it.
You can see that once we start racking up big systems there are gonna be a helluva lot of begins and ends flying about and it is really easy to lose track of them !

My tip is to indent them, as they appear, by one tab each time. This way you can easily see that each 'begin' command has an associated 'end' command.
Once you start indenting, the editor will helpfully indent the rest of the code for you automatically (an option that can be turned off in editor options). The code below will show it much better than I am explaining it !

To do comparisons in RX2, we use standard mathematical notation. 'Greater Than' is '>', 'Not Equal To' is <>, 'Less than or equal to' is '<='.
If you're not sure, the help file in RX will tell you what symbols you should use.

So... we need to check our bankroll.

Code:
system "Two Dozens"

method "main"
begin

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

end

method "Check Win/Lose"
begin

if bankroll > 550 units
   begin
   stop session
   end

if bankroll < 400 units
   begin
   stop session
   end

end



There is a deliberate mistake in that code - type it in as written and then validate it again.
Damn those semi-colons... you need one at the end of the 'stop session' command,
which does exactly what you would expect it to - ends the current betting run.
You will be seeing the semi-colon error message a lot ! Note, also, that the words 'units' up there are not compulsory, but can be added,
if you like, to make the thing more readable. Anyway, add the semi-colons and then we can do the last bit.

OK... add the 'Place Bets Method'

The command in RX for placing bets or storing numbers, any kind of 'doing' is 'put'.
There are a lot of options with 'put', and it is roughly equivalent to RX1.5's 'bet' command.
The companion commands of 'put' are 'add' and 'subtract'.

'Put' basically over-writes whatever was there before.
If you did the following two lines - put 4 units on black and then put 1 unit on black - you would only get 1 unit on black.
The 4 units would be over-ridden. In order to get 5 units on black, the second command would be add 1 unit on Black. Subtract works the same way.

The command is very straightforward and reads like English:

put 1 unit on 1st Dozen;

(Note - damn semi-colon again !)

Add the command for the 2nd Dozen, finish off the method with an end statement and that's it !

(Just for fun, change the 'put' command to an 'add' command - this will make the system bet 1 unit on the 1st spin, 2 on the 2nd, 3 on the 3rd - surprising how often it wins, but you will see the obvious flaw  )

Code:
system "Two Dozens"

method "main"
begin

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

end

method "Check Win/Lose"
begin

if bankroll > 550
   begin
   stop session;
   end

if 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



A final word on the 'methods'. RX only ever runs through the code in method "main". Once it hits that 'end' statement it goes back up to the start of method "main". When you 'call' another method, RX jumps to the line that has the same name... once it reaches the 'end' statement, it jumps back to the line BELOW the 'call' command that has just been executed.

Just to confuse things even further, this system does not need have to separate methods for checking wins/losses and placing bets. You could put all the code in the method "main" section - try it and see.

However, once we get onto more complicated systems, it is much easier to program the system in 'modules' which is why I'm going down this route of breaking up the system into individual parts. If you start off programming like this, then complicated systems will be an easy learning progression.... if you start off with bad programming practice, it will be difficult to unlearn later on !

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 !


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


See what I mean about indenting the 'begins' and 'ends' ? If you don't do it, it starts to get very messy. This is now very much easier to do than in 1.5 because you can simply cut and paste one block and modify it to make the other two.

Finally, we have 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

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

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



end




The next post below will deal with the progressions. In order to be able to understand how progressions will work, you will have to be familiar and comfortable with the data records in RX2, how to create them, access them, and make comparisons with them, so have a good digest of the above before carrying on !

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

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.

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.

By Magnox from VIP
I have received an email from UX software outlining some improvements they are making to the new version of RX - 2.0.13. In this tutorial I was going to look at advanced tracking - perhaps getting all the sleepers from 37 spins and then applying a system to them, that kind of thing, but the improvements to the language are so powerful that I would be wasting your time going through the current method of doing this. When the new version is released, what is currently 20 lines of programming will become one - very useful for people whose systems track numbers, streets, whatever.

Instead, I thought we'd consolidate what we've done so far - data records, flags, methods, methodology.... To that end, we'll look at how I translate a system from paper into RX - it doesn't mean that it's the only way of doing it, or the best way, but if you are new to the language or struggling with certain elements of it, perhaps this will help. What we'll also do is add a front-end on to this system. The 'Front-End' allows you, in standard Windows presentation, to select what cash value a unit has, how many times to wait until x has hit or not hit, whether or not to apply a certain rule to the system. Drop-down boxes, check-boxes, numerical entry - we can do it all in RX, and it saves you going back into the program every time you want to fine tune your system.

We'll look at SnakeEyes' system which he posted here:

nolinks://gambling.projectsydney.com/viewtopic.php?t=605


What you need to do is summarise your system into easily programmable stages: With this system, we always bet for 10 spins, regardless of the result. If we are up at the end of the 10 spins, we switch colour and start betting again, with 1 unit, noting the new bankroll as a minimum. If we are down, we stay on the same colour and double the units bet. If we are even, we stay on the same colour with the same units.

I look at it like this:

1 - Set the units we bet to 1
2 - Spin 10 times on Red/Black as applicable
3 - Bankroll Result
Up - Store new bankroll; switch colour to Black/Red - goto stage 1
Down - stay on same colour - multiply units by 2 - goto stage 2
Even - stay on same colour - goto stage 2


Looking at our standard system template - Initialise, Qualify, Check Win/Lose, Place Bets - there are really only 2 modules we are going to use - Initialise and Place Bets.

What we'll do in the Place Bets module is this:

We'll count the spins. Before we actually place the bets, we'll check to see if we're up to ten spins - if we are, we'll check what colour and what units we should be betting with, and change them accordingly. Then we'll set the spin counter back to zero.

Simple, really, but you need to develop a method of looking at paper systems as a set of logical instructions that can be programmed into RX.

To start with then - our standard, non-qualifying 'main' method:

Code:
system "10 Spins"

method "main"
begin

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


end

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


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

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

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



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

By Moch from VIP
You can only post 10000 characters so you have to put part 1 and part 2 thogheter and copy and paste it into RX

Part 1

system "Streak Viewer v1.0"
{
*************************************
*            Idea by Moch
*         on the VIP Lounge
*       Roulette Extreme Coders
*               :Moch
*               :
*************************************
           TO-DO :
1)Record pocket distances

}

method "main" begin
   // start up
   while starting new session begin
       Clear all records
       call "Init"
       call "WheelType"
       exit
   end
   
   copy last number record"LastN"layout
   
   if record"Type"data = 1 begin
       call "Record Red-Black"
   end
   if record"Type"data = 2 begin
       call "Record Dozens"
   end
   if record"Type"data = 3 begin
       call "Record Double Streets"
   end
   if record"Type"data = 4 begin
       call "Record Finals"
   end
   if record"Type"data = 5 begin
       call "Record 4 Sectors"
   end
   if record"Type"data = 6 begin
       call "Record Positional"
   end
   if record"Type"data = 7 begin
       call "Record Streets"
   end
end

// Methods
method "Init" begin
   // defaults
   put 1 record"Spins"data
   put 0 record"TotalSpins"data
   put 1 record"Wheel"data
   // Input
   group begin
       display "Streak Viewer by Moch"
       display "This is a simple tool created to help streak analysis
                Open the Statistics/Data Record window, and you
                will see the outcome transformed: i.e.
                Dozens will appear as 1,2,3,
                Red as 1 Black as 2,
                Double Streets as 1,2,3,4,5,6
                Use the splitter to view data in groups of 1,2,3 etc
                You can also EXPORT this data to Excel
                Note: Finals, 4 Sectors, Positional are not 00-compatible

                "
                 
           input dropdown " View  ?
           1:= Red-Black
           2:= Dozens
           3:= Double Streets
           4:= Finals
           5:= 4 Sectors
           6:= Positional
           7:= Streets" record"Type"data
       display "
               "
   end
   // flags
   // assign
   // call once
   if record"Type"data = 4 begin
       call "Setup Finals"
   end
   if record"Type"data = 5 begin
       call "Setup 4 Sectors"
   end
end


// Recording Methods
Method "Record Red-Black" begin
   if red hit each begin put 1 record"Red-Black Data"data end
   if black hit each begin put 2 record"Red-Black Data"data end
   add 1 record"Red-Black Data"data index

end

Method "Record Dozens" begin
   if 1st dozen hit each begin put 1 record "Dozens Data" data end
   if 2nd dozen hit each begin put 2 record "Dozens Data" data end
   if 3rd dozen hit each begin put 3 record "Dozens Data" data end
   add 1 record "Dozens Data" data index
end

Method "Record Streets" begin
   if street(1-3) hit each begin put 1 record "Street Data" data end
   if street(4-6) hit each begin put 2 record "Street Data" data end
   if street(7-9) hit each begin put 3 record "Street Data" data end
   if street(10-12) hit each begin put 4 record "Street Data" data end
   if street(13-15) hit each begin put 5 record "Street Data" data end
   if street(16-18) hit each begin put 6 record "Street Data" data end
   if street(19-21) hit each begin put 7 record "Street Data" data end
   if street(22-24) hit each begin put 8 record "Street Data" data end
   if street(25-27) hit each begin put 9 record "Street Data" data end
   if street(28-30) hit each begin put 10 record "Street Data" data end
   if street(31-33) hit each begin put 11 record "Street Data" data end
   if street(34-36) hit each begin put 12 record "Street Data" data end
   add 1 record "Street Data" data index
end

Part 2

Method "Record Double Streets" begin
   if line(1-6) hit each begin put 1 record "Double Street Data" data end
   if line(7-12) hit each begin put 2 record "Double Street Data" data end
   if line(13-18) hit each begin put 3 record "Double Street Data" data end
   if line(19-24) hit each begin put 4 record "Double Street Data" data end
   if line(25-30) hit each begin put 5 record "Double Street Data" data end
   if line(31-36) hit each begin put 6 record "Double Street Data" data end
   add 1 record "Double Street Data" data index
end

Method "Record Finals" begin
   if record"LastN"layout found in Record "1" Layout begin put 1 record"Finals Data"data end
   if record"LastN"layout found in Record "2" Layout begin put 2 record"Finals Data"data end
   if record"LastN"layout found in Record "3" Layout begin put 3 record"Finals Data"data end
   if record"LastN"layout found in Record "4" Layout begin put 4 record"Finals Data"data end
   if record"LastN"layout found in Record "5" Layout begin put 5 record"Finals Data"data end
   if record"LastN"layout found in Record "6" Layout begin put 6 record"Finals Data"data end
   if record"LastN"layout found in Record "7" Layout begin put 7 record"Finals Data"data end
   if record"LastN"layout found in Record "8" Layout begin put 8 record"Finals Data"data end
   if record"LastN"layout found in Record "9" Layout begin put 9 record"Finals Data"data end
   
   if record"LastN" layout not = number 0 and
       record"LastN" layout not = number 00 begin
       add 1 record"Finals Data"data index
   end

end

Method "Record 4 Sectors" begin
   copy last number record"LastN" layout
   if record"LastN" layout found record "sector1" layout begin
       put 1 record "4 Sector Data" data
   end
   if record"LastN" layout found record "sector2" layout begin
       put 2 record "4 Sector Data" data
   end
   if record"LastN" layout found record "sector3" layout begin
       put 3 record "4 Sector Data" data
   end
   if record"LastN" layout found record "sector4" layout begin
       put 4 record "4 Sector Data" data
   end
   if record"LastN" layout not = number 0 and
       record"LastN" layout not = number 00 begin
       add 1 record "4 Sector Data" data index
   end
   
end

Method "Record Positional" begin
   copy last number record"LastN" layout
   if record"LastN"layout=number 32 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 15 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 19 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 4 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 21 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 2 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 25 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 17 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 34 begin put 1 record"Positional Data" data end
   if record"LastN"layout=number 6 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 27 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 13 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 36 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 11 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 30 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 8 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 23 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 10 begin put 2 record"Positional Data" data end
   if record"LastN"layout=number 5 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 24 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 16 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 33 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 1 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 20 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 14 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 31 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 9 begin put 3 record"Positional Data" data end
   if record"LastN"layout=number 22 begin put 4 record"Positional Data" data end
   if record"LastN"layout=number 18 begin put 4 record"Positional Data" data end
   if record"LastN"layout=number 29 begin put 4 record"Positional Data" data end
   if record"LastN"layout=number 7 begin put 4 record"Positional Data" data end
   if record"LastN"layout=number 28 begin put 4 record"Positional Data" data end
   if record"LastN"layout=number 12 begin put 4 record"Positional Data" data end
   if record"LastN"layout=number 35 begin put 4 record"Positional Data" data end
   if record"LastN"layout=number 3 begin put 4 record"Positional Data" data end
   if record"LastN"layout=number 26 begin put 4 record"Positional Data" data end
   if record"LastN"layout not = number 0 and  record"LastN"layout not = number 00 begin
       add 1 record"Positional Data" data index
   end
   
end
// END Recording Methods

// Setup Methods
Method "Setup 4 Sectors" begin
   put 4 neighbor count
   Copy Neighbors of number 21 to record "sector1" layout
   set max record "sector1" layout index
   copy number 21 to record "sector1" layout
   
   Copy Neighbors of number 11 to record "sector2" layout
   set max record "sector2" layout index
   copy number 11 to record "sector2" layout
   
   Copy Neighbors of number 1 to record "sector3" layout
   set max record "sector3" layout index
   copy number 1 to record "sector3" layout
   
   Copy Neighbors of number 28 to record "sector4" layout
   set max record "sector4" layout index
   copy number 28 to record "sector4" layout
end

Method "Setup Finals" begin
   Copy List [number 1,number 10,number 19,number 28] to Record "1" Layout
   Copy List [number 2,number 11,number 20,number 29] to Record "2" Layout
   Copy List [number 3,number 12,number 21,number 30] to Record "3" Layout
   Copy List [number 4,number 13,number 22,number 31] to Record "4" Layout
   Copy List [number 5,number 14,number 23,number 32] to Record "5" Layout
   Copy List [number 6,number 15,number 24,number 33] to Record "6" Layout
   Copy List [number 7,number 16,number 25,number 34] to Record "7" Layout
   Copy List [number 8,number 17,number 26,number 35] to Record "8" Layout
   Copy List [number 9,number 18,number 27,number 36] to Record "9" Layout
end

// Misc. Mehtods
method "WheelType" begin
   if record"Wheel"data=1 begin Load Single Wheel end
   else begin Load Double Wheel end
end
// END Misc. Mehtods

By Magnox from VIP

What you need to do is summarise your system into easily programmable stages: With this system, we always bet for 10 spins, regardless of the result. If we are up at the end of the 10 spins, we switch colour and start betting again, with 1 unit, noting the new bankroll as a minimum. If we are down, we stay on the same colour and double the units bet. If we are even, we stay on the same colour with the same units.

I look at it like this:

1 - Set the units we bet to 1
2 - Spin 10 times on Red/Black as applicable
3 - Bankroll Result
Up - Store new bankroll; switch colour to Black/Red - goto stage 1
Down - stay on same colour - multiply units by 2 - goto stage 2
Even - stay on same colour - goto stage 2


Looking at our standard system template - Initialise, Qualify, Check Win/Lose, Place Bets - there are really only 2 modules we are going to use - Initialise and Place Bets.

What we'll do in the Place Bets module is this:

We'll count the spins. Before we actually place the bets, we'll check to see if we're up to ten spins - if we are, we'll check what colour and what units we should be betting with, and change them accordingly. Then we'll set the spin counter back to zero.

Simple, really, but you need to develop a method of looking at paper systems as a set of logical instructions that can be programmed into RX.

To start with then - our standard, non-qualifying 'main' method:

Code:
system "10 Spins"

method "main"
begin

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


end

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

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

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

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

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

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 ?

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 !

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

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.

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

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

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

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)

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 !

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

See what I mean about indenting the 'begins' and 'ends' ? If you don't do it, it starts to get very messy. This is now very much easier to do than in 1.5 because you can simply cut and paste one block and modify it to make the other two.

Finally, we have 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

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

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



end




The next post below will deal with the progressions. In order to be able to understand how progressions will work, you will have to be familiar and comfortable with the data records in RX2, how to create them, access them, and make comparisons with them, so have a good digest of the above before carrying on !