v2k, you can also do it using AJAX and php.

I made an app that is accessed through a website where you have to login (using .htaccess) and then pass the username into the Contstruct 2 app using AJAX to call a php script that just echos the username.

RenatoB, I had trouble like that a while ago. I believe there was a known bug where touch events weren't firing in some versions of IE. It sounded like Ashley thought he had fixed it, but I know I had the issue after that (but I may have still been using an older version of C2). I haven't tested in old versions of IE recently, but if you are up-to-date and still having the problem you may want to submit a bug report...

RenatoB, there are a few things in your code that seem a little funny to me, but I tested some of them out and they seem to work (but just aren't quite the way I would have done it).

I believe the main problem is that the CheckAnswer function is not working with the same "numbers" instance as the one you touch. When you touch one, it is the only instance "picked", but when you call the CheckAnswer function it will randomly pick any instance to work with. So, You should pass in the numbers.UID into the CheckAnswer function, and then in there "pick" that unique ID.

One other potential problem is in your "On Start of layout" section, where you "Pick a random numbers instance". You repeat that loop 20 times, but theoretically it could pick the same numbers instance all 20 times. Out of 20 times through the loop, you will have no way of knowing how many instances got picked more than once, and how many never got picked. If you have 20 instances of numbers, and want to set each one to a random animation frame, then replace the "Repeat count times" and "Pick a random instance" with "For each numbers". (the part where you choose a random index and delete it out of the array seems fine as far as I can tell).

komalrajsingh, Very nice job so far! Although it seems the problem still exists...

I believe the problem occurs when the sprPlayerPosition is overlapping more than one ElevatedBox. If that is the case, it only works correctly if it happens to pick the taller box. But that isn't always the case.

I changed the code so that it always picks the taller one (by doing a For Each loop by descending ZHeight and then exiting the loop after the first one). I also eliminated some unnecessary code. Like pinning, you are always setting the sprPlayer position anyway, so there really isn't a need to constantly pin it and unpin it. Also, on your "Else" blocks, you don't need to repeat the condition from above (unless you were doing it for readability). In the Jump block you were checking if the sprPlayer is falling, but it is always falling because it is never actually standing on solid ground.

Using the Platform behavior was a creative way of adding a "jump" ability to your player. Someone yesterday in the forums was asking how to do that, and I like the way you did it!

You can see my version at: rieperts.com/games/forum/Xekorn2.capx

I just tried it too... and agree with Jim15.

The artwork is really nice! then menu system is great. You are off to a fantastic start!

In addition to Jim's comments I would love to see the fish move a fin or something. Even a simple 2 frame animation would go a long way to sell the idea that they are swimming. They already look good, so a little animation would go a long way!

Colludium, Using the plugin to convert to a timestamp is pretty much the same idea as what RamPackWobble was suggesting because it returns a single integer, only it also incorporates the date (as well as seconds and milliseconds). Then you can subtract one timestamp from another one and calculate how many days, hours and minutes is between the two.

Or, if you want to add 4.75 hours to a timestamp you would have to convert 4.75 hours into milliseconds, Round(4.75 * 60 * 60 * 1000) = 17100000, then add that to your starting timestamp.

One thing to watch out for with the plugin is that date.day(timestamp) returns the day of week, not the day of month, use date.date(timestamp) to get the day of the month. This confused me at first, and obviously others if you read through the forum thread for the plugin.

so, if you set a global variable "CurrentTime" = date.UnixTimestamp

then ask it for date.day(CurrentTime) you would get 5 for Friday, while date.date(CurrentTime) would return 31 because today is the 31st of January.

The rest work the way you would expect (Year, Month, Hours, Minutes, Seconds).

To get a timestamp for a given date/time (for example 1:30 pm tomorrow) use: Date.Date2UnixTimestamp(2014,2,1,13,30,0,0)

Have you looked into using unix time stamps? I wrote a calendar app and used the rex_date plugin. You can then convert any date (and time) into a timestamp, and then add it or subtract from any other timestamp - down to millisecond accuracy.

— - did you try out my wall-tracing example? It isn't physics based, but does use the platform behavior, which does have simplified physics - so you can control how strong gravity is, how fast they move, how far they can jump, etc...

rieperts.com/games/forum/Wall-Tracing.capx

RamPackWobble - Thanks! I sure learned a lot doing it! The tutorial that I based it on sure had some serious bugs. I might turn my example into an updated tutorial...

Ok, I think I have it working pretty well... I started with sqiddster's Gravity tutorial: scirra.com/tutorials/273/how-to-make-a-gravity-based-platformer

and expanded on that... Gravity Zones tell it which way gravity goes. If zones overlap it calculates the average angle of gravity. There are two types of gravity zones: Relative and non-relative. Relative ones send gravity to a single point, so they work around curved objects (there is a semi-circle and round variation). Non-Relative zones work along flat surfaces and send gravity in the angle of the zone (these zones have an arrow so you can tell which way it goes - you can rotate them to any angle you need).

The pink bars are gravity reversers. When the player or wall hugger hit one their gravity changes 180 degrees.

The wall huggers go in the initial direction they are told to until they hit a blue direction changer. If they hit a green jump box, they jump. Usually when they get to the opposite side of the jump they are upside down, and by the time they get turned around they are not on the jump box there (but sometimes they turn around too quick and then jump right back).

The main problem is that collision boxes don't come in circles, so for the round objects I made the collision box as close to round as possible, but when players and wall huggers go over the corners of the collision box they briefly think they are in the air, and they can't jump if they don't think they are on the ground. So, there are many times the wall huggers will go right past the jump boxes (usually on the round object but I have seen it on flat parts a couple times too).

It is also real easy for the wall huggers to get stuck - you have to be pretty careful how you line up the floors, and sometimes the gravity zones (the inside corner on the L shape was tricky).

Over all, the code is fairly simple - C2 does almost all the work... it is only 24 events! And it seems to run pretty smoothly, although it is doing a lot of collision checks.

One other slight issue - the rotating square moves, but the gravity zones around it don't, so that confuses the two wall huggers on it a little. If you want moving surfaces, you either have to have the gravity zones move with the surface, or set them up in a way that works (and doesn't interfere with other zones)...

you can get the capx file at: rieperts.com/games/forum/Wall-Tracing.capx

how would it know when to "jump" to another object, rather then just go around the one it is on. In your last example, the red square is on top of the "L" shaped block. Would it circle around that forever after it got to it? Or jump back down and reverse its path? How would it know it can jump to the platform below it, and not all the way over to the circle? If it did jump down to the lower block, would it have to head back to the left, as opposed to continue to the right (and go around under that block) and how would it know not to just jump back to the L shapred block?

(I am just trying to understand all the rules before I try to implement it.)

wow, I remember colour cycling! That takes me back too - On some systems that was the only way to simulate animation! I haven't though about that in decades!