http://dl.dropbox.com/u/8626299/someshite/index.html

Threw this together in a few minutes.

Can't wait to see where C2 goes!

Just updated the graphics card driver, bug persists.

I'm experiencing some very odd behaviour... I think it may be linked to 64-bit windows, and not a bug in construct perse, as it happens in every version I've tried, even very old ones, but never occured on my old laptop (running 32 bit vista and then win 7).

Anyway, the bug(?) is, after editing any sprite with a width less than 16, the sprite is squashed vertically. This is particularly annoying, because 16*16 is a very useful sprite size.

It even happens when going back into an old .cap. The sprites will be fine until "edited", where upon saving, they will become squashed - so it's something to do with the sprite editor? Sprites imported through the animator will also be fine until edited.

Can anyone using 64-bit windows 7 (or maybe vista too?) check this out/confirm it?

This sounds like the behaviour I reported way back in .99.6. They appear to be working in 99.80.

<-Looks for "Is on ground" condition in custom movement behavior.....

Nope not there.

Is overlapping --> Push out.

What's hard about that?

Edit: Nevermind, i mis-understood what you were talking about.

Doesn't sound like a problem that couldn't be solved with events, at any rate.

Also, aren't you a proponent of using the custom movement plugin?

Edit 2: Something like the "overlapping at offset" condition of sprites can be used to test if an object is "on the ground" quite easily.

> Because it doesn't teach the... erm... "player" about events

>

There is this misconception in development that you should do everything the "hard" and "true" way. That is not true at all. If you're looking to learn then yeah you should go learn events. If you want to get something done, then the easy way that works is just as good.

I assume you meant "the creator" and not "the player", as the player doesn't need to know (and shouldn't know) anything about events.

Making games is a game, a fun passtime --> The player is the creator.

It's not about doing things the hard way just 'cause, it's more about learning the hard way incase you need to use it for something later on. (Also, maybe the hard way has other benefits... easier to read code/events, better structure?). Construct's event system gives the player lots of power and flexibility. Personally, I think most of the movemement plugins are redundant and even dangerous as they do not promote clear thinking and problem solving --> Construct is easy enough to use as it is.

[quote:2j32u4oj]

Additionally...

-is it faster at run time?

-It's not exactly hard to write those couple of events

-what's wrong with teaching players about physics at the same time as Construct?

-Its faster as the plugins are C++, not interpreted events. It probably doesn't matter, though, at this scale.

-If it's not hard to write the couple of events... then why the fuzz about it? why do more work than needed?

-what is wrong is teaching people to always take the longer road to a destination bad practice!

-I don't know much about the internals of Construct, maybe you're right on that one.

-Not sure what your point is.

-This isn't about taking a shortcut for an experienced user, it's about building your knowledge of the program. To elaborate on your analogy to driving... what's better, learning to drive in the rain and snow and at night and in other conditions or just learning to drive when it's sunny and clear because it's easier?

Custom movement would also be a good idea, it has gravity(by way of force) too IIRC

I was using the custom movement plugin.

> I don't think this is a very good way to learn how to use Construct well.

>

why not? it's faster in both design and execution and yields the exact same numerical result.

Because it doesn't teach the... erm... "player" about events, which is where Construct's power lies. When the player is already fluent with events and program flow in Construct, maybe it would make sense to do it that way.

Additionally...

-is it faster at run time?

-It's not exactly hard to write those couple of events

-what's wrong with teaching players about physics at the same time as Construct?

Actually, I've made grenades that way.

But yeah, if you just need a bullet that arcs towards the ground, why not just use Bullet behavior, spawn it at the angle you want, then every tick you turn it a little bit towards the ground?

That'll give you an arc, but it won't look or behave "naturally". Also, bullet behaviour doesn't have an explicit "accelerate" action. I think bullet behaviour is a tad more efficient than custom movement, but it's far less versatile.

I agree, plus the solid attribute works with other behaviors, unlike physics.

My example used the Custom Movement plugin.

you could also use platform behavior, set ignoring input on create and set vertical and horizontal speeds.

Make sure to set air deceleration to 0 in the platform behavior options.

I don't think this is a very good way to learn how to use Construct well.

In the real world, gravity applies a constant force to an object, and (air resistance aside), an object probably won't slow down horizontally. How can we describe this behaviour in Construct? Simple.

Let's assume you're using the custom movemement plugin (not essential by any means), we'd probably have something that looks like...

+ System: Always (every tick)
-> Projectile: Accelerate vertical speed : 200
[/code:7yqzx6b2]
and 

[code:7yqzx6b2]+ (event that creates bullet)
-> gun: Spawn object Projectile on layer 1 (image point 0)
-> Projectile: Set speed : 400 towards 30 degrees[/code:7yqzx6b2]

This reads as: every tick accelerate at a rate of 200 pixels per second^2 towards the bottom of the layout, with initial condition of 400 pixels per second at an angle of 30 degrees whenever a bullet is created. This will give you very realistic and satisfying projectile motion.

Hope this helps. If you have any more trouble, maybe I could break it down further for you.

Conway's Life.

Built this afternoon with an array, a canvas, and one huuuuuuge for loop. There's probably a better, more efficient way to do this, but as far as I can tell, this obeys all of the rules of Conway's Life.

.cap included for those interested. If you want a random field generator, untoggle the first event and right click when the game opens.

Left click places a punnet (on a 50*50 unmarked grid) and right click starts the simulation (can't pause or add new punnets after that).

Erm, Enjoy!

A custom (square?) collision mask or bounding box might solve the problem. (Yes you can).

hmm. Just tried the custom movement "bounce" action. Actually gave a better result than push out, you should try that.

Edit: I don't think physics behaviour is really compatible with any other movement plugins...

Edit: Nevermind, bounce gives pretty poor results with lots of units.