Entitytype 3 NOT colliding? oO
Blitz3D Forums/Blitz3D Beginners Area/Entitytype 3 NOT colliding? oO
| ||
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: |
| ||
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. |
| ||
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? |
| ||
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. |
| ||
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? |
| ||
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). |
| ||
um.... ok? how? wouldnt i be able to use linepick for this? if so, how? |
| ||
I've never used linepicks before, so I can't give an immediate answer. |
| ||
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. |
| ||
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. |
| ||
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. |
| ||
http://www.blitzbasic.com/codearcs/codearcs.php?code=540 |
| ||
thanks ja2 |
| ||
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. |
| ||
i thought about that. but im actually going to go w/ the link ja2 showed. i need it to respond to animated meshes |
| ||
You won't get anything other than the default pose, for boned animations, for use with collisions, you should note. |
| ||
so how CAN i get something other than the default pose for boned animations? also, can coldet do this? |
| ||
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). |
| ||
Indeed, you could use that invisible segmented mesh for fighting games, for example. |
| ||
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) ? |
| ||
you could also parent a pivot to the relevant bones, and check for collisions with them |
| ||
good idea. I'll keep that in mind |