I'd say it's a bug considering javascript's indexOf() is case-sensitive. There's no explanation or even mentioning why find() isn't case-sensitive in the manual. If someone wants to find where "string" is, and they have "strinG" before it, it will return the wrong index.

having to use regex just to find the index is troublesome, because in some cases you might have to escape specific characters. If you can simply use find(), it would make the process simpler for users.

I don't mind specifying whether to use case-sensitivity as long as there is the option to do so.

Okay, it's fixed.

Question: How to upload a texture in 3D model .obj?

Quazi has an unfinished manual here: https://dl.dropboxusercontent.com/u/829 ... 2-4_2.docx

It has information about textures on page 21..

Problem Description

using find() expression is not case-sensitive. Because it isn't, you have to use more complicated methods to get the results you need. It'd be better if find() is case-sensitive.

Attach a Capx

http://1drv.ms/1PmPKxi

Description of Capx

text object has an instance variable holding a string ABCDabcd. find() is used to get index of "b", but it returns an index of 1 instead.

Steps to Reproduce Bug

run capx

Observed Result

It doesn't return the index of "b"

Expected Result

it should return an index of "b", which would be 5. It should be case-sensitive.

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

vista sp2

Construct 2 Version ID

216

Thanks..

I had to escape some characters to make it work with execJS (since I need to find other characters), so I added string.replace(/[\-\[\]\/\{\}\(\)\*\+\?\.\\\^\$\|]/g, ""\\$&"");

It was creating errors otherwise.

You would need to project the current velocity vector onto the direction vector of the thrust:

https://en.wikipedia.org/wiki/Vector_projection

And measure whether the projected vector is lower than the maximum velocity allowed. If it is lower, then it would be okay t add thrust in that direction.

If I use find() to try and find "a", it will return "A" if it is ahead of the "a".

How do I ensure it finds "a" instead of "A"?

dityaznaka , is your near plane on the camera set too high? Is the object too close to the camera? Seems like it is getting cut off. Any info on what you're experiencing? hard to judge the issue just by looking at the image.

If I plan to learn something while I work, it creates issues with making progress on the work itself. If what I learn doesn't take too long, it is fine. But if I don't know how to do something and it takes considerable amount of time to figure it out, the longer it takes then the more likely it will have negative influence on the progress of the work. You have to judge whether or not what you're trying to figure out is worth the time. If you have all the time in the world to experiment and you aren't concerned with finishing anything, then you can spend time learning as much as you want. If you are concerned with finishing it, then you have to be careful not to juggle too many things that are open-ended.

Game mechanics are tricky, because they are used throughout the entire game, but you also can create more mechanics than are necessary, or you spend too much time tweaking them. I would focus on only the mechanics that are necessary to allow development of the larger systems that the game needs. If the mechanic doesn't serve to progress your work in other areas of the game, then don't implement it yet.

For me personally, I've learnt that I should build only what my hands can hold. I have to know clearly if I can handle something. If there is any uncertainty about whether I can do something, then chances are that I lack experience, and that inexperience will lead me to certain failure unless I can gain the necessary experience.

What I try to do is create boundaries/limits to my work, so that the work doesn't exceed what I am able to handle. If I spend too much time imagining things, I overlook the boundaries to my physical limits, which make things overwhelming. I also think that focusing on the essential parts are more important in the beginning- things that hold the game together, or run deep throughout the game, like a dialog system or inventory system, menu system, save/load system, etc. Those sort of things should be created in the beginning rather than later because much of the game will rely on those. My specialty is with art, but I don't focus on art in the beginning at all, unless it is necessary to visualize something.

I think aesthetics are more important than resolution/style because you can have hd graphics that look horrible if the aesthetics are awkward. You can have low-res pixel graphics that look amazing if their aesthetics are great. The good thing is, that it takes more than just graphics to determine if a game is great.

Thanks!

I must have overlooked the control panel- I don't think I've ever clicked on it before.