If the player stands still the enemy will not collide/damage him.

Here is my current WIP - http://www.stencyl.com/game/play/14118

I have been having a problem with collisions for a long time, the enemy will not actually damage you unless you move into them. In the game's current state I was toying around with having the character not physically collide/be blocked by the enemies, so that he could walk past them, but still take damage. So both the character and enemy have 2 collision shapes on each of their animations.

One collision shape is not a sensor and the assigned collision group collides with tiles.

The other collision shape is a sensor and I currently have it set to collide with both of the opposite character's collision groups.

I'm not really sure what the issue is here, and if someone could please point me in the right direction that would be great. Please tell me if there's any other useful information I could provide.

Even in an older test version of my game where the player would be stopped by enemies upon running into them, you still won't be hurt if standing still, but if you run into them or jump ontop of them you will take damage. http://www.stencyl.com/game/play/13712

One last thing, the enemies have modified Health behaviors so that they make take damage from multiple projectiles at the same time. However even by setting their Health behaviors to the default behavior, it still has the same effect on collisions, so I don't think it is a factor. The changes made to the Health behavior can be found in this thread: http://community.stencyl.com/index.php/topic,12061.msg73788.html#msg73788

Thanks again and hopefully someone can help! 

I presume the green at the feet is when the player takes damage?  There is some weirdness where if you move for just a fraction of a second and then stop, the green blips stop, but you continue to flash every so often even though not taking damage anymore...

I've had some similar weirdness with collision detection.  At one point I had it so enemies would collide into each other (so that the one in 'behind' would slow down so they wouldn't overlap so much) and I discovered that if two actors are moving in the same direction at the same speed they don't trigger a collision at all.

I've never had a moving object and a 'still' object refuse to collide, however.   Would you take a screencap of the 'on collision' code between the player and the dino?  Which actor is set as the sensor and which is non-sensor?  (I presume the dino is non-sensor?)

I have very little experience with non-sensor collision detection.  For my games I almost always use sensors and only sensors and my own limiting/binding code - though with jumping and the need to stop when you hit the ground that might not be the best approach.

OH I know what the problem is.  Maybe...  Do you only have one collision group type, or multiple types?  (In other words - are there any collision group types that are different from 'Same as Actor Type (default)? )


I have another small suggestion fix.

The projectiles - after you create them, move them up by 1/2 their height and left by half their width;
[set x of [self] to [[get x of [self]-[half-width of [self]]]
[set y of [self] to [[get y of [self]-[half-height of [self]]]

I was trying to figure why the aim was all crooked - and that's why.  The 'location' of an object is at the top-left.  (Things would be SO much simpler for me if the location was the same as the scaling/rotation point, but that's not the way it is.)

The green at the feet is left over from the Run and Gun example game. It's just a particle effect when running that I will probably remove, so ignore it. The player himself flashes when he takes damage, the 'negative' effect is applied, I believe.

I don't really know a lot about collisions so how I have it set up currently, as I explained in the OP, is two collision groups for the player, and two for the enemy.

The 'player' group collides with tiles, and it's collision shape IS NOT a sensor because I assume he would fall through the ground otherwise.

The 'player collision' group collides with the 'enemy' group, the 'enemy collision' group, and the 'enemy projectiles' group (This one isn't a factor in this situation.) It's collision group IS a sensor.

The 'enemy' group collides with tiles, and it's collision shape IS NOT a sensor.

The 'enemy collision' group collides with the 'player' group, the 'player collision' group, and the 'player projectiles' group. It's collision group IS a sensor.

I assume the 'on collision' code would just be the Health behavior, which also references the Inflicts Damage behavior. They're pretty much unchanged other than the Health behavior which I have posted a link to the thread with the changes I made, but I could post a screenshot if you still want. Just clarifying that that's what you need, because I don't think there is any other behavior involved.

And so yes, there are collision group types different from default, because one is the same as the Actor Type while the other is not.

And thanks for that suggestion for fixing the aim, I'll give it a try!

Just tell me whatever you think would be the best way to go about this, should I use sensors or no? Would it work better to have the player actually bump into the dinosaurs like in the second game example, or is it easier to make it the first way, passing through the dinosaurs.

Also the player has 1 second invulnerability after taking damage.

Still working on this - not familiar with the pre-made code and I've been trying to find the scripts you use.  Turns out the Health Manager in the Library for 2.0 is probably not the one you are using - then it occurred to me you are using the 'Run and Gun' game mode (because that's where the green ... things ... whatever they are... come from) so am now at least looking at the right code.  I think =Z

I actually wrote a very long responce (before I wrote the previous short one I posted above), got called away, forgot about it - closed the browser, then came back to the forums and realised I didn't post.  Then wrote another whole long thing and then realised I could say what I needed to say without the wall of text - so here goes;  (my attempt at being non-verbose) <-- this was written before I needed to ramble about the code.  If you take that portion of the post OUT, then it's 'brief' as I get 0-0.

Okay, so it looks like the collision code in the 'Health' behaviour (for run & gun) is okay for what you are doing, because it doesn't check actor or collision groups at all.


The changes you made to Health should have no bearing.  Especially since the soloution you used applies more to the bullets than to the health code itself.  You removed a delay that stops the process later on in the chain than the direct collision.


The way you have structured your collision groups is exactly what I would have done too.  The only difference is that I would have used one "Ground Collision" group for both actors, instead of using "Actor" and "Enemy" - but that's a cosmetic thing not a functional thing.


I know that when I moved into the dino and then stood still, I was still flashing though I'm pretty sure I had to move at least once for that to occur.  It might be some weirdness with the two collision types, since the movement would then trigger 'Player' collision type, which maybe somehow changes the state to allow the 'Player Collision' to register.  It *shouldn't* do that, but it's one of the weird things to look into (and I wouldn't know where to begin for something like that other than extensive use of the 'Print' block and staring at the console wondering where things are going wrong.)


What I thought might be the problem when I realised you had 2 different collision groups is that the actor group and the collision group are separate, and they are checked in completely different parts of the process.  They share the same 'groups' though, which makes it confusing the first time through.  (I tried to give my enemies a 'weak spot' so I had one collision for 'hits' and one collision for 'crits' - neither were the same type as the actor type and so at first none of my spells were registering at all until I figured this out.  There's no docs on this, and I don't like asking for help unless I REALLY am stuck!)

Events check the actor type, not the collision shape type.  So if you have an event somewhere that says "When [Self] hits a (member) of [Enemy Collision]" it will never trigger.  In this case, the Health behaviour is used "Actor - Any", so this is not a problem.

What might be a problem later on is if you need to check exactly what hit the player and which 'sensor' triggered it.  This events fires every time a collision happens, and then weeds things out.

Okay, I need to ramble about some of the problems with this collision code here.  Some of this may or may not affect the problem you are having - so if you hate walls of text skip this part - but I need to do this, and the information may help you debug a few other potential problems.

(In case you are wondering - the event I'm talking about is the one called 'Actor  - Any' in the Health behaviour for Run & Gun)

Begin ramble
This empty 'if' statement in 'if this actor [hit][a tile]' is very weird.  When I was trying to find the code you use I found a package that also had this and had a 'stop' inside it.  The current code looks like if you take damage from a dino and then run away - every time you 'collide' with the ground it will deal damage to you (because [Last Collided Actor] is still returning the dino - unless tiles actively clear this even though they aren't actors).  Worse still if the dino was killed this will likely throw null pointer errors.

For this reason I would also put the 'Other Actor' block (which you can drag down from the top) everywhere you see 'Last Collided Actor' - but that depends on your comfort level messing with the blocks.  When using 'Last ... Actor' references you need to be very sure what that will return.  I've had code that created an actor, waited a fraction of a second, then moved the 'Last Created Actor' somewhere else - and found random actors basically got teleported because in that fraction of a second another behaviour created a new actor, which then became the 'Last Created'.

This empty 'if' statemtent might be why I'm flashing if I move into the dino and then stop but not if I'm not moving and the dino comes at me, because it's actually the collision with the ground that's re-triggering the damage.  This *might* be related to what is causing your problem.

This bit about clearing the value of actorCache after a delay has me worried for the same reason, but then I'm OCPD about thread-safe code (which means timing weirdness).  The way this is written - it COULD cause a double-hit every so randomly often, because the actorCache could be set but then cleared immediately by the timer from a previous collision, causing it to trigger again.  This can be passed off

There's some other issues with this code with regards to timing delays TBH that freak me out - but then I'm bordering on OCPD when it comes to my code, and this isn't code you wrote - so I don't think there's too much point going into detail - the problem I see will very rarely impact your game and might triger a double-hit every once in a blue moon and we can write that off as a double-damage critical hit due to insane lucky timing.

The 'being hit' boolean being removed after 0.2 seconds might also cause double-damage for the same reason.  Also the 'remove all effects' will be a problem if you need to apply another effect in another code (ie - a buff where you turn red to show that you deal double damage).  This behaviour does not play nice with others!  Likewise with the Temporary Invulnerability Time.

Despite there being 3 places where it might 'oops' and double damage - the double damage will only ever happen once per hit, so it can be written off as a random lucky critical.

/end ramble

Relevant to you specitically - this collision code looks like it plays nicely with your system of different collision groups, because it is Actor-Any (the downside is it can potentially cause weirdness with some other collisions, such as tiles, but that's in the ramble.)

The 'check' for damage here is not group-specific, but it checks for the behaviour 'Inflicts Damage'.  This is perfectly fine for the most part - but you will have problems if, for example, you want two enemies to check for collisions on themselves for any reason - because ANY time something with Inflicts Damage registers a collision with something that has this 'Health' behaviour, it will take the damage.

If you need to incorporate that, then you need to use the [group for [actor] collliding shape] block in the 'Collisions' group that appears in collision behaviours.

Okay, I need to take a brief break because I've been obessing over this for too long, and I will give you some tips for debugging & figuring out exactly where it's mis-firing.

Thanks for that long, helpful, and insightful reply. I read it all and do not mind reading huge walls of text. I will try some of the things you mentioned and also look forward to your next post. Thanks for being so helpful, this is a major bug that pretty much halts my progress on the game. 

Thanks for reading - I kinda had a sense from your posts that you were a little verbose too so figured you might not mind as much as some people I encounter, though I really did try   

Okay ran another test and a few things;
The 'hit the dino and run away' problem I mentioned in the ramble seems to be a non-issue, I guess colliding with a tile sets the 'Last Collided Actor' to null (or something similar to 'null' that doesn't trigger null pointer errors anywhere else in that code... regardless the point is you don't continue to take damage if you are running from the dino)

On the flip side, sometimes I run straight into the dino and run back and forth without flashing at all.  I actually have to 'stop' or 'run slower' before a flash triggers.  The flip side is if I just stand there and let the dino come to me, it also doesn't hurt.  (EDIT:  Actually maybe that's the same reason - maybe colliding with the tiles reset it and I actually have to stop before it registers?  Something to try.  Gosh I'm spending more time obsessing over this and a few other posts on here today than on my own code, I guess 'procrastination' or something... even though I'm still coding just not on my stuff.)

Oh interesting.  I think I figured it out .  At least the 'does not take damage while standing still' part, and it has NOTHING to do with the collision groups.  I was kind of wondering why the dino didn't run through me and then do some kind of a zig-zag often happens when a 'follow' script nears or is at the target point.
It 'stops' when it looks like its touching the player, my first thought was that the non-sensor blocking collisions were involved.. but then I figured it out   When it was stopped next to me I moved forward just a little and it turned around and began whapping me with it's tail.

The 'location' of an actor is always the top left corner of the 'square' for the animation graphic.  Estimating where that would be, I get why it seems to 'stop' at the player.  I suspect that the hit locations are not actually touching here - the dino's body might be a *smidge* too far away (even one or two pixels)


Because the 'Run and Gun' game does not have code for this, I don't know what you are using for the 'Follow Player', but whatever it is you'll need to change one thing,
Anything that references;

Code: [Select]

([x] of [self])With regards to location and determing which direction to move.
replace that with;

Code: [Select]

({[x] of [self]} + {[half-width] of [self]})
That *should* cause the dino to run up to you all the way until it's middle lines up with your left side (you could do the same with the [(x) of player] - then it's middle will line up with your middle until it stops.  I would make a few other changes so that it runs past you and turns around - but I'm obsessive that way).

If that code makes it stop further away, then change the + to a - (though I'm pretty sure + is the one you want here.)

If the dino runs all the way into you and you still do not take damage, then there's a few more debugging ideas we can try (basically adding if statements for actor and group type checks and printing debug text to console which is much more immediate than 'flashing' animations.  Print statements go to the console which can be opened with the '~' key - if it comes to this I'll make a few blocks up and take screen caps to work through it.)

One more quick thought - I'm actually glad I didn't look at this and base my code off it.  The way I wrote it is much more intuitive to me =Z.  The actor that deals damage registers the collision and tells the target how much damage to take, instead of just being a 'place holder' behaviour to store damage.  Much less mucking about in my opinion.  (That said, this does have ways of preventing multi-hits that are harder to detect that way.  It's easy with a projectile that you destroy when it collides but for something like being trampled by a dino that doesn't work so well)

Oh I forgot to ask - if the above doesn't work may I see a screenshot of your 'Collision' tabs for each actor so I can see where they are?  I don't need every frame - one should be fine to get an idea - might help me locate the problem - unless the above is it.  I did run right through the dino and back and forth without taking damage, I was kind of wondering if I was running 'under' the detector.  Maybe I lucked out and missed the tail which I know hits me if I stand under it and it hits me when it comes down.

(One other quick unrelated thing - I suggest allowing the arrow keys as well as WASD.  I've been playing one video game where you use the arrow keys for so much the last few days it's where I naturally reached to play this and I was stumped why they didn't work for awhile before I clued in.)

Thanks, seems to have been fixed. Using your method for my follow player ability and also adding a 'stop' in the Health behavior for colliding with a tile, the player now takes damage normally. I think it was the empty 'if' statement in the Health behavior that was causing the problem altogether, weird that my version of the behavior did not include it...and I don't recall ever removing it, I don't know why I would!

But it seems to work just fine now although the dinosaur can look a little bit funny now that he walks halfway into you, because of how long his tail is it looks like he's not facing you. I may be able to remove the '+half-width' in my Follow Behavior, though. That was the first fix I tried and it still wasn't working properly until I added the 'stop' in the Health behavior. Hopefully I don't run into anymore collision problems now.

Finally, I tried your suggestion for the aim, but unless I did it incorrectly, it doesn't seem to work. You'll see that the bullet now originates over the player, but still flies under the mouse. I think the problem is more likely with the actual calculating of where the bullet should travel to. But of course you don't have the game sitting in front of you. Maybe I need to do some 'half-width' magic with that, or mess around with adding or subtracting x/y.

Here is the game in it's new, fixed state.
http://www.stencyl.com/game/play/14126

Oh and thanks again!

weird that my version of the behavior did not include it...and I don't recall ever removing it, I don't know why I would!

I actually thought it might be the missing 'stop' doing something weird, but I had no way to be certain.

It wasn't your version.  It was the 'Run and Shoot' version, because otherwise I wouldn't have known about it .  It happens that I downloaded Ceric's Health Pack when trying to find out what this 'Inflicts Damage' behaviour you were talking about, and it's the same, but with the stop.  Then when I clued in that you had based your game off of 'Run and Shoot' and that's why the green things appeared - I realised that you health code was there, and for some reason the 'stop' is missing.

I can 'kinda' see that they might want to have damage-dealing tiles... but there's no way to have an 'inflicts damage' behaviour (or ANY behaviour for that matter) on a tile...

Having the dino stop right at the player also looks weird.  Also whenever the dino is to the left of you, the dino will turn around and whack you with his tail (try turning Influcts Damage off, wait for him to come to you and then move to the right just a little you'll see what I mean - that's how I noticed the weirdness.)

I would actually code is so that if he 'reaches' you then he actually runs past you for a bit then turns around and runs at you again - basically zig-zagging back and forth.  I can write that for you if you like - it's not hugely complicated.

Basically I would make it so that if he collides with you from the left, it goes into a one or two second loop where he continues walking to the right, ignoring your position, and vice-versa for colliding from the right, right?

EDIT: Alright, figured it out, here's how it looks: http://www.stencyl.com/game/play/14126

Right now they continue moving for 2 seconds to emphasize the effect, but I will probably move it down to one second because if you are moving towards them you gain quite a bit of distance from them. But this was a good solution and looks much better. If you have any more suggestions please tell me. Also if you see an easy way to fix the shooting/aiming behavior problem (screenshot posted in my last post) off the top of your head, please tell me. I'm assuming I'll just have to try adding or subtracting x/y from the x/y of the mouse.

and btw you won't be able to hurt the little blue guy because he doesn't have the proper collision box yet.

that's pretty good.  Not the way I would have done it, but it works great (and I wasn't sure about the way I thought of to try it - it might not have worked.)

I would actually have it so the smaller dinos turn quicker, so maybe make a 'turn time' attribute.  I would test out 0.5 secs for the small one and 1 second for the large one and see how that looks.

Only problem is... the dinos actually walk right off the screen (and I think thereby the platform and they fall?) regardless they don't come back.  Lowering the numbers might help  (If you play this and just stand there you'll see it)

I don't know if you've tested the shooting thing I mentioned at all - still quite wonky.

There will be walls at either end in the actual game, and the play area will be 2-3x larger(wider) so the dinosaurs falling off won't be a problem.

As I said the 2 seconds was just to emphasize for both you and myself that it was working as intended, and nothing wonky was happening, I will probably lower the numbers, especially for the small dinos since they don't touch you for as long since their sprite is smaller.

I did test what you mentioned - at least I think so. I mentioned in my earlier post that I did make a change to it but all it does is make the bullets originate from a different position, (which is what you intended) but doesn't change the direction they take afterwards. The behavior is attached 2 posts (of mine) ago. You can see the changes I made to the origin of the bullet, as well as how the velocity/direction is determined.

Oh, right.  You want to change the target location by [negate[half-width]], [negate[half-height]].  I misspoke when I said 'move them'.  The part where you use the mouse position in the formula - that's where you need to do the adjusment.

The 'point' the actor is at is always the top-right hand side of their sprite, which is not what you want in this case, so by moving it 1/2 it's height up and 1/2 it's width to the left, it will appear as though the centre is being aimed in the direction you fire.