This is what we talk about ?

https://www.dropbox.com/s/ap7w3ni8wf6di ... .capx?dl=0

This is what you could not show ?

Not in the inventory does not mean it is not in the array. Did you look at the array in the debugger ?

You dont show how you let the inventory read out the array.

Adding to previous info.

Say you set the names of a footbal team on the X-axis. And now you want to also keep there weight and there lenght.

This will be a 2D array. And the adresses in the Array are like this:

player 0 name on array(0,0)

player 0 weight on array(0,1)

player 0 lenght on array (0,2)

player 1 name on array(1,0)

player 1 weight on array(1,1)

player 1 lenght on array (1,2)

Reading you question, you think that you need to do this in a 3D array. Naw, not need.

Okay, so you know the weight and you know the lenght. How do you trace back to the X ?

Got to run trough the array with 'for each element' ..

Use 'Compare at CurX,1' = weight

and 'Compare at CurX,2' = lenght

If true, CurX will be what you seek.

Manual:

CurX

CurY

CurZ

The current zero-based index for each dimension in a For each element loop.

Me:

Where is the For each element loop ?

I dont see your hero. I dont see the tilemap. I dont see how they interact. Lets suppose its a platform.

I would like to give you 2 things 2 think over.

First.

Speed is set as pixels/second. (I would welcom an action that sets speed/dt)

What importand in this is ... to know how many pixels something with a certain speed moves between the same event in the sheet.

The time it takes to check again an event you can read in the expression dt.

Now suppose an object is 1 pixel in size. And it moves at a speed 200 pixels/second. (= is rather slow)

Suppose you have an 'on collision' event.

Suppose the object it has to colide with has also a size of 1 pixel.

Suppose it runs at 50/second.

Now every dt (tick) this object moves 200/50 = 4 pixels. If the objects that it has to collide with is on a position%4 not = 0, there can be no collision dedected. Moving object is just never ever on those positions.

So, Size Matters.

Secondly.

Push-out-off-Solids. (PooS). Actualy, platform, bullet, physics all those behaviors depend on PooS.

Platform by example. The hero jumps. Falls. And then, at one moment, he actual wil overlap the Solid with some pixels. Now the PooS routine starts. It moves the hero back up till its out of the Solids. And that is how the hero walks on the Solids.

If you use a tilemap. Each tile has its collision map. Now again. Hero jumps. Falls down. TIll that moment he will overlap the tilemap. But now the hero is overlapping (depending on the speed as explained) a lot of tiles (because they are 1 pixel tiles). And they each start the PooS. And probaly some dont know whats up or down. Resulting in weird calculations, and they are probaly not even all calculated when the next tick arrives.

Again, Size Matters.

Thx 4 that Site.

That´s why I moved those ground images (background images) separately (which now looks bad of course). There still was an error.

No, no. Objects can overlap.

The collision polygones insides objects with a physics behavior can not overlap. Worser. Often Construct cant auto find colission polygones when you import a frame. In that case there wil not be 1 collision polygone set. And that gives countless errors if you give such an object a physics behavior.

Lesson 1: When you import an animationframe, check the collision polygones. Be in control.

Ok, here is the capx i looked into.

https://www.dropbox.com/s/tkpi3u9y14di1 ... .capx?dl=0

I have totaly no errors anymore. But then again, i am to stupid to play the whole level. (althaught you can just fall on the lunchbox in the space between the walls on the left, completing the level in seconds)

Best try yourself. I hope you dont have errors too this time.

I did two things. I kinda fixed the animation of your main character. Now it has a stable origin. And stable colission polygones. And it rolls so much nicer.

I lifted the chain creation out of the 'on start of layout', and made it only happen in the levels where they are actualy present.

I am a bit suprised that it all runs at a acceptable pace. Yet. That event sheet is full of unneeded events for a certain level. You have one sheet for all levels. As a result, lots of events check for objects that are not in the layout. I dont understand how you understand all this. Hat off.

The events about the Boss, for example, run in every level.

Would it not be a lot easyer if you used groups ?

https://www.scirra.com/manual/80/groups

You can set groups active & inactive. That way you can still have 1 eventsheet.

Have a group for events that are needed in every Level. Like the events that move the player. This is always active.

Have groups for things that only happen in a certain level, and set this group active based on the level name.

Now, the chain creation, for example, gave objects that are not in the layout and not global, a physics behaviour. The chains are not in every level.

WIth not in the level i mean: they have no grafic representation. They have no 'sprite' and therefor no collission polygones. Because they are not global. Yet they get the physics behavior set. But physics cant find polygones. And then you get that error.

Well thats my 'unconfirmd' analysis of what is happening. Ofcours, i can be wrong (again).

zenox98

You can not account for everything a users does, or tries to do. I agree that this is impossible.

Yet, is it a good practice to allow the physics behavior on objects that are set as not global? Physics is global though ? Else setting gravity in one object would not set gravity for all.

In this topic is a shift effect plugin.

I have no idea if it suits you.

Normaly you can apply effects also on a layer.

Cant promiss all, but can try eh

Can you upload the 'fixed' capx again ? Will go trough it one by one this weekend.

The error you get there usaly is about what i mentioned.

Also, you have to close the browser, between the tests.

As i said.

The collision polygones of clark animate to much. It will get stuck.

The collision polygones of

Sprite21

Sprite26

Sprite57

Sprite56

Sprite53

overlap eachother, thats a no no for the physics engine

99% of the sprites have collision polygiones that Construct guessed by import. They are all messed up.

This is just uncarefull coding.

Not that i expect you to listen this time.

It runs fine when i correct the biggest problems.