REQUEST: MANUAL SYSTEM-ASSEMBLING INTERFACE

[HardMan]

Vic, some of us are not coders .. thereof it might be useful for the RIBOT to have a manual interface =

a module whereby clicking on predefined options one might assemble a system lego-blocks alike .. & then potentially pit = several such blocks as/in a sequence, making a system more complex.

[HardMan]

The brief example is presented here, made by @FreeRoulette
http://roulette.epizy.com/calc/?I=1

[HardMan]

In essence, we shall be able to

• create & define various betting modules = betting blocks -- parameters: select/define number of positions, pertaining payout & units amount per each position + display the resulting payout for each position hit, as separate value including the units returned upon hit .. according to the vertical stake
• how these blocks interchange -- parameters: exposition amount, hit
• determine how these blocks are executed - exact positioning of the predefined placement) -- it might be important to allow for the determination of these as liberty to opt for a user to modify them either .. within the modules above (on a spin-per-spin basis, simultaneously as defining the block parameters) .. &or as a separate module containing instructions, as universally transposed & applied onto all other modules (aka bet selection module)
  
  
  
  

[HardMan]

•

• make the interface navigation intutive

/

Here is the text brief, on how to expand on the already-designed idea (quoted has been modified)

That's a wow!

Playing lego, inputting betting blocks & assembling a system.
Top-level interface for non-coders.


However more complex .. with more parameters included --
•  option to line up multiple positions & various types per spin  (combining various payout types) as well
•  add the 'hit' condition.. if no-hit, continue running one module  eg. multiple positions block); when hit, change to another program  eg. run one position, quantified with the parameters of payout, type, units .. geared at +1 & auto-adjusted on each spin of such a block, & the number of spins as well (.. till reverting to multiple position block -- parameter: hit, no-hit)
•  etc.

What I had in mind is multiple & various positions on each spin ... aka 12 numbers ... can be played with a DZ or CL, 2DS, 3Q, 4ST; I might as well opt to bet 2Q+2ST, 3Q+ST, 3ST+Q, 2Q+ST, 2ST+Q, 2Q, 2ST, 2DS, 3DS, DS+Q, 2DS+Q ....


Then, as another module, conditioning on the exact execution of the betting blocks modules, would be to define the bet selection too:

parameters: numbers out (=actives), exposition amount

.

As one parameter --  eg. based/contingent on the recent numbers out = fresh wave ≈ last outcome (refined with payouts);

That way.. progressing through payout based on the exposition (locus in the game), I would bet more & more actives, & fewer & fewer unhit .. with more & more finesse.

Exposition parameters:
defining which bs subset gets put in place & executed = various exposition ranges or thresholds.

.

For the spin positions' outcome; its simple .. the 'default positions' payout' minus 'the number of positions minus 1)
eg. 2Q+2ST
Q = 8:1 (+8) → 3 extra positions =  +8-3*1 (+5) = simply 5:1,
then potentially multiplied with the vertical units stacked.

.

Yes, as for multiple programs, or interchanging modules; one default program would be wide (multiple positions) running & continuously & reverted till a game in +, on hit focused (single position) as a several spin interrupt -- that's presented a bit simplified, but in a nutshell .. that's it.

[/list][/list]

[FreeRoulette]

I'm trying to visualize the idea. We have these components.

1. Money
2. Payout ratio
3. Bet location
4. Bet lists
5. Conditions

MONEY
Profit counters on lists, or overall profit, could determine if the list changes or resets.

PAYOUT Ratio
Not sure why someone would change this, but could be an option.

BET Location
Bet locations can be predefined or user entered numbers for groups. The user will select the bet to be added to a bet list. Multiple bets can be added per spin.

BET Lists
These are sequences that play out depending depending on conditions. They can reset the list, or move to a different list based on a condition.

CONDITIONS
This is the hardest part of the whole process. If a number loses, they want replay it, unless the profit is negative and they want restart the list, unless it also hits this xyz group of numbers and they want it to play the other list, but now they want to play two lists at one time. This will have to be well thought out what the possibilities can be. Maybe just start out with couple and add to it later.

 

[FreeRoulette]

Maybe the conditions could be like this to start out.

The bet in the list will have win and loss condition which have two actions.

1. Change the bet
   - Increase by x amount
   - Decrease by x amount
   - Increase to keep profit (up to table limit to avoid an infinite loop)
2. Change the bet location.
   - Same bet
   - Next Bet
   - Change List (could select the same list)

The list will also have actions

1. End of list
   - End program
   - Change list

2. Profit (within the list, while running the list)
   - End program
   - Change list

2. Loss (within the list, while running the list)
   - End program
   - Change list

[VLS]

In essence, we shall be able to

• create & define various betting modules = betting blocks -- parameters: select/define number of positions, pertaining payout & units amount per each position + display the resulting payout for each position hit, as separate value including the units returned upon hit .. according to the vertical stake
• how these blocks interchange -- parameters: exposition amount, hit
• determine how these blocks are executed - exact positioning of the predefined placement) -- it might be important to allow for the determination of these as liberty to opt for a user to modify them either .. within the modules above (on a spin-per-spin basis, simultaneously as defining the block parameters) .. &or as a separate module containing instructions, as universally transposed & applied onto all other modules (aka bet selection module)
  

Perhaps this is best served by a single dynamic betting module?

I'm trying to visualize the idea.

By all means do expand as much as you wish! Your input is valued 👍

[HardMan]

Important fact that I emphasize is to create a very intutive interface, where anyone including non-coderd can code/design system by simple push of buttons ..

given that there's proportionally in majority, vastly more non-coders tham coders, this improves the accessibility of/to the bot & increases/expands the potential user-base by a lot;

needless to mention, by removing the dependability on coders, decreases the manhours you Vic & few others would have to dedicate to honor & complete all the request + enrich the bot's systems repository (provided there's an incentive to upstream).

=scalability.

[HardMan]

There's definitely ways .. how to do this under the hood;
the way I see it, when we are talking about lists, or even a singular-list approach:

there should be a way that allows to design the bets sequence according to any or few major parameters, being anchored to .. or revolving around it -- irregardless, on the same screen!!

& potentially, as well, with the eg. 'NEXT BET' button, opening the next screen .. just like Android apps work, meaning the core-mechanism, hmm .. interactive pages of book.

Then "FINALIZE" the singular-list, & if opted for that way, potentisally create more lists, inytegrating them congruently.

Anyway, the main point here is -- irregardless which revolving-parameter we opt for the interface design shall allow for both (exposition, bet selection), as well as when shifting through bet/pages.

.

In essence, the interface =pushing of buttons, defines &or modifies the only thigs we (have in) control -- coverage + units placed -- these, as first principles are composed of

• bet types
• number of positions
• units per position .. or spin placement

These can be viewed in many ways

• coverage  =  bet types + number of positions
• units = number of positions (horizontal) + amount per position (vertical, as multiplication of foremost)
  

In short, again, bet types, number of them, potential vertical units placed (on them,per position)

.

Ie.  a multitude of spins, as a congruent & enclosed-sequence (loop), being based & revolving around

• exposition -- let's say, attack as initial spins with one hit to finish requirement -- is usually a set span of spins/bets .. where the bet types & units are predetermined upon (resulting) exposition, with the potential complementing coding parameter = spin outcome (hit, no-hit)
• the above might be true also for closing bets, based firstly on 'protruding rate' = the amount in units or (percentage) exceeding the new high, being nominal profit or something else -- & the bets being adjusted to that, possibly when opting for one position only auto-adjusted
• alternatively, [b[bet selection[/b] -- this as a design-anchor (with potentially its activation parameter being exposition too = threshold) ... the number of positions placed, & their types  placed might revolve around bet selection = actives, or recent numbers out (however far back), & how those actives are determined to be grouped -- as eg. DS, Q or ST .. meaning 27,25,26 or 26,26,27 might be covered with ST, meanwhile 27,26,23 or 24,24,26 with Q
• then, in such case, the complementing coding parameter of exposition or exposition range shall determine the activation of which course of action (sublist), using those bs qeantifying parameters = bet type (eg. -5 till -15) = DS 5:1, after Q--ST 8:1,11:1 .. including opting for the number of positions & their range (eg.1-2,3-4,2-5) corresponding to the actives & their potentialityof being grouped, plus vertical units stacked on each of those

.

Finally, as the main 'system-execution pivoting' coding parameter -- hit, no-hit;

• after having a hit the system might execute a different betting sequence (list) .. or continue with the same tillthe next exposition threshold (above, below)
• or as singular-list, execute a predetemined looped strategy -- eg. closing sequence mentioned above (below attack), or some other .. again contingent on the exposition threshold; or even determine which of those .. based on the actives = does it have sufficient actives, within the same area that hit, & within the set vertical cap .. to constitute the closing bet at that hit .. or, using DS since more actives out that Q would inadequately cover, opt for DS bet .. including the vertical units based on the exposition amount

[HardMan]

That's quite comprehensive.

If smth requires further cleaification, or has to be expanded upon &or I haven't addressed an aspect yet -- shoot.