Those operators are meant to be used inside expessions and not really that useful in this case.

You can make an event block into an OR block by adding two conditions (in your case 4), then selecting the event block and pressing Y on the keyboard. (or right click)

You could also check if the variable is less than 5 by adding a "System -> Compare variable" condition and selecting "Less than" in the dropbox.

There are many ways to do it, but those should do the trick for you.

A good place to start is just doing some tutorials, even if it doesn't benefit your game directly, you'll learn a lot of useful stuff. Some of the things you mentioned can be found in the FAQ thread in this subforum. It's always good to get a good overview of the basics before attempting something more complicated like inventory and random dungeons.

BluePhaze:

Yeah I thought about that earlier. It's a viable alternative, although not as visual in the editor so it might be difficult for the developer to imagine where the rectangles would be amongst all the other objects in the layout. And as you said you'd have to calculate scale manually. More like programming, so it sort of defeats the purpose of C2. <img src="smileys/smiley1.gif" border="0" align="middle" />

Or give the object an instance boolean "placed", set it to true once the block is placed. Then on the rotate event, only rotate objects with boolean value false.

EncryptedCow

You could, but it wouldn't be smoothed like the lerp would. Depends on what you want really.

BluePhaze:

Kk, thx, just wanted to make sure I understood correctly. It makes sense though, I see how this can be a major issue with mobile devices. But I'd imagine setting it to invisible would take care of that problem though? No pixels rendered, no VRAM needed.

Yea, put all the solids in a family (you can call it "Solids"), then check for collision of the family.

You can also add behaviours to families, so if you add all the objects in, then add a solid to the family, you've added the solid behaviour to all of them. Not so useful now since you've probably added the behaviour to each solid object individually, but it can be good to know.

If you have a license you can put all your solids in a family.

BluePhaze

Like I said, I wouldn't recommend using this for mobile devices, and personally I wouldn't use it at all, I design my levels manually, but he asked, so I provided a solution.

Anyway, I was generally talking about PCs in my last post. I'm not going to argue anything on mobiles since I know little to nothing about it.

As for the 1px sprite I see what you mean, but I found the thread about invisible objects and as far as I understand it, setting it to invisible should skip the drawing of the sprite, saving you the VRAM usage:

Offscreen objects are not drawn, and objects set invisible are not drawn (although objects with opacity 0 are still drawn)

As for sprites vs tiles, are you saying a 320x320 area of 32x32 sprites would use the same amount of VRAM as a 320x320 TiledBackground based off a 32x32 sprite?

BluePhaze:

Well, sort of, but if you're developing for mobile using sprite objects as tiles is a very bad idea in the first place.

And as the manual describes, a TiledBackground object is a lot more efficient in rendering, so it wouldn't be twice the amount of pixels, only the equivalent of one extra sprite object, in this case 32x32.

But the TiledBackground object doesn't need to be 32x32, it could be 1px in size. Or you could set them to invisible, which if I remember correctly will skip the draw call so that only logic is calculated for that object (not 100% certain this is true).

Creating too many objects can cause slowdowns, and a common mistake is to use grids of Sprite objects instead of Tiled Background objects. For example, a 20x20 grid of sprites has 400 objects, which is a significant impact on the object count. A single tiled background can replace the grid of sprites and it only counts as a single object. Tiled backgrounds are specially optimised for repeating their texture so in this case it is literally 400 times more efficient than the grid of sprites. Always use Tiled Backgrounds instead of repeating Sprites wherever possible.

So what I'm trying to say is; I don't think the extra TiledBackground object matters, but using sprites instead of tiles does.

This wouldn't work with a TiledBackground object since it uses only one image. Your best bet is to use a Sprite object for the stone with different animation frames, place it where you want it, then set a random frame on start of layout.

Edit: When I think about it, what you could probably do is have a TiledBackground object that defines the size of the area where you want the stone, then distribute the Sprite objects over the TiledBackground object using events. I can try and throw something together if you're interested.

Edit2:

Wanted to see how easy it was to achieve the effect so here you go, hope it helps:

RandomTiling.capx (r134)

Give the objects an instance variable for "frequency" and one for "active". Then you can use the distance expression to check if the objects are in range of eachother. (see system expressions in the manual)

That should be pretty much all you need, but feel free to ask if you need more details.