GDPR-83_694920's avatar
GDPR-83_694920
Blocked user by Spotware at 16 Jan 2024, 06:52
0 follower(s) 0 following 0 subscription(s)
Replies

GDPR-83_694920
22 Oct 2020, 12:14

RE: RE: RE: RE:

Hi firemyst

Thanks for the reply/I thought I would leave it a week or two before replying to see how the changes I made worked out

I am not experiencing lots of issues only two but they are major issues obviously - I do not think it is anything to do with the server build/all seems fine on that side

I removed a print statement (that I could toggle on/off anyway) and the streamwriter file writes from within my code and basically stripped it down to the absolute bare miniumum code I can manage to still actually do what I want it to do! Overall I would say this seems to have sorted out the issues although they are not completely gone - I am no longer getting server disconnects (although I did once and to me it seems it is happening when I try to recconnect to the server via my iPad using MS RDP when I have not properly disconnected from the server and swapped to another app on the iPad then 10-15 minutes later switch back to the RDP app and it tries to reconnect - this seems to send the server into a bit of a spin and cTrader server broker connection is attempting to connect - obviously now I always disconnect properly from the server before swapping to another app and this seems to be working!)

The other issue is with the NYC Servers Liberty ‘widget’ which I guess you don’t use as you have multple instances of cTrader running - it seems to be a little too aggressive in determining an app has crashed when it is actually just ‘having a moment’ but it treats it as a crash and restarts it - I also added the taskmanager to the widget as I always have that open to monitor realtime CPU/RAM and this too has ‘crashed and restarted’ a couple of times by the widget so yeh it seems to be too agressive/might contact NYC if keeps happening

Overall though happy to report things are working ok now but I am still not satisfied this is a robust enough solution to build up (hopefully!) to be trading 10’s/100’s thousands of $$’s and sleeping easy at night - I still wish more focus could be put on providing increased redundancy for 100% automated algos but I guess it is down to the trader themselves to work that bit out...

cheers

xammo


GDPR-83_694920
09 Oct 2020, 18:33 ( Updated at: 21 Dec 2023, 09:22 )

RE: RE:

Ok something very odd has just happened... since writing the last message I was busy with an online meeting for two hours - after the meeting finished I logged onto the NYC VPS to check everything was ok

I wasn’t quite sure what I was seeing as the screen seemed to be glitching and refreshing badly all messed up but as it ‘came right’ cTrader was starting up and the bots were firing up and the server connectivity attempting to connect which it did eventually and everything seemed to settle down but obviously something had been very very wrong...

I checked my emails to see what had been received and am attaching the screenshot from my phone

(Sorry am sending from my phone - that image looks huge/cannot see how to resize) the coloured circles showing green for the emails which I have configured the bots themselves to send on order execution then the red one which is ‘Liberty’ (NYC Servers ‘widget’) notifying me that cTrader had become unresponsive at about quarter to nine (am in Asia/Thailand/is Thai time) and was attempting to restart it but you can see the amber circled email is me logging onto the server at quarter past nine which is when I saw cTrader frantically  starting up so the restart of the unresponsive cTrader was obviously unable to happen without a user actually being logged on so unfortunately that doesn’t seem to have worked well

Then you can see the next green circled email which is one of the bots executing a trade that obviously should have happened during the time cTrader had crashed...

Ok I thought so things happen and this is all new territory and what the h*ll just happened etc. as cTrader suddenly disappeared and began restarting... wtf! Ok it’s started up again wtf is going on... woah it’s restarting again!

after this third restart I stopped the ServerState bot (code above) thinking it might be something to do with it but still it restarted two more times which is when I set cTrader back to multi instance and didn’t even restart it just left it like that and it hasn’t restarted in near on an hour now/everything seems stable again...

hmmm... not good... enough for today though just wanted to report back what happened

 


GDPR-83_694920
09 Oct 2020, 15:07 ( Updated at: 21 Dec 2023, 09:22 )

RE:

Hi Panagiotis

Many thanks as always for an extremely quick and very thorough reply! I wrote my reply earlier but on submit it seems not to have actually posted and just took me to the homepage (something I forgot happens when posting on this forum/I usually always copy and paste the whole reply before hitting submit just in case but didn’t bother this time more fool me!) but I thought I’d go and do somethibg else instead and give the changes made some time to ‘work’ and hopefully have more to report back 

I am fed up with it so decided to write the following code in an attempt to catch the issue but every time the disconnect happens the bot (below) has stopped and no email is sent (email setup is 100% ok/the other bots running fire off emails no problems) so

The events provided by the cBot are triggered only when the server disconnects you for any reason. When disconnections occur for any other reason beyond our control (e.g. bad connection, poor server performance) then these events will not be triggered.

Ok understood thank you for the explanation (I would use other methods external of cTrader to detect connectivity/machine performance issues anyway)  but obviously there were  no connectivity issues as I was connecting to the VPS at the time

please advise what is wrong with the code or how I can achieve the desired results of sending emails every time a connect/disconnect happens

Based on the above, probably the events were not triggered at all. Also if your disconnection is caused by a general internet disconnection, obviously no emails will be sent

I think they were triggered as the code bombed out and stopped the bot also as per my edit post above I realised I had mistakenly left the ‘protected’ instead of changing to ‘private’ for the two methods

Yes I do of course understand no internet connectivity means no emails can be sent but as stated it is a VPS I am connecting too so no connectivity issues otherwise I would be unable to connect and the other bots are firing out emails just fine

But also just to add Panagiotis with all due respect I think you and I both know that a single point of failure in any system is not ‘good enough’ and using a recommended VPS is still a single point of failure no matter which way you look at it

We recommend this as the first step to take for your cBot to run 24/7. Frequent infrastructure outages is something you need to check before proceeding with a software solution to the problem. Disconnections every some hours should not be the case. Is your VPS provider reliable? Where is your VPS located? What is the ping time? Do your machine specs meet the recommended requirements? Can it handle your cBot execution efficiently? In any case, if you need fault tolerance, this is something you need to develop it yourself, since a cBot is your software.

As previously stated it is a NYC Server VPS and there does not seem to be any strain on the CPU/RAM with the currently three bots running so I assume all the remaining questions are null and void apart from the statement about fault tolerance which yes I understand

 I have seen other posts going back 5+ years that are requesting greater fault tolerance and resilience of cTrader such as being able to autostart bots if a machine restarts unexpectedly/system crash

Here it is

 

I take my hat off to you sir!!! I do recall seeing this in a relatively recent update (last year or so or maybe bit longer?)  but as at the time my thinking was more along the lines of multiple instances did not feel the need for it and to be honest totally forgot about it! Thank you very much for pointing it out - I set it up immediately after reading  - restarted  cTrader with the bots still running and yes! they all started immediately - superb and obviously a perfect combination with NYC’s ‘widget’ to allow for autologon and autostartup on startup of  cTrader - that pretty much solves unexpected machine restarts! Thank you very much!

 

 I really think Spotware need to start putting some effort into making their software (up for an award I think I saw - hope that goes well!) more resilient (for example why isn’t there already a built in tick box in the settings to send an email on server connect/disconnect?)

Our part of the software is fault tolerant. Our servers are up and running for 10 years now and we had no downtime yet.

Yes I was not referring to your backend infrastructure and honestly I do not say this lightly congratulations on such an extremely impressive track record that is quite amazing and I am sure without a shadow of a doubt a great many factors contributed to achieving and are continuing to contribute in maintaining such a resilient and robust system which is the wisdom and knowledge I am basically suggesting would be great to extend out over to the front end to your clients that are using cTrader for algo’s (not manual trading/semi-automated/web based etc.but for full time algo clients looking for the most robust and resilient setup they can achieve - it would set you leagues apart from others) 

(for example why isn’t there already a built in tick box in the settings to send an email on server connect/disconnect?)

As explained above, we cannot know if there is any issue on your side. You need to handle these cases yourself.   

Yes understood but as you also explained above you are able to detect server disconnects initiated  by the broker so why not alert the client to these disconnects as the norm/switchable setting?

 what about developing the ability I already spoke about where the same bot can run concurrently on different machines (multiple machines managing the same code/positions at the same time - I am  sure that would win Spotware many awards! :)

The same cBot can run concurrently on different machines. Nothing prevents you from doing so. But you need to handle the concurrency issues yourself, since it is your logic that is being executed. This is not something cTrader can handle for you, cTrader is just the platform for your strategy to be executed on. It is like asking from a multicore CPU to do the parallel programming for you. This is not possible. If you need concurrency, you need to write the cBot code in a way that it can run concurrently on many machines. 

Yes of course I am not looking for the CPU to do the programming for me I understand what you are saying but I was thinking/hoping there might be something behind the scenes perhaps even between spotware and the broker that might help in this regard but sounds like nothing along those lines exist

I have tried to think how to rewrite my code to achieve anything that might work but am at a loss as previously stated my code relies on the TradeOperation (or TradeResult) to manage the trades and as  bots cannot ‘talk to each other’ I cannot see how it is possible other than a couple of ideas have been to write a file every tick to a shared location that is time stamped and read  by the paired  bots on different machines but other than the logic I would think file read/write/sync latency would basically wreak havoc  - another was along the lines of the bots pinging each other in a master/slave scenario and brief searches brought up TCP transmitter and listener as being available in C# but even whether it is anything that would help or even does what I think it does I don’t know and can see many hours being consumed just trying to work out what it is and how to set it up/use it...!

Anyway on a final note and now being some hours later having switched cTrader to single instance mode I have not experienced a single disconnect... not one... hmmm

Cheers

xammo


GDPR-83_694920
09 Oct 2020, 09:45

RE: RE:

Just realised I’ve got ‘protected’ - should be ‘private’ for the connect/disconnect methods! (I just quickly edited the default code...)

Have edited them both/rebuilt and running the bot again will see what happens (but still appreciate any feedback please @Panagiotis)


GDPR-83_694920
09 Oct 2020, 09:32

RE:

OK.... so I setup and have been using a NYC Server (Windows Server 2012 R2...! which I am typing this on now) for the last week or two and running a few bots live and whilst initially everything seemed ok I am now experiencing relatively frequent broker disconnects which seem to happen when I connect to the VPS (cTrader goes into a bit of a fit and the GUI gets messed up and is not showing properly the list of bots in automate and the broker connect is attempting then after 10-20 seconds things spring back into life) but other times I am only aware of it as I have not received any emails from the bots running that trigger trades every few hours or so on average and when I logon to the VPS I see the previous mentioned ‘fit’ and the broker connection eventually made then a handful of trades trigger that should have triggered some time ago! very frustrating :(

I am fed up with it so decided to write the following code in an attempt to catch the issue but every time the disconnect happens the bot (below) has stopped and no email is sent (email setup is 100% ok/the other bots running fire off emails no problems) so please advise what is wrong with the code or how I can achieve the desired results of sending emails every time a connect/disconnect happens

But also just to add Panagiotis with all due respect I think you and I both know that a single point of failure in any system is not ‘good enough’ and using a recommended VPS is still a single point of failure no matter which way you look at it - I have seen other posts going back 5+ years that are requesting greater fault tolerance and resilience of cTrader such as being able to autostart bots if a machine restarts unexpectedly/system crash - I totally appreciate this is no doubt complicated but I also do not believe this can be passed off by saying it has anything whatsoever to do with ‘no system can run 24/7 without any intervention’ - this is is not what we are talking about here and I really think Spotware need to start putting some effort into making their software (up for an award I think I saw - hope that goes well!) more resilient (for example why isn’t there already a built in tick box in the settings to send an email on server connect/disconnect?) and what about developing the ability I already spoke about where the same bot can run concurrently on different machines (multiple machines managing the same code/positions at the same time - I am  sure that would win Spotware many awards! :)

Thanks

MaxT

 

using System;
using cAlgo.API;

namespace cAlgo.Robots
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class ServerState : Robot
    {
        protected override void OnStart()
        {
            Server.Connected += OnServerConnected;
            Server.Disconnected += OnServerDisconnected;
        }

        protected  void OnServerConnected()
        {
            SendEmail("Connected "+Convert.ToString( Environment.MachineName),Convert.ToString(Server.TimeInUtc));
        }

        protected void OnServerDisconnected()
        {
            SendEmail("Disconnected " + Convert.ToString(Environment.MachineName), Convert.ToString(Server.TimeInUtc));
        }

        private void SendEmail(string subject, string body)
        {
            Notifications.SendEmail("abc@gmail.com", "xyz@outlook.com", Account.IsLive ? "[LIVE] " + subject : "[DEMO] "  + subject, body);
        }

        protected override void OnStop()
        {
            Server.Connected -= OnServerConnected;
            Server.Disconnected -= OnServerDisconnected;
        }
    }
}

 


GDPR-83_694920
17 Sep 2020, 13:27

RE: RE: RE: RE: RE: RE: RE:

Ah right ok so a slow and steady kind of cbot :) that you seem to intervene with quite a bit so I guess more of a semi-automated strategy - sounds good to be honest

yeh I’ve been at this (cTrader) quite a while now (2 or 3 years + and the same again with ProRealtime before that - never got into MT for some reason) and it took me a bit of time to get to grips with position labelling but got all the help I needed on here (as cryptic as it seemed at the time and still does! but have learnt a lot of C#!)

I prefer LINQ for position lookups and use;

Positions.Where(pos=>pos.Label == label);

then can include things like && pos.TradeType == TradeType.Buy or && pos.NetProfit > netProfit etc. to get exactlly what you’re after (yes I also include all the ‘vital info’ I need in the label) - also works great for ‘foreach’ statements and counting and detecting existing positions etc. but as I say I use/depend on a TradeOperation (sorry I said TradeResult earlier - always get mixed up on those two) off of an ExecuteMarketOrderAsync so it is not possile to ‘detect’  a position (by looking it up) until it has actually completed/impossible to do whilst the transaction is ‘flying in the air’ which is where the TradeOperation comes in - unfortunately the TradeOperation is cBot specific as far as I know so one cBot doesn’t know the other has already fired off a trade operation so they both do it/no way can detect it by counting positions etc. as they both will fire near simultaneaously/the position doesn’t exist at the time they trigger to trade

Also seems you’re using server side stops/limits set by your cBot so that will obviously ‘do the job’ managing the trade(s) if the lights go out on the VPS

I’ve dabbled with more techniques than I care to remember (have a folder stuffed full of all my previous attempts!) but at the moment I do not use any server side operations - everything is controlled by the cBot hence my desire to have as robust a solution as possible - I realise as I am writing this I said above I have tried to build things to take into account issues but here I am admitting I don’t even use server side operations to ‘deal with things’ if the cBot goes offline for whatever reason but.. well...that is to do with the style of trading I am doing which is not particularly fast moving and I could/have used server side operations to deal with things but for reasons that escape me now I decided to have 100% control within the cBot itself as my strategy depends on new trades triggering on others closing (could be hours/days between trades) so I can survive 9/10 if the VPS goes offline unless like this time it just so happens a trade is very near to closing/subsequent trades should fire (I guess I am trying to reduce ‘sods law’ haha ;)

Anyway thanks for the feedback all helps in broadening the mind! :)


GDPR-83_694920
17 Sep 2020, 11:02

RE: RE: RE: RE: RE:

yeh I’m expecting notification of at least a partial refund for the outage will wait and see/contact them if don’t hear anything

Thanks for explaining your strategy and I don’t want to keep on about this as I know it is never possible to account for all the markets can throw at us (but this is not actually about the market) but even so with what you are doing what if the outage occurs when you’re sleeping? (low equity a thousand pounds or so ok can live with it but what about 10’s or 100’s of pounds equity?) I see NYC Servers offer a service to start up trading software after a restart (so umm isn’t that kinda admitting sh*t can happen even for them?) but I think this is only for MT - not possible with cTrader (and anyway starting cBots unattended with all their variables possibly in a mess due to the ’missing time’ spent in the outage/again depends on style of trading/cBot code would not be too cool)

Anyway I don’t know what the solution would be and as Panagiotis said there are many (most probaly all) running on a single VPS so I guess an outage and any potential loss caused by it would just be put down to experience and the overall P&L of trading as a whole... btw I did try running both VPS’s with same cBots at the same time and there were no issues when a trade  closed/triggerd  the next trade EXCEPT for the fact that each cBot placed a trade when it should have only been one (I use/depend on the TradeResult in the code to hold back further trades until initial has been registered succesful - obvously this result cannot (that I know of) be shared between the two cBots so I don’t reckon that idea is going to work for me anyway at least not for the current code but good to know it is ‘possible’

 


GDPR-83_694920
17 Sep 2020, 10:30

RE: RE: RE:

Wow 2 copies of cTrader and 26 cBots in total on a 2CPU/4GB VPS is quite simply incredible!

Yeh I know about print statements (why can’t they be ‘sorted’ by spotware to not cause the problem though...?) and also loading charts but thanks for the advice all helps - I have had cTrader on a 2CPU/4GB Azure VPS (no OneDrive hooked up) start eating up the CPU just having it open watching a chart whilst I worked on my laptop occasionally checking back on the VPS - no cBots running/literally nothing goingn on... close and re-open cTrader sometimes sorts it but usually best just to do total restart to be sure whatever was causing the issue has been cleared

My suscpicions started to go towards the Azure VPS not having a GPU as to why this happened but really have no idea (I noticed previous/now dead laptop used GPU quite extensively when running cTrader - I work exclusively on VPS’s now so can’t check)

Just curious - what would you do if that one NYC VPS went down for 5/10/15+minutes? obviously no idea your equity level or if you’re similarily just testing with low equity or what your current situationn is but yeh would that cause you a problem and/or could you recover from it relatively quickly/easily with minimum to no ‘hurt’? Obviously HFT would be shot to pieces but long term would not be too bad most probaly so a lot is dependant on style of trading - and yeh most probaly the VPS ‘will never go down’ and perhaps it ‘won’t’ but what if it did? (just read the incident report on the Azure outage - a number of chiller pumps shutdown in the datacentre causing temperatures to exceed thresholds which began sequantial shutdowns of various equipment - issue was identified and chillers brought back online/systems gradually bought back online sequentially... yeh unbelievable in my mind this could happen to a MS datacentre but yeh sh*t can and does happen!

 


GDPR-83_694920
16 Sep 2020, 11:41

RE: RE: RE:

Hi Panagiotis

Thanks for the quick reply! yeh I am from an IT background/used to use Azure in the past (business use not trading) and compared to Beeks offering (shocking/dark ages) I felt Azure offered much more bang for the $ - obviously Micorosoft is quite a big company/a lot of hardware behind the scenes etc. but yeh outages do occur obviously! (there are ways to cluster VPS’s and build in redundancy but I guess that is what the likes of NYCServers are already doing ‘behind the scenes‘ so I guess there is an argument for going with a dedicated FX VPS provider over a more general VPS provider so will give it a go

I know I sound over the top trying to build in such resilience and I can quite believe there are many out there running on single VPS but it would only take one bad day to potentially set back any gains (or make losses worse) disasterously - my long term strategy has been to build algos/backtest/forward test demo/forward test live - live is with a small account trading micro lots so the outage was no big deal and is all part of the learning process and developing a complete solution I would be willing to start ramping up the amount of equity into and be able to sleep at night knowing the cash I have reserved (for years!) which I hope to one day pump into the ‘system’ will be as best looked after as possble

Many thanks also for confirming it is possible to do what I am asking about and I can ‘give it a go’ - yes can understand about the advanced coding of such a system and whilst I am by far no pro coder I’ve been at it for quite a while now and as odd as it sounds my cBots ‘do a lot from a little’ so in some sense there is not actually a lot going on - the main thing I can think of being a problem is the latency cBots experience in receiving notification of trades being placed/succesful and the positions.opened/closed parrallel methods being implemented on each machine running the cBot but yeh what the hell reckon I’ll give it a go and see what happens :)

Thanks!

MaxT

 


GDPR-83_694920
16 Sep 2020, 11:05

RE:

Hi Panagiotis

Thanks for the reply - haha so Microsoft Azure are not a reliable VPS provider...? I guess not with the downtime I’ve experienced and yeh I guess an ‘FX focussed’ VPS provider would be more reliable (?) but I am not interested in execution times/not scalping and this still leaves a single point of failure so was hoping you might have said ‘sure you can do that’ or ‘NO! whatever you don’t do that!’ so I think I might just give it a try as even a reliable VPS provider can have issues so why not just find out if this will work then can have 2 reliable VPS providers running and increase reliability to the ‘max’

Thanks

MaxT


GDPR-83_694920
16 Sep 2020, 10:59

RE:

Hi Firemyst

Many thanks for the reply - I am meaning the exact same cBot managing the exact same positions from mulitple machines - not sure if that is what you mean you have been doing (I am still tempted to try it and just see what happens...!)

I appreciate all you’ve said about OneDrive but the way I have things setup it is not affected by any uptime availability of OneDrive or network lag etc. OneDrive folders/files can be cached locally - the only issue I have had is file access conflicts when OneDrive is uploading and the cBot needs to read/write at the same time but I have implemented the cBot code to handle this and it works well - it is more of a ‘lazy’ way not ‘mission critical/cBot dependant on the files’ to have a central repository for cBot .txt files containing the cBot variables which will be available to any other machine if the main VPS goes down (and I don’t need to drag drop any folders/files - everything is already always backed up)

Regarding the file bashing/hashing you’ve mentioned yeh this did cross my mind but as I say the only file that has a problem is the journal which is no big deal a copy is created and as far as I can tell all the folders/files ctrader creates in the MyDocuments folder are templates/Indicators/cBots which are all essentially static - all the workings of cTrader go into the appdata folder from what I know of from doing a complete proper uninstall of cTrader and this folder is of course not included in the OneDrive sync but yeh I appreciate this probably isn’t the best way to have ctrader installed (I guess...but not confirmation from spotware either way)

Thanks for the recomendation on NYCServers and yeh I am with ICMarkets/have been aware of the discounted VPS offerings but I tried Beeks many moons ago and have to say it is abysmal (Win Server 2000 from memory and no web console to manage the VPS and very expensive for the specs) - NYCServers look better pricing but their VPS calculator recommends their basic plan (1 CPU/1GB RAM) for ctrader which doesn’t give me much confidence as it simply won’t run on those specs but yeh the standard looks ok but even 2CPU/4GB RAM will only just get cTrader running but can choke if a few cBots running especially more so as time passes and cTrader eats into RAM/CPU for inexplicable reasons only cleared by a restart of the VPS

 

Anyway thanks again for the input much appreciated!

 

MaxT

 


GDPR-83_694920
17 Jul 2019, 12:55

Just got the platform update - happy to report multiple backtests now all running at full speed!

Very quick work well done getting it sorted very impressed thank you!


GDPR-83_694920
10 Jul 2019, 09:53

Hi Panagiotis

Yes the multiplier (and random hanging) issue is my main problem and is making backtesting practically unusable - only way is to backtest one cBot at a time and still it can hang

This topic is showing quite a few 'reads' surprised no one else has chipped in saying they are having the same issue/how are they able to effectively backtest like this...

Anyway thanks for letting me know and hopefully that means an incremental update not too far off in the future best of luck getting it sorted

Thanks

Max


GDPR-83_694920
10 Jul 2019, 05:28

Hi Panagiotis

As you originally said you were unable to reproduce this issue and nobody else is adding to this post saying they are experiencing the same issue is this something unique to me for some reason and therefore low priority/unlikely to be resolved any time soon or is it an issue you have identified potentially affecting many users/it is high priority and a chance it may be fixed relatively soon please?

Thanks

Max


GDPR-83_694920
05 Jul 2019, 08:30

Hi Panagiotis

Another vid showing that the backtesting hangs and needs to be paused and played to get them going again - https://www.youtube.com/watch?v=KYkJK7CtoEo

I can (just about) put up with 200x but this hanging is getting very frustrating...

Even if this issue is anything to do with internet glitches the old version kept running the backtests no problem

Also I tested the reverting backtest speed on my VPS and get the same issue

Thanks and hope a solution reveals itself soon! :)

Max


GDPR-83_694920
03 Jul 2019, 15:11

OK great appreciate you letting me know thanks and will wait to hear - best of luck getting them sorted out


GDPR-83_694920
03 Jul 2019, 13:29

Hi Panagiotis

Appreciate you might be working on this (or quite posisbly busy on many other things!) but could you let me know if you have viewed the videos/seen the issue(s) please?

Many thanks

Max


GDPR-83_694920
01 Jul 2019, 13:20

Hi Panagiotis

I guess it must be something 'local' or broker related if you are unable to reproduce it but it is driving me crazy...

I have just uploaded video here using the sample martingale cBot so as to rule out anything to do with my own cBot being the issue - https://youtu.be/qd2qhrdSozg

Also I have noticed an issue with charts not showing full history (same thing in old version from what I remember) that is easier explained in this video - also the date/time pop up at the bottom of the crosshair seems to be missing now in the backtesting window as shown at begining of the video - https://youtu.be/xly5EpcFQHs

I have also just worked out totally by chance what was wrong with the severly limited history in some of the instruments when I went to video the JP225 in that I needed to set backtesting to minute data then back to tick data to get all the available history but missed it so did it on NOKJPY - video here - https://youtu.be/eFcdEdjiezA

(btw - the disconnections on old version are hopefully a thing of the past now I'm on the new version but were definitely connected to when I was heavily backtesting any day of the week and I could have 2 instances of cTrader open at the time with one connected fine and the other stuck in the disconnected state)

PS - would LOVE the ability to increase scroll bar sizes only/not whole interface as you can see in the vids they (and other 'tiny' buttons etc.) can be a real pain to 'catch' sometimes especially when trying to work quickly through repetitive tasks...

Thanks

Max


GDPR-83_694920
28 Jun 2019, 11:30

Also forgot to mention that backtesting paused yesterday too - left them running at 200x went out for the evening and when came back they were all paused (but not actually paused using the pause button) so had to pause them (using the pause button) and play them to get them going again...

It is possible there may have been internet connectivity issues whilst I was out as I do experience very occasional brief outages but even with V3.3 if I was running multiple backtests it was a regular occurence that cTrader would seem to be in a disconnected state popping up the logon screen but the backtests were still running fine in the background whilst I was still able to browse/use internet no problems (it could well be something to do with the ISP/I'm in Thailand and have experienced similar oddities with other broker platforms that can only seem to be explained by the ISP 'doing something' to cause the issue...) but I would just leave cTrader running and it would eventually reconnect - sometimes I would purposefully disconnect/reconnect internet to get cTrader logged in again which it would almost always do instantly other times it could take an hour or more to get going again...


GDPR-83_694920
31 May 2019, 11:05

Haha :) yes I knew something like that would happen - there are much easier ways to achieve the same result as I have presented it!

But of course this is not the full code/strategy although I think you have got it there/on the right track with the collection idea

The basic idea behind the strategy is to open two opposing positions each with a TP - when a TP is hit again two opposing positions are to be opened with their own TP's

The TP's are modified as time progresses in a manner that means in some situations multiple Buy positions (for example) would all have the same TP (for example 6 out of the 10 exisiting Buy positions now have the same TP) which will all close at the same time when their TP is hit

When this happens I want to only open one more pair of Buy/Sell order (not 6 pairs!)

So yes I think this could be achieved with the collections idea as you suggest but hmmmmm.... looking at it again/quickly thinking it through perhaps not as it would only be 6 of the 10 orders (in this example) that are closing...

Maybe this further explanation will help you come up with another approach or even if not it would be great if you could give an example of how what you've already said could be achieved - I have no problem creating the collection but how/where would I receive the Closed event and process it properly...?