... | ... | @@ -50,7 +50,7 @@ Example: `buy 0.001 @9000` |
|
|
| **`projectedsize (prs)`** | When you have a long position, adds up your current position size and the total size of your bids. If you are short, adds your current position size to total size of all your offers. |
|
|
|
| **`projectedavg (pra)`** | Calculates the projected average entry after all current bids or offers are hit on the same side as your current position. |
|
|
|
| **--------------------------** | **----------- **New Features / Commands** -----------** |
|
|
|
| Load Balancing: **`wait`** | **wait** on it's own - eg: `buy 1, **wait**, repeat` - will load balance themselves to queue up and release one every 100ms (round robin). So for example, you have that example command **`buy 1, wait, repeat`** running in 2 separate commands on 20 different instruments all running at the same time, it will queue all of those waits up, and then start releasing 1 of those waits every 100ms while keeping the other 19 on hold in the queue. So it will take 2 seconds to cycle through all 20 of those `wait` commands. Or if you had 5 of them, it would cycle through them all twice per second. Or if you had 100 it would take 10 seconds to cycle through all of them. So the point of this, is so you can effectively make all those commands run in one big serial operation. So that your commands are evenly distributed across multiple instruments. Rather than having to run one instrument after the other in serial. So even if you have the commands running in parallel, they will queue up and run those waits basically in serial. At a rate of 1 every 100ms. (We can adjust the timing to basically anything on the next deployment if there is any feedback about it). **NOTE: This will not affect normal wait orders - traditional waits still all work exactly as they always have. This is a new independent feature.** This would be really useful for `loop` commands. To basically round robin all the instruments even though you are running them in parallel. You can slip in a `wait` in there and boom. - It's easier to see how it runs with a simple test. Try this: **`set kd: btcusdt,ethusdt,solusdt,ftmusdt,solusdt,bnbusdt,dogeusdt,atomusdt,gmtusdt,aptusdt`** and then **`loop kd: let x 1 \| wait, let x x+1, say testing, check value x, repeat 19`** here we have initially set x to be a value of 1. And every time it repeats, it adds +1 to x. So the number will increase by 1 every time it cycles through, and print the value to screen. And you can see the order numbers being run through on each instrument in round robin. Anyway, it'll make sense when you run it. |
|
|
|
| Load Balancing: **`wait`** | **wait** on it's own - eg: `buy 1, **wait**, repeat` - will load balance themselves to queue up and release one every 100ms (round robin). So for example, you have that example command **`buy 1, wait, repeat`** running in 2 separate commands on 20 different instruments all running at the same time, it will queue all of those waits up, and then start releasing 1 of those waits every 100ms while keeping the other 19 on hold in the queue. So it will take 2 seconds to cycle through all 20 of those `wait` commands. Or if you had 5 of them, it would cycle through them all twice per second. Or if you had 100 it would take 10 seconds to cycle through all of them. So the point of this, is so you can effectively make all those commands run in one big serial operation. So that your commands are evenly distributed across multiple instruments. Rather than having to run one instrument after the other in serial. So even if you have the commands running in parallel, they will queue up and run those waits basically in serial. At a rate of 1 every 100ms. (We can adjust the timing to basically anything on the next deployment if there is any feedback about it). **NOTE: This will not affect normal wait orders - traditional waits still all work exactly as they always have. This is a new independent feature.** This would be really useful for `loop` commands. To basically round robin all the instruments even though you are running them in parallel. You can slip in a `wait` in there and boom. - It's easier to see how it runs with a simple test. Try this: **`set kd: btcusdt,ethusdt,solusdt,ftmusdt,solusdt,bnbusdt,dogeusdt,atomusdt,gmtusdt,aptusdt`** and then **`loop kd: let x 0 \| wait, let x x+1, say testing, check value x, repeat 19`** here we have initially set x to be a value of 1. And every time it repeats, it adds +1 to x. So the number will increase by 1 every time it cycles through, and print the value to screen. And you can see the order numbers being run through on each instrument in round robin. Anyway, it'll make sense when you run it. |
|
|
|
| Option: **`skew`** | **Correction on use** - You can `split buy 1 into 20 from m-50 to m-350 skew 33` - and it will skew the same sized orders closer together, instead of scaling order sizes. Play around with the number. |
|
|
|
| **`wait position`** | ***(Not a new command, but thought it could do with some updated / refresher guidance).*** Waits until the position on the current instrument is not zero. Be aware that this will be true if you already have a position. So if you wait position, do something, repeat then once it hits, its going to repeat that command like 1000 times a second. So you'd want to do something like - wait position, do something, wait possize == 0, repeat - so that it waits until you close the position, and then waits for the next position to open. Rather than just executing one time and blasting through 1000 repeats a second. |
|
|
|
| **`if, else`** | Same goes for if, else comparisons. You don't want to be infinitely repeating an `if, else` without any wait conditions, because it will repeat 1000 times per second. (Next update it will slow you down every second to allow you to fix your mistake). So you need to have waits in there to wait for the condition to be true, and then if you want it to repeat, you'd want to have another wait __before__ you get to the repeat command so that it doesn't just run back through immediately 1000 times a second, because your condition technically __remains__ true. Think it through logically. And think when you want it to trigger, but also how many times you want it to trigger when the condition becomes __and remains true__. If you need help - just DM ichi what you've got and he will help you get it right. |
|
... | ... | |