A problem I can't solve

[LTNGames]

Okay, to start I'm creating a plugin for RPG Maker MV for my game, don't worry I don't expect many people here to have much knowledge on that engine. My question is not related to MV specifically but to a time system I'm creating. So far I have the whole system in working order, there is one feature I am attempting to get working and my brain is not capable of solving it at the moment lol. So, basically, I am making a feature that allows the player to time travel and I want to set up an update function that will record an event(location & time) every few minutes (set by the developer using the plugin). I have a time object which is always updating to whatever the current game time is, so I essentially can never get the current time without it updating, it's really hard to explain so I'll show some code in hopes to clear some confusion up.

	Game_Time.prototype.updateTimeEvents = function () {
		var currentTime = this.time.minute;
		if(currentTime === (currentTime + 5)){
			console.log('Recorded automatic time event');
			this.recordEvent();
		}
	};

Here I'm trying to compare the currentTime(in minutes) with itself + 5 minutes but because this is happening in an update function and the time object is always updating this will remain false, forever! lol, This is what I'm having a hard time with, I need to somehow get a copy or a static version of my time object to be able to compare it with but I feel like I've mentally tried so many different ways and none of them work for me. I'm hoping someone here can post some ideas or ways you may achieve what I'm attempting to do, at this point my brain has worked too hard to figure it out, so I'm taking a break and asking here to take my mind off it for a little while. I hope this was not too confusing, if you have any questions let me know, cheers

[Firenibbler]

If you are trying to get it to update every five cycles, then try something like this:

if(currentTime%5===0){
     this.recordEvent();
}

Basically, if whatever the current time is is divisible by five then it will run the function. Hope this helps!

[LTNGames]

Wow, so easy almost makes me look bad hahah. Almost 8months I been dabbling in JS with RPG Maker & Phaser and I have never seen the % sign being used until today. Thank you for this very simple solution and you have motivated me to do more research for Javascript.  

My final function looks like this. I had to add in the time objects second property so it would not update for the entire minute but easy enough. Thanks again, I'll be sure to ask my question in this community for now on.

	Game_Time.prototype.updateTimeEvents = function () {
		var currentTime = this.time;
		if(currentTime.minute % 5 === 0 && currentTime.second === 1){
			this.recordEvent();
		}
	};

 

[Firenibbler]

No problem  glad I could help.

[symof]

On 8/13/2016 at 1:36 PM, LTNGames said:

Wow, so easy almost makes me look bad hahah. Almost 8months I been dabbling in JS with RPG Maker & Phaser and I have never seen the % sign being used until today. Thank you for this very simple solution and you have motivated me to do more research for Javascript.  

My final function looks like this. I had to add in the time objects second property so it would not update for the entire minute but easy enough. Thanks again, I'll be sure to ask my question in this community for now on.

	Game_Time.prototype.updateTimeEvents = function () {
		var currentTime = this.time;
		if(currentTime.minute % 5 === 0 && currentTime.second === 1){
			this.recordEvent();
		}
	};

 

Are you using typescript? I don't see the point in not writing it like this

Game_Time.prototype.updateTimeEvents = function () {
		var currentTime = this.time;
		if(currentTime.minute % 5 == 0 && currentTime.second == 1){
			this.recordEvent();
		}
	};

==	equal to
===	equal value and equal type

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comparison_Operators

[LTNGames]

You know, I thought about this myself but JShint & JSLint tell me otherwise, it says to use === when comparing to 0 and at the moment both give me the same outcome. I'm still getting used to JavaScript and I find JSHint helps a lot but in this case, I'm confused.

[Firenibbler]

The == only compares values. while the === compared values and information type.

for example:

0=='0' // is true.
0==='0'// is false.

=== is more exact, while if you need something more flexible, use ==.

[mattstyles]

On 8/18/2016 at 0:55 AM, Firenibbler said:

=== is more exact, while if you need something more flexible, use ==.

@LTNGames

Never ever have this thought process.

Always use triple equals, whilst not necessary in many cases it will save you many potential headaches.

Only when you actually know the rules of double and triple equals in JS can you use double equals, and even then, there are always better solutions. JS is confusing enough, don't make it more confusing. Just use triple equals and be done with it (learn the rules though, always learn the rules). Code that requires less effort to read and process is better code.

Type coercion is a nasty subject, in a loosely typed language its even more dangerous, just use the triple equals. There is a reason just about every linting setup enforces it from the get-go and it isn't because the authors dont know the rules.

[LTNGames]

2 minutes ago, mattstyles said:

Always use triple equals, whilst not necessary in many cases it will save you many potential headaches.

Since I've started with JS I have always used === not because I knew much about it but because I've always used a linter, it's a habit now to use triple equals and feels unnatural when I don't use it. Thank you for chiming in and giving me your 2 cents on the subject it gives me peace of mind. Not often that I run into a scenario where double equals is required and I have been programming in JS off and on for at least 8months and if it's ever required, like you said there are better ways to accomplish same results. Thanks again, cheers.

[Firenibbler]

7 hours ago, mattstyles said:

@LTNGames

Never ever have this thought process.

Always use triple equals, whilst not necessary in many cases it will save you many potential headaches.

Only when you actually know the rules of double and triple equals in JS can you use double equals, and even then, there are always better solutions. JS is confusing enough, don't make it more confusing. Just use triple equals and be done with it (learn the rules though, always learn the rules). Code that requires less effort to read and process is better code.

Type coercion is a nasty subject, in a loosely typed language it's even more dangerous, just use the triple equals. There is a reason just about every linting setup enforces it from the get-go and it isn't because the authors don't know the rules.

While you would be correct, there are a few times that many people have needed double equals, like, for example, if you are comparing variables of different types, but the same value. (Like parsing text, and checking the number from the string.)  There is a reason that both are implemented and it is best practice to use each feature to its fullest extent.

How they work behind the scenes, is the == is a type converter as well as an equal sign. So it converts the type of information before checking. However, === only compares the values. This is the reason that === is recommended over ==, because it is slightly faster to execute. 

It is similar with the eval function, It is extremely bad practice to use it in most cases, except for a few where it is needed and perfect. It all depends on the problem you are trying to solve. As for @LTNGames I recommend reading up on the differences between == and === and deciding what is best for your code. 

[mattstyles]

=== wasn't implemented due to performance (the differences are super minimal and in many cases == wins), its to do with making JS a little less unpredictable.

The only valid reason for advocating use of double equals (which has not been mentioned) is that developers should learn the ins-and-outs of their language and use it properly, this is a great argument, but, unfortunately, the rules around it are awkward so most prefer to just stick with triple equals and accept another of JS's little quirks. There is an additional concern here regarding JS's ridiculously high level of flexibility, its a strength to a language's adoption across platforms but not to developers trying to use that language.

Bikeshedding over style is pointless but when there's a decent rule for static analysis that makes your code easier to read and understand and helps avoid a slew of subtle (and hard to track down) bugs then you use it. Take, for example, the rules around auto semicolon insertion, in the case of ASI there are pros and cons to each approach so each is a valid point of view, in the case of === vs == its very one-sided towards always using triple equals.

Quote

if you are comparing variables of different types, but the same value

You see, this is the very crux of the issue, variables of different types are different variables, saying something looks the same and therefore is the same is a very bad idea™. The fact that JS lets you even attempt to compare them is a by-product of loose typing and implicit type coercion. If you take a different track by declaring an explicit type coercion (or, a common way to solve this would be to add additional check for variable type, ie typeof) then I'll immediately know what your code does (and so will you, some time in the future) rather than risk a misread of an equality check or a misunderstanding.