Ah, okay. I think I see. Maybe. But I just woke up and haven't had my coffee yet. I'm sure that light-bulb-turning-on eureka moment will happen some time though.

Okay, I'm trying to build a blob.

Here is my inspiration:

http://cowboyprogramming.com/2007/01/05/blob-physics/

I've had a little success making small blob constructions of nodes and cross-bars, but I've had to make each node and crossbar a separate object and attach each piece by hand with Create Hinge. And simple blobs with only a few sections don't behave very well.

I thought I could automate the process with loops to create a larger, more complex blob. Here's the blob I want to make:

<img src="http://i25.tinypic.com/16a7b6g.png">

It has a total of 33 nodes, 16 outer walls, 16 inner walls, 16 outer spokes, 16 inner spokes, and 16 crossbars. That's a grand total of 113 objects.

Now, I could go and make each object separate, but that would be tedious. And I could go and make Create Hinge actions for each object separatly, but that would be SUPER tedious... the outer nodes have 4 connections each, the inner nodes have 5, and the center node has 16. So that's a total of 160 or so Create Hinge actions I'd have to code in the event sheet on top of that.

That's a lot of work. I'd much rather just make one of each and use a loop to duplicate and attach them.

I can automate the spawning of all the objects and put them in the proper position for attachment. That's no problem. The problem comes with attaching hinges from one object to another...

When I pick an object, I can pick it by it's private variable and Construct knows which object I'm interested in. But when I do this:

+ Spoke.value("currentSpoke") = 1
[ul]
	[li]Spoke: Create Hinge to Node at Image Point 0[/li]
[/ul][/code:3pdxtf9q]

Construct has no idea which node I mean, because there's no way to specify which second object I'm interested in manipulating.

Or is there?  Is there some method that I'm missing?  Or is this beyond the scope of Construct at the moment?

(And yeah, this has to do with the polygon drawing thing I asked about earlier... eventually I want to make the blob parts invisible and just draw the outline around the blob, I just thought I'd get the easy part out of the way first.)

Awesome, thank you both. And neverk... nice first post!

Still, if possible I would like someone to point out to me why mine doesn't work. Obviously I'm doing something wrong, it would help me learn to know what.

Yeah, I'm gonna take a look at this, see what I can learn

EDIT: Whenever I try to scroll down, I get three dialog boxes saying "An invalid argument has been encountered". In your project. Never happened to me :O

That's just one bug in a list of them that I have yet to report. It happens if you click the scrollbar in Construct before clicking in the window itself.

Try it with your own .cap, I don't think it has anything to do with mine specifically.

Doh!

I just realize that the offset of the line was due to the fact that I didn't realign my hotspot when I made the node sprite. But the rest is still broke.

Nooo... don't keep it to yourself! I want to see the results of your collision experiments.

hrm... pixel shaders..

AUGH DON'T GET ME STARTED *SHAKES FIST

Yeah, I realize that. Like I said in my TIGS thread, I feel kinda bad that the largest project made with Construct to date is about Hitler on a temper tantrum.

Sorry, Ashley. It was the Random Game Name Generator what did it So far though nobody has scolded me for making it.

But yeah, nobody go promoting this elsewhere as a turorial. It's in no way official, and has no affiliation with Scirra. As a mere Construct user, I take full responsibility for it as my own creation.

I'm trying to get the canvas to draw a line in a loop between four objects, from one object to the next, in order to draw a polygon.

Here's the .cap:

http://www.mediafire.com/?yamw9oepewn

I have four copies of a sprite, and each copy has it's own private variable called nodenum. They are numbered 1, 2, 3, and 4, and this number is stored in nodenum.

The I have a counter object that contains drawfrom and drawto variables. It starts at drawfrom = 1 and drawto = 2. It's supposed to find the node who's nodenum equals drawfrom and store that node's x and y coordinates in yet another object's private variables (ax and ay). Then it finds the node that matches drawto and stores it's coordinates in bx, by.

Hope you're with me so far. Anyway, the counter then counts up drawfrom and drawto, so now drawfrom = 2 and drawto = 3 in preparation for the next line.

Then it's supposed to draw a line on the canvas from ax,ay to bx,by, and start the loop over again.

Here's the event sheet:

<img src="http://i25.tinypic.com/24e81tl.png">

I'm having two problems:

1. The canvas seems to be resizing upon running the layout.

2. It's still drawing a line... but it only draws one line, and the line is offset from the nodes 1 and 2. Like this:

<img src="http://i32.tinypic.com/2mq3g2b.png">

The tan part is the canvas. It's supposed to cover the entire image.

I'm pretty sure the canvas resizing is a bug, but it seems like it wants to draw anyway. But there's only one line... is there something wrong with my loop? Should I be doing this differently?

You're forgetting the main thing :

Compare Construct 1.0 to MMF 2 without extensions.

Construct 1.0 wins so much.

MMF2 has extensions, but Construct supports them too! So it's up to the community to create whatever they need, a pixel physics? Other stuff? All possible with plugins.

You have a point, but the reverse is true also... MMF extension developers can (and have) extend(ed) the capabilities of MMF.

So will Construct have per-pixel physics one day? It's likely. Then MMF will have this. And Construct will have that. And back and forth. There will always be advantages that one has over the other. It's up to people to decide for themselves which they want, or need.

All I'm saying is that right now (with Construct in an incomplete state) if want to make a hassle-free game and you can use MMF, then use MMF.

Personally, I think MMF is superior to Game Maker. But Game Maker has a much larger community than MMF. Go figure. It's all about what people are comfortable with.

When the time is right, users will come. Already a couple of people who saw my thread at TIGS have tried out Construct. I think that's going to be the best way to spread the word for now... just make some cool stuff and throw it out there for people to enjoy. Those that are interested will bite.

I was actually never able to understand MMF's interface. And I think Construct is generally easier to use. Yep, I love it, so I'm sticking with it.

While I eventually got it down somewhat, I never got over the annoying fact that you have to scroll back and forth in a spreadsheet to hunt for your objects and hover over some little checkmarks to see what your events are, so agreed 100%. Construct is hella easier to use.

And I'm sticking with it for now because I don't have any of my deadly-serious projects ready to go yet, and I don't have the skillset to start them, so they can wait along with 1.0. It seems that Construct and I are developing at a similar rate, so by the time 1.0 is ready, I'll be about ready to start on a major project.

I just want to interject something here...

Construct has better hardware support and physics,

Yo, check this out:

My First Skydiving Academy

Physics in MMF. One of the most polished MMF games I've ever seen, too. It's damn near flawless.

MMF might have it's physics drawbacks, but so does Construct. MMF can do per-pixel stuff, whereas Construct can't. It's likely there will always be differences like that between the two, causing people to waffle on which one they want.

So if it's a matter of sitting on the fence, well... go with MMF for now. It is more viable. It's a much more complete product, and hence a more logical choice for game development at the moment. The time you spend mulling over which product to use you could spend instead on creating something cool.

Other than that, I agree with ssbfalcon. Just give it time. It'll all come together eventually.

Whenever you talk about what's new or fixed in the next build my shriveled Grinch heart grows three sizes.

Sorry to have cluttered up your thread, Attan.