I’d love if we could get pool operators to update this each new term with the new pool parameters.
That could be very easy if only I received pull request from each pool operator
…and did find out how to accept/include them, lol
I’m still a git noob
As this is still a kind of test whether people like a “universal ALP bot collection” or not, I might be a lesser noob by the time we’ve found out; or I might not need to be a lesser noob - depending on the outcome!
The thing is, I played with so many bots on so many pools that I wanted to have one single place to look at for an up-to-date and hopefully complete set.
As this set wasn’t existing in the way I preferred it, I decided to make it.
The whole collection was built on self-interest combined with the hope someone else might like that idea as well.
More fun with screens^^
The ALP bot collection now has a script to terminate (at least it tries to…) all bots gracefully (to have them delete the orders) in the unix section.
If you have up to 9 bots running and want to gracefully terminate them, you have to attach to the screen, terminate the bot, yada-yada-yada…
…or you use the script!
Here it is:
Obviously It’s part of the experimental branch.
A Windows version of it will likely not follow - I have no clue how to send CTRL+C to a command prompt and confirm the action (at least not without AutoIT - and I’m not going to do that ).
I’m not only a git noob, but a PowerShell noob as well^^ (at least I think it could be possible with PowerShell…).
I think that’s it for now with the ALP bot collection.
Have fun with it!
Send feedback, or suggest improvement if you like.
is there a parameter in conf file in order to set how much of our funds the bot could use in orders?
right now i see it uses full funds.
I’m not aware of such a setting.
But I didn’t dig deep in the inner workings of the bot.
I merely tried to streamline the structure to make it easy getting an up-to-date version of the bots and especially make running multiple bits in parallel more convenient.
I bet a parameter like
reservebalance would be quite easy to be implemented for someone familiar with Python, or the other way round, a maximum value that shall be put into orders.
Or to keep it in line with the concept of liquidity operations a way to tell the bot how much to use for Tier 1 or Tier 2, respectively.
I hope I caught all links in the previous posts…
The repo was renamed. It’s now called “alp-collection” (formerly known as a fork of nu-pool that was called nu-pool).
The most interesting branch of it is not the master (which is hopefully quite stable) but the experimental branch, that can be found here:
The experimental branch contains some scripts that should make using the bots (especially if you intend to run more than one of them) more convenient.
I recently added support for the fixed payout ALP test pool - in the windows and the unix section!
Have fun with it!
New branch for testing available with new features: https://github.com/Lamz0rNewb/alp-collection/tree/nagalim
Details about that are in @Nagalim’s subsequent post.
So this was pulled from an old (but stable) version. I’d like to see if we can pull some of the updates since then into the branch. Things that should happen:
- I’ll remake trading.py and client.py to absorb all the recently discussed changes as well as any updates to the main branch.
- Absorb all other updates to the main branch since I forked.
- Rename restime to reset_timer and wire out fillfactor
- Fix unix directory to take step 2 into account
- Fix the windows directory
This would best be done once I understand how to use github. I’ll give it a shot tonight, but fair warning if I can’t get it all done I won’t be able to work on it this weekend.
Edit: This is totally not going to get done tonight. I’m just going to take my time and try to get comfortable with github first.
Even if you did get comfortable with github I might not be able to handle your pull requests as I’m a github n00b.
If you can point me to adjusted files (trading.py, client.py) I can integrate them manually and we learn how to use github later
Or what about this: you fork https://github.com/Lamz0rNewb/alp-collection/tree/experimental and make the changes. We figure out how to make pull requests later?
ninjaedit: Doh! You already forked it.
I merged MoD’s branch in with my own. I’m almost done getting the client all updated with the main branch, but there’s a conflict about how we name our config files and how the inuitwallet branch labels its config files. This conflict happens in client.py about two lines in to the main routine. Anyway, I’ll get it figured out eventually, but that’s what’s holding me up for now.
Sorry - that was due to my attempt to provide a useful naming structure not knowing about code dependencies…
I like your structure better, I’m just trying to code it so that maybe the others will look at our changes and pull us in. The biggest issue is that to add a config parameter we have to wire it into every single pool, but if each pool can just check to make sure their folders are right then maybe everything will work out without too much work on any one person.
I consider that one of the big advantages - to have independent configuration for each pool!
@woolly_sammoth I found the thing that was tripping me up. Can you explain why there is a ‘not’ in the logical of line 374 here:
As far as I can tell it makes your branch unusable for normal client-side ALP. Deleting that ‘not’ makes it work just fine, and logically it doesn’t make sense to me with the ‘not’ there. It’s not in any of the other case structures following it.
Alright, here you are:
By the way, nothing other than nupond works in there. All the others have the wrong name for ‘restart_timer’ and lack a fillfactor. Fixing this would just require a lot of copy and pasting.
I pulled your changes intp a new branch in my repo called “nagalim”:
and made changes for the other unix bots and the windows bots.
I fear it might confuse users to have yet another branch and intend to merge all the changes soon to the master branch.
It would be nice if somebody could test it before.
I won’t have time for through tests over the weekend.
I’m sorry, you missed the restime -> reset_timer. I can try to add something into the code to accept both if you’d rather.
Oh, also I think we should go to 0.5 hr default reset.
Will fix that later…
…sed will do it in fact
hi, a question related to ask/bid sides.
i see sometimes that an ask or bid side vanishes while running an ALP pair.
do you advise to manually keep the balance of ask/bid sides (every now and then) or leave it to balance it self?
That can happen due to volume beyond target - as far as I understand how ALP works…
no, i didn’t mean due to spread value, i mean due to filling order
i bid 100 and i ask 100 (perfect balance)
the other day, i see that i bid 200 and no ask (due to filling ask order)
then should i let it as it is or should i do some manually balancing?