0

Alright so I put this together,

var ms = 0;
var currentCrashNumber = 100;
var nextIncrease = 1.25;
var userIncrease = 1.25;
var multiplierInterval = setInterval(function(){
  currentCrashNumber=currentCrashNumber + 10/(3.5/(nextIncrease - nextIncrease/1.25))/1000;
  console.log(currentCrashNumber);
  ms=ms+10;
  if(currentCrashNumber >= nextIncrease){
    console.log(ms);
    nextIncrease = nextIncrease*(userIncrease);
  }                 
  if(currentCrashNumber >= 305){
    console.log('Script done in ' + ms + 'ms');
    clearInterval(multiplierInterval);
  }
}, 10);

This piece of code is to be done in 17500ms or 17.5s. When I launch the code it will eventually result in about 17500ms.

But, when I time it using my stopwatch I end up to over 19000ms or 19.0s, why is this, how can I solve this?

Fiddle: https://jsfiddle.net/2wbbprfj/

I'm having a progress bar on my site, and this is some backend coding but when the progress bar that lasts 17.5s reaches the end the script isn't done yet, which is weird because they are both programmed to end at 17500ms

Martijn Ebbens
  • 253
  • 3
  • 15
  • 1
    Possible duplicate of [setInterval timing slowly drifts away from staying accurate](https://stackoverflow.com/questions/8173580/setinterval-timing-slowly-drifts-away-from-staying-accurate) – 4castle Jul 30 '17 at 21:57
  • @stybl yeah, I thought so but I edited the post, read the last bit. – Martijn Ebbens Jul 30 '17 at 21:57
  • This is just bad code. It does not respect javascript coding principles. There are certainly better solutions than doing it like this. The question here is what you are trying to do rather than why the timing does not match up in two arbitrary pieces of code. – SkryptX Jul 30 '17 at 21:59
  • @4castle I don't think it is, because the progress bar is always at least 500ms to 750ms faster. – Martijn Ebbens Jul 30 '17 at 22:00
  • @SkryptX I want to keep track of the number because I need the number, but I don't want to keep sending a socket signal to the browser therefor I have the progress bar running that knows how long he needs to run for, which is 17.5s, and so does this script code need to run 17.5s but the script seems to fall behind. – Martijn Ebbens Jul 30 '17 at 22:01
  • So you're simulating a progress bar from something that you _think_ runs 17.5 seconds on the server and hope that it matches up in the end? – SkryptX Jul 30 '17 at 22:04
  • @SkryptX I made the math so it should always run at 17.5 seconds. Therefor I added a ms counter and this also shows up 17500ms. Althought it shows up as 17.5 the progressbar always seems to be done earlier then the backend code. – Martijn Ebbens Jul 30 '17 at 22:06
  • But you can't be sure that the network delay is nearly 0. There are also other options than using sockets, like server-sent events or half-open connections. – Stephan Jul 30 '17 at 22:07
  • 1
    That's just not how it is done. I suggest you read up on event handling and client and server interaction. You can make your code work with a lot of hacks or build a proper implementation that saves you a lot of headaches later on. I strongly recommend the second one. – SkryptX Jul 30 '17 at 22:10
  • @SkryptX yeah (this is ignoring what you just said just a general question because I shouldn't spend any more time on something like this when I don't have to), but every user that comes to the site (most of them) will have a counter like this, wouldn't this be to intensive for a server to handle? That's why I doubted it at first to even start this project and now I'm doubting to continue it. – Martijn Ebbens Jul 30 '17 at 22:12
  • 2
    Additionally there are lots of situations where `setInterval` is massively imprecise (for example if the browser tab is currently in the background). If you choose to go the hacky way instead of some form of server communication, I would suggest to use at least `Date.now()` in order to keep track of the time passed. – Stephan Jul 30 '17 at 22:13
  • @Stephan thanks, but I can't really make a interval using date now, or can I? Anyways, would you maybe mind anwsering the question above your comment? I'm kinda new to all this and stuff and I feel like I'm not doing things the right way. – Martijn Ebbens Jul 30 '17 at 22:23
  • 2
    Another option would be to replace your progress bar with a spinning wheel and just wait for the server to finish. A progress bar is pointless if it does not represent the actual progress. That would be fast and clean. – SkryptX Jul 30 '17 at 22:26
  • @SkryptX yeah you're right about that, that would work I guess, but still. If you had let's say 200 players playing the game then their would be 200 different intervals counting, how heavy would this be on the server? enough to handle? or way to much? – Martijn Ebbens Jul 30 '17 at 23:11
  • Intervals do not count seperately. One process tracks the real time and checks if a interval timestamp is met or return the difference. If implemented correctly even a small webinstance would be able to handle 200 simultaneous players easily. I really suggest you open a new question and formulate your problem, different solutions that you came up with and ask how proper server-client interaction would look like. This comment section is getting too long and will not yield the solution until we have the actual problem you are trying to solve. – SkryptX Jul 30 '17 at 23:24
  • @SkryptX thanks for the help, I will open up a question with what I'm trying to do and then ask what the best way of doing this would be, only problem is. I always get downvoted and no one comments why (whenever I post a question without any code). – Martijn Ebbens Jul 30 '17 at 23:37
  • The question needs to show that you have put effort in yourself. We're not writing code for you but we can answer what the best strategies are and why, if you present us the problem and multiple possible solutions. – SkryptX Jul 31 '17 at 06:09

0 Answers0