Okay, but what about the inconsistency I pointed out? I understand if you want to keep it as a flooring op, but at least make it consistent because it was driving me crazy why I was getting inconsistent output.

int(-0.6) returns 0

Variable1 = -0.6

int(Variable1) returns -1

Edit: I know you won't change anything, but parseInt seems to do the exact same thing as the bitwise-version casting except that it handles larger than int32 values.

this.data = parseInt(val, 10);[/code:3jbjqwuk]

...I'm sorry, but no. This is a bug that needs fixing. People can fix their projects to match this (by replacing int() with floor()), but it's atypical, inconsistent, behavior. You can't possibly expect a serious group to use the product when simple bugs that like aren't even stomped out.

Plus, you don't work for Scirra as far as I can tell, so stop talking on their behalf, as if you do. I'm not interested in your guesses.

Also, "integerizing" is programming jargon referring to the act of casting a 32-bit or 64-bit floating point value to a 32-bit integer. So please stop acting like you know everything.

Why did you provide a link to the def of integer? I'm a software engineer...oh, wait, are you confusing "language" with "spoken language". I'm saying "language," as in, "programming language."

As far as your other statement goes, well, I'm going to have to say that you're wrong there. Doing int(-0.6) gives a different result than "Variable1 = -0.6" followed by "int(Variable1)". This is an extremely valid and ridiculously simple to fix bug.

Problem Description

int() is performing a flooring operation on variables. This is not what casting to int does in any programming language, ever.

Given the example, Variable1 = -0.6, when doing int(Variable1), it should return 0 and there are extremely valid reasons for this. Like when you're doing basic movement operations like "int(sin(270) * speed * dt)". At an angle of 270, for instance, there should be 0 movement from the Y axis. However, int is flooring. Flooring will take a number like -0.6 and make it the next lowest integer, which is, in the case of my example, -1.

The interesting part about this bug is that it only does it in this order. If you do int(-0.6), it will properly integerize it. I assume this is a static evaluation that occurs during compile time.

Observed Result

Variable1 = -0.6

int(Variable1) returns -1

Expected Result

0

Steps to Reproduce Bug

• Create variable by name of "Variable1"
• Set Variable1 to -0.6
• Print out "int(Variable1)"

Affected Browsers

• Chrome: YES
• FireFox: YES
• Internet Explorer: YES

Operating System and Service Pack

Any

Construct 2 Version ID

240

Where?

The bug is in expressions.js, with this line of code

ExpValue.prototype.set_int = function (val)
	{
		assert2(cr.is_number(val), "Calling expvalue.set_int without number type");

		this.type = cr.exptype.Integer;
		this.data = Math.floor(val);
	};[/code:32wnyed3]

To fix it you need to do a typical JS int casting operation using a bitwise or op with 0.

[code:32wnyed3]this.data = val | 0;[/code:32wnyed3]

Alternative fix that doesn't truncate the larger integer values that can be stored as a float.

[code:32wnyed3]this.data = parseInt(val, 10);[/code:32wnyed3]

[b]Clarification for anyone confused by my post[/b]
This is the difference between floor, ceil, round, and int. I provided what results you should get and how it works (and some alternative examples if that helps).

floor(-1.6) should return -2
floor(1.6) should return 1
How it works: int(value) < 0 ? int(value) - 1 : int(value)
Alternative how it works: int(value) - 1 * (value < 0 ? 1 : 0)

ceil(-1.6) should return -1
ceil(1.6) should return 2
How it works: int(value) >= 0 ? int(value) + 1: int(value)
Alternative how it works: int(value) + 1 * (value >= 0 ? 1 : 0)

round(-1.6) should return -2
round(1.6) should return 2
How it works: int(value + 0.5 * (value < 0 ? -1 : 1))

int(-1.6) should return -1
int(1.6) should return 1

If your code currently uses int() and is stable, replace it with floor(), cause that's what int() is doing right now except that you'll have the proper function name.

[b]Definition of "integerizing"[/b]
This is programming jargon that I'm incredibly accustomed to and expect everyone to know, but this was obviously a lousy assumption on my part. So I'll provide the definition here.
To "integerize" is the act of casting, usually, a 32-bit or 64-bit floating point value to a 32-bit integer with the purpose of trimming off the decimal points, leaving only the whole number and its sign (- +).

[quote:3q74x4u3]So, who are you?

I'm Nicholas, a 25 year old professional software engineer from California.

[quote:3q74x4u3]How did you find out about Construct?

Heard about it when I was looking into non-programming game engines. I looked at it as more of a joke for several years before I took it as a serious platform when utilized correctly.

[quote:3q74x4u3]What brought you into the seedy underworld of making games?

It started when I was 7 and used RPG Maker on the PSX. I knew I wanted to make games.

[quote:3q74x4u3]What interests you?

Electronics engineers, robots, arduino, programming language development (meaning I make my own programming languages), and middleware (because the world would slow down without it).

[quote:3q74x4u3]Where have you been, and where are you headed?

I've already written several games. They were all programmed by hand. I'm recreating my games in C2 to validate what I noticed as a potentially strong platform. Assuming I can successfully recreate the games within the limitations of the engine, I plan to make my next game with C2 and forgo my typical route of programming by hand.