Entitytype 3 NOT colliding? oO

Blitz3D Forums/Blitz3D Beginners Area/Entitytype 3 NOT colliding? oO

Guy Fawkes(Posted 2010) [#1]
Why won't entitytype item, 3 work? I did a entitycollided(player, 3) to check if the player collided w/ the item, but it didnt work.

code:




PowerPC603(Posted 2010) [#2]
You have enabled collisions between player and world, but you forgot to enable collisions between the player and items:
Collisions 1, 3, 2, 2


The player could move through the yellow cilinder.


Guy Fawkes(Posted 2010) [#3]
ok, now how can i make it so if the player goes through the item, it detects that and deletes the item thats picked up?


PowerPC603(Posted 2010) [#4]
When colliding with the entity, free it.

	; Get the handle of the type-3 entity which the player has hit
	itemtofree = EntityCollided(player, 3)
	; Check if there was an entity-handle returned (will be something else than 0)
	If itemtofree Then
		; Free the entity
		FreeEntity itemtofree
		; Clear the variable
		itemtofree = 0
	EndIf


NOTE:
As you're bumping into the item, the player momentarily stops (for one frame), as the collision occurs.
When moving forward 1 unit, and the item you're bumping into is only half a unit away, the player only moves half a unit.
Then the item is freed and you can go 1 unit forward again every frame.
This bumping can be seen by the player (try it).

To prevent this, you can also use EntityDistance to detect if you're going to bump into an item, before you actually collide with it.

But then you'll need to check the distance to every single unit in your world.
When you have alot of units (such as the yellow cilinder), that will take alot of distance checks to process every frame.


Guy Fawkes(Posted 2010) [#5]
How can I make it so that instead of a stopping collision, it allows my player to go 'through' the item, but STILL has collision on it?


PowerPC603(Posted 2010) [#6]
If you want to actually collide with it, I don't know any way around this.
You could of course:
- temporary store the current player position
- move the player
- check if he has collided with an item
- if collision occured, free the item
- check if the player has moved the distance he should be moving
- if not, move the player forward the remaining distance

So, if your player should be moving 1 unit forward, but collided with an object which was only half a unit away, then the player should move another half a unit after the item has been freed (the remaining distance).

It's best to reset the player to the previous position when a collision occured and move him 1 unit forward.
As the player could collide with a round item (like a cilinder or sphere) and could move left/right because of the collision (sliding against the side of the item).


Guy Fawkes(Posted 2010) [#7]
um.... ok? how?

wouldnt i be able to use linepick for this?

if so, how?


PowerPC603(Posted 2010) [#8]
I've never used linepicks before, so I can't give an immediate answer.


Oiduts Studios(Posted 2010) [#9]
You could copy the player and update it just like the real player and hide it. Then set only the collisions with the pickups to the copy. So when you hit the pickups, only the copy of the player moves and the collisions are detected.


Drak(Posted 2010) [#10]
Sometimes it's easier just to use Entitydistance() for certain situations. It's a retardedly fast function so have no fear of it. I use it quite liberally (hundreds of times some frames) in some of my games/simulations with no noticeable ill effects.

I'm not saying thats the absolute best way to do your collision with the yellow cylinders, but it is a viable option, and it's a lot simpler as well.


Ross C(Posted 2010) [#11]
Yep, I'd use entitydistance, for objects which only require a rounded collison, like coins. When your within a certain distance then simple delete the object your collection and your collision is complete. The only problem with entity distance, is you may be moving too fast between frames, to be within distance of the entity. I mean, you might be within 10 units of the entity, then next frame you move right through it and end up 15 units from it, as you've moved 25 units.


JA2(Posted 2010) [#12]
http://www.blitzbasic.com/codearcs/codearcs.php?code=540


Guy Fawkes(Posted 2010) [#13]
thanks ja2


Yasha(Posted 2010) [#14]
This is going in a slightly different direction, but have you considered ColDet for your collision needs?

http://www.blitzbasic.com/Community/posts.php?topic=30735#327689
http://www.freewebs.com/elias_t/coldetwrapper.htm

Pros: much, much faster than builtin Blitz3D collisions. Allows poly-poly collision checking and ray/line picks as well. No-response collision checking.

Cons: There is in fact no option to have a collision response, so you need to code that part yourself (easy enough for stop-collisions... not so much for sliding downhill), or use it alongside builtin collisions. Also has no support for animated meshes.


Guy Fawkes(Posted 2010) [#15]
i thought about that. but im actually going to go w/ the link ja2 showed.

i need it to respond to animated meshes


Ross C(Posted 2010) [#16]
You won't get anything other than the default pose, for boned animations, for use with collisions, you should note.


Guy Fawkes(Posted 2010) [#17]
so how CAN i get something other than the default pose for boned animations?

also, can coldet do this?


Yasha(Posted 2010) [#18]
ColDet can't - that's what I meant by no animation support. Unfortunately there is no way to get anything out of boned animations (the vertex positions are dynamically recalculated every frame for rendering and aren't stored). There are two options that I can think of (neither is perfect):

1) Use a vertex-based animation system, like (but not) MD2. MD2 itself is again handled differently by Blitz3D, but there are "fake MD2" and MD3 systems floating about that use the Blitz3D vertex control commands, which means real mesh data will be available. The big downside of this though is that you'll still need to re-upload the new mesh data to the collision system every frame, and this is dog-slow for either Blitz or ColDet.

2) Use boned meshes for your visuals, but run them alongside a 3DS-style segmented mesh with EntityAlpha 0. Segmented meshes don't involve any mesh deformation and will work quickly and correctly with either collision system, but for obvious reasons there might be a few points of inaccuracy at the knees and elbows (I guess this depends on how accurate you need it to be - I'd be happy with this).


Kryzon(Posted 2010) [#19]
Indeed, you could use that invisible segmented mesh for fighting games, for example.


Guy Fawkes(Posted 2010) [#20]
how would i go about doing this? could someone show me a short example of this collision being used on perhaps a cube or a blitz-generated, animated mesh (if possible) ?


Ross C(Posted 2010) [#21]
you could also parent a pivot to the relevant bones, and check for collisions with them


Guy Fawkes(Posted 2010) [#22]
good idea. I'll keep that in mind