Ok so I'm making a game/engine which is like 3/4 view using physics for collisions and i've put in jumping over and walking on top of obstacles right, but as soon as i have obstacles that have different 'heights' i run into problems.
So i have a familty called Terrain, and every object in the terrain family has a ZHeight variable which tells the game how high the object is and subsequently how high the player will have to jump to get over/on top of it.
The player also has a ZHeight variable that is obviously how high off the ground he is.
So i'm running this little loop:
(Don't worry about the subevent in there, it's not part of this context)
Looking at it you would think it should work fine, cause the objects in terrain have varying heights, a 'for each' should be the way to go. Yet, the collisions are not disabled, with the 'for each' loop there i can't jump over a single thing, so i take the 'for each' loop out, now i can jump over things but it treats them all as the same height. It's quite frustrating. I'll upload the exe so you can see what's going on
You'll have to ignore the sprite laying for now, i'm also having trouble ordering the layers by ZHeight THEN by Y coordinate
WSAD + mouse - move
Space - jump
E and Q - go in and out of slow-mo (soon to be upgraded to super speed once/if physics velocity is pixels per second) currently mostly used for helping find bugs.
Anyway, is this a bug with families and disabling physics collisions? or is there a better way to code this? I dunno, anyone got any ideas?
After running a little test it would appear that "Reset disabled collisions" resets all disabled collisions for that object. What's happening here is your tallest obstacle, when it is reached in the loop, is resetting the collisions for your sprite because, well... it's tall and your only picking criteria is tallness. This is why it was working when everything was the same height.
Try reversing the order of the objects in your "disabled collisions" actions. So instead of saying:
Controller: Disable physics collisions with Terrain
do this instead:
Terrain: Disable physics collisions with Controller
That way each collison disablement is local to the Terrain instance instead of global for the Controller. If that makes any sense.
Deadeye, you're a genius, i've got it to work now, although i had to change the else statement to another 'for each' loop, but i can now try to change it so it works a little better
Thanks! just when i was beginning to think nobody read my threads lol
So now, maybe someone here might know, now that my height problem is out of the way, i wanna know how i would do the ordering of sprites, i've tried the 'for each' ascending by Y coordinate thing, which worked great until i introduced the pseudo Z axis.
I now need to be able to order by Y coordinate AND the ZHeight variable, with higher ZHeights being on top but still being put behind or in front of objects of the same ZHeight if you catch my drift.
Save me deadeye!
Develop games in your browser. Powerful, performant & highly capable.
Oh man, I think you just broke my brain
I'm sorry, I haven't even the faintest clue where to start on that one. I keep thinking a nested loop to sort by z in side of a loop to sort by y might do it (or vice versa, I don't know), but when I try to picture it running all I get is a headache. And to test something like that out I'd have to build my own pseudo-3d thingumer too and... bleah, that's too much work.
Hopefully someone else has some good ideas for you though.
Yeah i just attempted a nested loop similar to what you said, so far it only does the typical Y coordinate one though thanks for trying though
i could send you the cap if you want to try a few things with it
Well okay, I'll give it a shot but I can't promise anything. And I won't be able to get to it until tomorrow, I should have been in bed hours ago.
rightio, shoot me a pm with your email or something in it later
'ELSE' doesn't make sense after a 'For each' loop - 'For each' is actually logically false (because of how the engine works), so I think the else event will actually run like an 'always' event.
I think the best way to handle Z ordering is to come up with some combination value: if you loop by .Y + .Z ascending or something, it might be able to factor in both. I think you'll need to tweak that expression a fair bit to get it right though...
Yeah i've got the loop fixed, the only problem now is the proper sprite layering, i'm stumped
ok so i had an idea that might come closer to working, i've done something like this
for "layers" from 0 to 64
(sub)for each (family blue) ordered by Y acsending
(subsub)Blue.Value('ZHeight') is equal to loop index of "layers" - send to front
it -kinda- works but not really, any help?
do you want an object with a higher Z to always be on top of one with a lower Z regardless of Y value, and only sort it by Y value if Z is equal
surely you can just do (pretty much what Ashley said)
for each object ordered by .y+.z*9999999999999999999999999
I'm trying that method now, I still can't quite get it right though
I'm about to try a differiing variable system though, cause at the moment, the player's ZHeight variable is at the level of the player's 'feet' whereas the terrain's ZHeight is the top of the obstacle, so I'm about to try using one variable for the bottom of the player, and one for the top, and see if i get any better results
Okay, so I was getting ready to test out some stuff in your cap and I moved some boxes around to make it easier to jump onto the big box. I found a little bug...
If you jump onto the big box, and then walk over the edge to drop onto the small box, he doesn't drop. He just floats in midair until the detector is clear of all the box colliiders.
Anyway, I haven't really started tinkering with the Z sort issues yet, I'll let you know if I have any success.
I just can't wrap my head around this problem. I've been trying for a few hours now and I just can't seem to get it working at all. The closest I got looked okay until you walked off the far side of a box, but the player would still be in front of the box until it hit the floor.
I'm sorry man. I gave it my best shot, but if I spend any more time on this I'll go completely insane. Good luck though. I hope someone else can help you out better than I can.
Heheh thanks for trying anyways deadeye, you're a legend, at least you helped with the collisions and found a bug i gotta work on
Still if anyone has any idea how to get the Sprite layering to work, TELL ME
I can KINDA get it with the way Ash suggested, but it needs tweaking
the trick for your zbuf problem is comparing the y coordinates of the boxes on their respective zhieght(from their base)then comparing the height of the stacked boxes and performing the layering from the bottom up(in z height) doing your zbuf for the base first, then for the progressively higher layers
im not sure excactly how to do this, but im working on it atm