OK, testing it.

Sure, I'm currently compiling it under VB.NET for Pockets and Stef.

File must be named:

TextBox_Connector.exe

By all means let's move to VB6!

---

Can you please replicate this itsy-bitsy form in VB6?

Just a textbox with the word "input" in it.

[attachimg=1]

---

This is a most-generic connector, works in every programming language capable of using a Textbox (99.9% of all GUI-capable languages! )

Quote from: esoito on January 15, 2014, 04:23:15 AM
There's a problem right away.  No idea how to do that.

Reading from here:

http://justbasic.conforums.com/index.cgi?board=novice&action=display&num=1175250727

It seems that justbasic isn't too easy when dealing with GUI. I find the code a somewhat messy. Guess I'll have to make the GUI code myself first to try.

Hooking into console mode can prove a long winding road. Internally, a Textbox is just a window which can be referred to by handle and "messed with" more easily via standard windows messages.

Quote from: esoito on January 15, 2014, 04:15:35 AMAnd what of 'bot mode'?

Yes, it's supported. The connector itself is NATIVE to the framework, which means it allows the foreign program to work as a tracker, tester, clicker and bot 

I have a very straightforward input-only connector ready. The output part is actually more cumbersome to work with (but we'll get there).

When you have time please make a GUI program with a TextBox with the word "input" in it.

You receive the last number from the framework in the TextBox and make as you wish with it.

Yes, the whole idea of the connector module is to "fake" it as being just another native framework module, loading equally, doing the same input/output routines so it becomes part of it.


This way disparate technologies can work seamlessly.

OK, starting right now, our official BetSoftware bundle releases are paid

Well max, this is a risk I'm going to take for the sake of my own tranquility and productivity.

Operating closed-source, keeping technologies as secrets, treating your users like thieves and worsening their usage experience in the name of retaining exclusive rights is actually more work and burden for the programmer.

I'll just ditch it away to focus on what interests me: developing.

I know appreciative supportive users and fellow developers are going to be happy. That's enough for me.

I'm thinking and rethinking about what's the best way to thwart piracy from day one, and the more I think of it, the more I realize the best movement is to give away the programs in source form to the community. This way -since I have a tradition of not using piracy protections in my programs anyway- we just can't tell who's pirating and who's not.

I respect my users enough not to accuse them of pirating right-up. (But yes, I know the realities of the world).

"El Cheapo" users who think $2.99 is one arm and one leg will go to extremes to get the software for free. I don't think those users are inherently evil, they are just, well, "cheapos".

Other users think everything should be free as it is their god-given right to never pay for anything. Developers should be paupers working for free all day long, and every attempt to monetize is seen with disgust by them... Out of any doubt this group are good to spend time learning how to compile the programs, for a change.

The official fair use of the programs' source code is to enable other developers to learn and contribute their twists/improvements -if so they wish-.

With regular commercial software you get absolutely nothing if you don't pay, so this way of distributing our sources is giving the community an unbelievably higher amount of benefit than purely commercial, the whole program to fiddle with, unrestricted. I can't effectively take any program back once it's source code is published in the open.

The programs as they stand right now were made at the most odd hours at night and aren't formatted any pretty, they just work for me in my development machine, which is perfectly OK for me.

I don't give my project files though, only the raw source code and bare resource files; like I mentioned, those interested in the source code for fair-use purposes will entirely rejoice to see this published online. On the other hand, everyone can rest assured that not having an ordered main project file won't stop "El Cheapo" users from spending the time making their own builds. Hopefully, those users can eventually become program fiddlers themselves, learning in the process. I'm not against that. In fact, I like the prospect of helping others learn.

Hardcore freebie hunters will inevitably find their way too.

In the end, there's something for everyone. Conscious users are going to support and I'm happy to foster the advancement of our community and making something that directly helps me and my family.

I promise not to ask anyone whether his copy has been paid or not, but I hope others will have the decency of not openly telling the world they are skimming off my work.

"Don't ask, don't tell"

One last tip on this. Another option for a rule of thumb to reset back is to simply use the payout (multiplying * 36).

i.e. after a hit, you check the current amount of deficit from last high and use:

1-36 = 1.1.1.1.1.1.1.1.1
37-72 = 2.2.2.2.2.2.2.2.2
73-108 = 3.3.3.3.3.3.3.3.3
109-144 = 4.4.4.4.4.4.4.4.4
145-180 = 5.5.5.5.5.5.5.5.5

and so on.

It doesn't always recover in full, but the goal with the ATILA isn't to recover everything in one hit as much as keeping exposure low.

Notice the ATILA is based on the cyclical nature of the win/lose streaks.

It aims to rise the bets slowly in order to take advantage of the natural clumping of wins when they come, rather than betting the farm on a single spin.

---

After a hit, you can "level" your bets down by keeping an eye on the amount needed to break even.

i.e. if after your last hit your deficit is -24, you can go back to:

1.1.1.1.1.1.1.1.1

Since one hit with 1 unit would recover, and the whole idea is to keep your bets low.

---

Likewise, if after last hit you are at -45, you can go back to:

2.2.2.2.2.2.2.2.2

and so on.

Always going back to the very least unit exposed as needed to break even.

9 numbers call for ATILA.

I suggest you try the reversed ATILA where you rise +1 on only one of the 9 numbers on a win, and hold the bet until a new hit, after which you rise +1 on a second single number, holding the bet until another hit...

You reset when a hit brings your balance to a new high (or break even).

---

The sequence goes like this:

1.1.1.1.1.1.1.1.1
hit
2.1.1.1.1.1.1.1.1
hit
2.2.1.1.1.1.1.1.1
hit
2.2.2.1.1.1.1.1.1
hit
2.2.2.2.1.1.1.1.1
hit
2.2.2.2.2.1.1.1.1
hit
2.2.2.2.2.2.1.1.1
hit
2.2.2.2.2.2.2.1.1
hit
2.2.2.2.2.2.2.2.1
hit
2.2.2.2.2.2.2.2.2
hit
3.2.2.2.2.2.2.2.2
hit
3.3.2.2.2.2.2.2.2
hit
3.3.3.2.2.2.2.2.2
hit
3.3.3.3.2.2.2.2.2

and so on. Rising +1 on one number at a time.

Thanks for sharing this with us OZ 

Quote from: esoito on January 12, 2014, 01:02:43 AM
It ran fine under:

XP + SP3 with Netframework 2,3 and 3.5 installed.

Awesome news Max, wonderful report. Thanks for taking the time to try all those framework versions.

Quote from: esoito on January 12, 2014, 01:02:43 AMThe balance often showed a negative amount but never a positive amount!  At this stage of development is that OK?

Remember this BetSoftware is MODULAR, which means it is comprised of tiny isolated programs working together, totally unaware of each other.


In the case of proof's module, it's strictly a bet selection module, which isn't concerned with tracking bankroll balance for the session but that's OK, soon enough balance-tracking modules are to follow suit.

Chances are after we go paid on the 15th development pace accelerates and modules are released at a good pace throughout the month.