[hseiken]

So I'm playing around with a sprite, using sprite 0 as a player controlled entity and I have this bit double up for each direction:

: "tryUp"
copy block at 21 29 for 3 by 4 to 21 32
if c?? Sprite_colliding p?? at "spr0_x" "(&spr0_y&-1)" then "doInputs"
if spacepressed then "doUpAttack"
dec "spr0_y" by 1
cycle 1
goto "doInputs"

Now, the intent was for the sprite to collide with a wall and not do anything. Dunno why it wasn't working, that's not the issue. The issue is that this code DOES make the sprite stop. In seemingly random places and the BLOCKABLE/SOLID/NORMAL blocks I have on the map do affect it...but it's so random...consistently so.

So In one map, I have copy and pasted an artsy fartsy collection of customblocks and made a solid rectangle around a single screen...and the sprite will detect a wall in the middle of the screen both horizontally and vertically. On a different board with the same robots and sprite, etc and this one is just a simple solid wall all the way around, the sprite stops randomly around apparently a single character block near the bottom left of the board.

ANd changing NOTHING about the boards, I switched all the code referencing sprite 0 to reference sprite 1 and suddenly, no more hidden walls...(now I can figure out why my collision detection code isn't working! LOL)

But was wondering if there's quirks to sprite 0 and/or maybe this is a bug? I can post a sample board if needed.

This post has been edited by hseiken: 27 November 2024 - 01:47 AM

[hseiken]

It seems I spoke too soon even after I did all of that hand editing to change every reference of spr0 to spr1, I found the offending line but I don't know what's happening now...because it's behaving the same way again with invisible walls, in the same place...

So now because it's sprite 1 I change this line in each direction to check before moving:

if c?? Sprite_colliding p01 at "spr1_x" "(&spr1_y&-1)" then "doInputs"

The key part is the p01 which I read means to refer to spr1, sprite 1. So I'm assuming 'if sprite 1 will collide at this position, then just skip moving.
And it works, but again, I have no idea why it's working on air. I thought maybe the scrollview position had an effect, so I just moved the player object to scroll the screen where i wanted and left that line out, no change, etc. so now I'm stumped!

[Terryn]

Here're the issues with what you're doing:

• First off, collision checks only happen against Sprite collision boxes and CustomBlocks. Not Solids, not Normals, not CustomHurts, not anything else, just Sprite collision boxes and CustomBlocks.
  
• Secondly, as the helpfile entry for IF Sprite_Colliding explains, its checks are relative to the Sprite when using c?? as the color. However, you're checking absolute coordinates in your code.

[hseiken]

Terryn, on 27 November 2024 - 08:00 PM, said:

Here're the issues with what you're doing:

• First off, collision checks only happen against Sprite collision boxes and CustomBlocks. Not Solids, not Normals, not CustomHurts, not anything else, just Sprite collision boxes and CustomBlocks.
  
• Secondly, as the helpfile entry for IF Sprite_Colliding explains, its checks are relative to the Sprite when using c?? as the color. However, you're checking absolute coordinates in your code.

So Rel Counters doesn't work here?

[Terryn]

hseiken, on 28 November 2024 - 11:57 AM, said:

So Rel Counters doesn't work here?

That's not the issue here. To restate, when IF Sprite_Colliding uses c?? as its color parameter, it acts kind of like a rel self is applied for the entire Sprite. To make your code work, instead of using the counters you're using in it now, you would use the numbers 0 -1 for the (x,y) coordinates to check for an obstruction one tile north of the Sprite. (Or you could simply change c?? to c00 or something to make If Sprite_Colliding check absolute coordinates to fit your current code, but that's much less clean codewise than just using relative distance.)

[hseiken]

Terryn, on 28 November 2024 - 07:12 PM, said:

That's not the issue here. To restate, when IF Sprite_Colliding uses c?? as its color parameter, it acts kind of like a rel self is applied for the entire Sprite. To make your code work, instead of using the counters you're using in it now, you would use the numbers 0 -1 for the (x,y) coordinates to check for an obstruction one tile north of the Sprite. (Or you could simply change c?? to c00 or something to make If Sprite_Colliding check absolute coordinates to fit your current code, but that's much less clean codewise than just using relative distance.)

Thanks for the help, I 'get' how it works now. It's confusing, but once the snake is unknotted, it's not so hard to grasp. I've been bringing to life a lot of old graphics/animations I've had laying around begging for controls/sprites to be made out of them...now I get to see em! Much appreciated to everyone that's been putting up with my forum pollution of my noob questions.