Ah, thanks guys, I'll give that a try shinkan.

Edit: Worked for the cursor, but since I have objects on other layers that I drag and drop, it seems to conflict there giving the same result as before. I might have to just set a global variable for mouse/touch position. I'll mess around with it a little more first though.

Solved: I used mouse("layer") on a layer that was scaled and it worked fine.

Hi there.

I'm trying to make zoom capability, but one of my layers seems to scale incorrectly, and I'm not sure why.

I have a UI layer and above that a cursor layer, which has my cursor sprites on it. The sprite has its position set to the mouse.x and mouse.y coordinates every tick.

But when I change the layout scale, the mouse position and the sprite are in different places. At the middle of the screen it doesn't do this as much. I tried setting the layer scale rate to 0 but to no effect.

Edit:

Looked at the mouse coordinates, looks like they change based on the layout scale. Made the sprite set to the mouse position though, using cursor x = (mouse.x - (mouse.x - scrollx) / 2) and the same for y.

Hah, doge.

Use physics behavior and just apply force or impulse, whichever is more appropriate for what you're doing, towards the player's X and Y coordinates.

Windwalker

Well, a massive scale - no, infinite - universe destroyer god game might be interesting!

Hmm. Not a bad idea actually, might be my next project.

newt

I suppose it would be pretty easy to make this into a boid. All you would have to do is apply some varying forces instead of setting position.

Pretty much not a whole lot, though it could be useful in making a game set in space that had a lot of moving objects over a long period of time, in order for the actual objects to not move too far away from the origin point or more accurately to move the origin point to wherever. The actual xorigin and yorigin coordinates could be useful in calculation for spawns and such, e.g. distance away from the center (which would have the highest density of objects) determines the chance to spawn something, such as a black hole.

It works with scroll too I believe, but I'll have to try that one out. Right now it's practically useless though, since there's no real need for it in anything I'm thinking of working on.

This is mainly just a proof of concept for some metaphysics. Well if ever I create a space RPG it'll be useful though! =P

moymoymoy

Well damn. Good luck, and ramones right, same thing with image points.

I guess if the animation changed just after it collided it could think that it was not overlapping and thus able to collide again. Also, you really should add a text box for debug so you can work out what is happening. Something like append "collided " to it when it collides. If it shows "collided collided " then you know it was the animations problem like ramones suggested, otherwise... Good luck!

Also I really don't know why your character is falling through platforms, that should be completely separate from the Forest Cow events, so unless you had that for each for everything in the project I'm not sure what's going on there, but I'm pretty sure it's not the for each.

Just wondering, jayderyu, if you know of an equation that could give a smooth non-revolvey movement?

I've been using this formula...

((distance(Objects.X,Objects.Y,Cursor.X,Cursor.Y)^2 / 500 + 10) + Objects.Physics2.LinearDamping * sqrt(sqrt(sqrt(distance(Objects.X,Objects.Y,Cursor.X,Cursor.Y))))) * Objects.Physics2.Mass / 100 + sqrt(distance(Objects.X,Objects.Y,Cursor.X,Cursor.Y))

But I think that's probably a bit overkill, and it can most likely be factorised / simplified as well.

Edit: You'd be surprised how well it works though =P

Ah, now you mention it try putting a system>for each at the top like hornet suggested, and have all the "Forest Cow Movement" events under it. I tried the original one with two objects just then and it did something similar to yours. It seems else has problems with instances.

Example:

[attachment=0:1t7ohwjm][/attachment:1t7ohwjm]

By reading that it seems the program is reading it like this: shake = 1 so set shake to 2, now shake = 2 so set shake to 1. Thus it will just stay as shake = 1.

Try using an else, incorporated into the second event, that should ensure it doesn't do both events.

Example capx:

[attachment=0:2yba4cz1][/attachment:2yba4cz1]

-snip-

Well I'm confused. Here's a working one, no idea why it does work, since it's pretty much the same as yours.

Also I tested it with a string, just like yours, and it still worked, so I'm not sure what it is.

[attachment=0:24fuppzk][/attachment:24fuppzk]

Hi. So this is something I've been thinking about for a while, and that is, how do you create an actual functioning relative game world?

Well, I sat down today and made it, and was surprised when it didn't take very long at all.

[attachment=1:2ptxwiu8][/attachment:2ptxwiu8]

[attachment=0:2ptxwiu8][/attachment:2ptxwiu8]

What it does and why

It basically finds a "center" of the universe. It means that the actual origin which in most games is at (0, 0) is not constant, but determined by the location of every other object, the average. In this way no-one can really say they are at the center of the universe, because the center is not literal, it's just where everything else seems to be.

And as for the reason, this demonstrates that there can in fact, logically, be a center of the universe. Trouble is we would need to first explore the entire universe and find the density of everything just to find it.

The processes

This is such a simple idea I'd be surprised if no-one had tried it before.

It's basically 3 steps.

1. For each object, add the object's coordinates to a global variable.

2. Divide this global variable by the amount of objects to find the average position.

3. Take away this average from the current positions of every object, and add a constant offset value to keep it centered rather than in the top left corner at (0,0).

And that is all there is to it.

There are a couple of ways, either an instance variable for the amount of frames left until you can shoot, a timer, or an instance variable which sets the time with a later event to check if [time] is greater than the variable + something.

For example.

1. I fire, it sets player.firerate to its default, 100.

2. Every frame, decrease (firerate) by 1.

3. When you fire, it checks that player.firerate ≦ 0

Not the best way, but it gets the job done.

Here's a capx.

[attachment=0:23548nrc][/attachment:23548nrc]