Jump to content


Photo

collision_line detecting more than one object.


  • Please log in to reply
4 replies to this topic

#1 GRS9790

GRS9790

    GMC Member

  • GMC Member
  • 46 posts
  • Version:GM8.1

Posted 12 June 2012 - 03:35 PM

Ok guys, after gaining a lot of momentum in my current project, I'm at a loss. I'm currently working on a sprite based FPS and most things have been going quite smoothly. In order to eliminate "bullet skipping" I decided to go with instant bit detection using our good friend "collision_line_first" which works great at what it is meant to do. The problem is that I don't want to use solid objects, and I don't want it to check for all objects. Long story short, I need it to check for multiple objects. I cannot just check for a parent object because of the way I have parent objects set up already for various objects (half walls, full walls, etc). I've been searching around for a way to do this but I haven't been having any luck. Hell, I don't even know what to search for.

I've done this by checking the collision_line_first of each object that should interact with bullets and then checking which is closest to the player object, but that seems a bit clumsy and I'd like to avoid it if there is a simpler way that I seem to be clueless to. If not then I'll do what I have to.

Basically I want something like:

collision_line_first(obj_player.x+lengthdir_x(32,obj_player.direction),obj_player.y+lengthdir_y(32,obj_player.direction),
obj_player.x+lengthdir_x(50000,obj_player.direction),obj_player.y+lengthdir_y(50000,obj_player.direction),(obj_wall_parent OR obj_barrel1 OR ETC),true,true)


...which obviously does not work, I'd just like something that would work like that concept to simplify things.

Thanks everybody!

Edit: On second thought, this might belong in another section, sorry! :confused:

Edited by GRS9790, 12 June 2012 - 04:50 PM.

  • 0

#2 Gamer3D

Gamer3D

    Human* me = this;

  • GMC Member
  • 1589 posts
  • Version:GM8.1

Posted 12 June 2012 - 09:03 PM

I've done this by checking the collision_line_first of each object that should interact with bullets and then checking which is closest to the player object, but that seems a bit clumsy and I'd like to avoid it if there is a simpler way that I seem to be clueless to. If not then I'll do what I have to.

Consider using the keyword "all" for objects or modifying the collision_line_first code to check each type of object internally.

Edit: On second thought, this might belong in another section, sorry! :confused:

I think this was the right section. You asked a GML question that wasn't "please write my code for me" or "I don't know what point_direction does and I refuse to read the manual."
  • 0

#3 GRS9790

GRS9790

    GMC Member

  • GMC Member
  • 46 posts
  • Version:GM8.1

Posted 12 June 2012 - 10:30 PM

Thanks for the reply! I did use "all" to test if the function works but the problem then is objects like half-walls or solid bushes that cannot be moved through but can be shot over stop the "bullet".

Currently I'm using:
with obj_player
    {
aa=collision_line_first(obj_player.x+lengthdir_x(32,obj_player.direction),obj_player.y+lengthdir_y(32,obj_player.direction), obj_player.x+lengthdir_x(50000,obj_player.direction),obj_player.y+lengthdir_y(50000,obj_player.direction),parent_wall,true,true)

bb=collision_line_first(obj_player.x+lengthdir_x(32,obj_player.direction),obj_player.y+lengthdir_y(32,obj_player.direction), obj_player.x+lengthdir_x(50000,obj_player.direction),obj_player.y+lengthdir_y(50000,obj_player.direction),obj_barrel1,true,true)

cc=collision_line_first(obj_player.x+lengthdir_x(32,obj_player.direction),obj_player.y+lengthdir_y(32,obj_player.direction), obj_player.x+lengthdir_x(50000,obj_player.direction),obj_player.y+lengthdir_y(50000,obj_player.direction),parent_enemy,true,true)

if distance_to_object(aa) < distance_to_object(bb) and distance_to_object(aa) <  distance_to_object(cc)
    then {with (aa) {sound_play(snd_bullet_hit)}}
if distance_to_object(bb) < distance_to_object(aa) and distance_to_object(bb) < distance_to_object(cc)
    then {with (bb) {instance_destroy()}}
if distance_to_object(cc) < distance_to_object(aa) and distance_to_object(cc) < distance_to_object(bb)
    then {with (cc) {instance_destroy()}}
    }
}
It works very well but there has to be an easier way. Every time I add a new type of bullet "hittable" object (like the windows I'm doing now) the code length will multiply.

Edited by GRS9790, 12 June 2012 - 11:38 PM.

  • 0

#4 Desert Dog

Desert Dog

    GMC Member

  • Global Moderators
  • 6409 posts
  • Version:Unknown

Posted 12 June 2012 - 11:45 PM



Edit: On second thought, this might belong in another section, sorry! :confused:

I think this was the right section. You asked a GML question that wasn't "please write my code for me" or "I don't know what point_direction does and I refuse to read the manual."


It is a good topic, but I think it belongs more in Q&A. It's still a how-to topic, with regards to using GM functions, rather than an advanced discussion. It should get answered quickly enough in the Q&A without being dropped off the first page.

You won't want to use multiple collision_line_firsts, if you can help it! :P

Do you know that parents can have parents?

Think of a obj_everyone_parent

That is the parent to obj_half_wall_parent and obj_solid_wall_parent and obj_enemy_parent, etc
which are in turn, parents of other parent objects, or game objects.

It'd probably help to write it out in a flow-chart on paper, how to best work the hierarchy. (also, pick better names than I just did!)
  • 0

#5 GRS9790

GRS9790

    GMC Member

  • GMC Member
  • 46 posts
  • Version:GM8.1

Posted 13 June 2012 - 02:52 AM

I have something like that. I have parent_wall and parent_wall2 being full walls and half walls, respectively. Then they both have a parent "obstacle" which is what is used to determine where characters can and cannot go.

New problem is determining if the bullet travels over or stops at half walls depending on if the player is crouched or not. If it travels over, than with my current code nothing would happen to anything behind the wall because the script would have already run and returned that wall as the place of "impact". This game is turning into a real headache :wacko: but it feels good to have a project worth working on.

I'm an idiot. :laugh:

Edited by GRS9790, 13 June 2012 - 02:58 AM.

  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users