Cool, I'll have a play around with that later. Does the invisible sprite also need to have the main movement routines (eg I'm currently using MoveTo + Line of Sight to chase the player when they can see him), or can you assign those to the main sprite, and just leave the pinned invisible ones as Custom Movement with Solid enabled and it'll work itself out?

My main problem in the past has been the way sprites sort of 'pop' around the place when pushing out of solids, especially when clumped - it just looks glitchy and bad. A lot of my game is also in very tight tunnels which makes it doubly hard to find something that works.

As far as I know, you just have to pin the invisible sprite to your enemy sprite, you don't even have to use custom movement on it, it will just follow the enemy sprite around. But as DUTOIT suggested I'd rather not use the solid behavior and set the AI myself whenever the invisible sprites collide. That's doubly true if you're gonna have tunnels in your game, because if you set the force fields to solid, then the enemies might not fit into the tunnels, or bounce around a lot when they're traversing them. Also I'm not sure how it would work out if both your enemy sprite and the invisible one are solid.

I think what he means is pinning an invisible sprite to every enemy, and making that sprite have a bigger hitbox than the actual enemy sprite (the area which you don't want other enemies to enter). You should also place it in a container with the enemy. Then, whenever those sprites collide with something, you can do whatever your logic determines (such as making the enemies go away from each other and then continue to pursue the player), or if you want the easy way out you just give the invisible sprite the solid behavior.

This way you achieve enemies never clipping with each other without actually having to affect their hitbox (which I assume you want unchanged for shooting them or whatever way you have of damaging/defeating them)

If your buttons are sprites you could try disabling collisions on them when the corresponding layer becomes invisible

define your own function which calculates the sign, you can call it in expressions with Function.Call("Sign", x)

YES!! IT WORKS!!!

THANK YOU <3

The usual method for isometric or 3/4 view Z-sorting in C2 is to add everything you want sorted to a family and set up an event like this:

For additional control, I like to add an instance variable to the family called elevation, and sort by IsoObject.Y+IsoObject.Elevation. That way I can change an object's sorting priority without changing it's position. Hopefully you can adapt that to suit your needs.

Thanks, I'll try doing that. I'll calculate the Elevation prior to the sorting by using the X positions of the bullets relative to the Screens on the same tile. I'll tell you if it works out.

Hi, thank you for your reply

How would that event look? I'm trying to picture it but can't

I forgot to mention that I'd rather not use hitboxes if possible, it should be a purely position-based algorithm

Hi everyone,

I'm currently building a 3/4 perspective board game, and so far I'm having a LOT of trouble with the z-order. Normally it would be a breeze, but I've got a certain element of uncertainty in the game.

As you can see, I've got these screens which make bullets bounce, and depending on where the bullet is coming from, the bullet should be either in front or behind the screen when they share a tile. I've tried a million different approaches to the z-ordering but every time there's a certain case where it doesn't work as intended.

Does anyone know of a reliable algorithm to sort my sprites in the Z layer? As you can see, it's not a thing of just moving things with the highest Y to the top of the layer.

Cheers

I'm not clear on what the advantage of the "alias" feature is over just putting object UIDs or IIDs in a local variable and using that to reference objects. It sounds like the name of the local variable would basically be the alias.

I was suggesting it as syntactic sugar, if your Object has more than 5 or 6 instance variables and you wish to compare most of them between both objects in a collision, then it becomes a tangle of local variables and subevents that would be avoided if you could just have an actual reference to each object in the same condition block. A similar thing could be accomplished if Object references could be assigned to local variables, but I'm guessing there's a good reason why that isn't implemented either.

[quote:14xf561p][quote:14xf561p]the engine could just as well support aliases by treating the SOL as an associative array.

That would be disastrous for performance. Ordinary arrays are essential for strictly O(1) efficiency.

If it's a performance issue then there isn't much to be done :c

PS: Ashley, what about my other suggestion? About having combined AND/OR blocks?

Another godsend of a feature would be the possibility to combine "AND" and "OR" blocks within the same event. Something like

Player.X > 10

Player.Y > 10

-or-

Player.X < 20

Player.Y < 20

Where both the top conditions OR both the bottom conditions have to be true for the event to be triggered. Lack of this feature sometimes results in a lot of repeated actions and some clunky nested events scenarios that could be easily avoided

I just checked, and the object(index) is not re associated in the sol for the collision event. Perhaps that may be a bug? Ashley

However I still don't see how naming an object would be useful as you are stuck using the same picking methods, at least at the local level that is.

Maybe you could explain that a little more?

The thing with System pick nth is that you can't differentiate both objects within the same set of conditions, so if you want to compare their instance variables, you have to store them in local variables, but if you also want to check for individual properties, you have to do it in separate sub-events.

With aliases you should be able to do all those things within the same sub-event without having to rely on local variables, which in my opinion is a very good thing, because it helps to keep code more readable and less cluttered with unnecessary sub-events