Legacy GM [SOLVED] Particles spawning in the wrong location from projectiles hitting walls

S

Shawn

Guest
Why are you so desperate to make a thing like particles work if you don't understand actual mechanical code? I advise you to continue on working on more important parts of the game than particles. This is going in circles, I don't know how to help you.
Particles are essential to making the game have the feel I'm trying to give it. I want chaos and fast-paced gameplay, and there's a huge difference in feel when using particles vs not using particles. You can't have a lot of chaos if there's no impact.

I've tried using the scripts I've been told, only NOTHING has worked. People are looking at this thread, but no one is really attempting to help. What help I do get also doesn't explain what's going on, and variables tend to be vague or easily confused with built-in variables/functions. I'm not going to just stop trying to get the particles to work. If someone understands HOW to make particles spawn in the proper location, and they refuse to explain how to do it, then the fault of this issue NOT being solved is on them not helping. I can't just know something I don't know, I need to learn it, and the best way for that to be done is through experience and proper explanation, and the explanation is lacking.
 

Simon Gust

Member
Particles are essential to making the game have the feel I'm trying to give it. I want chaos and fast-paced gameplay, and there's a huge difference in feel when using particles vs not using particles. You can't have a lot of chaos if there's no impact.

I've tried using the scripts I've been told, only NOTHING has worked. People are looking at this thread, but no one is really attempting to help. What help I do get also doesn't explain what's going on, and variables tend to be vague or easily confused with built-in variables/functions. I'm not going to just stop trying to get the particles to work. If someone understands HOW to make particles spawn in the proper location, and they refuse to explain how to do it, then the fault of this issue NOT being solved is on them not helping. I can't just know something I don't know, I need to learn it, and the best way for that to be done is through experience and proper explanation, and the explanation is lacking.
Well I tried warning you of bad coding habits but with the current system it doesn't work. I just set up a system myself that is simple.
The speed and direction variables to move instances has the one drawback that you will never be able to check the first frame of a collision check. using horizontal and vertical speeds solved this.
I made a single particle sprite with animation spawn on contact with the wall that plays beyong the bullet's death.
 
S

Shawn

Guest
Well I tried warning you of bad coding habits but with the current system it doesn't work. I just set up a system myself that is simple.
The speed and direction variables to move instances has the one drawback that you will never be able to check the first frame of a collision check. using horizontal and vertical speeds solved this.
I made a single particle sprite with animation spawn on contact with the wall that plays beyong the bullet's death.
Saying that I'm breaking coding rules or that there's a specific habit that's bad, WITHOUT saying what you're referring to, resolves nothing and keeps what you're saying as vague information. To even expand on this, one could argue that your coding habits are bad, since using variables with names similar to built-in variables/functions or 1-to-3 letter "words" keep things so vague that a return to said location easily invites confusion and forgetfulness. You want to claim that I'm doing something wrong, then point out what I'm doing wrong, instead of lording over me with "I KNOW MORE THAN YOU!"

The code I've been given that uses the program's base functions didn't work.

The script I was given to set the room to a grid wasn't explained, and the one time I managed to get it at least somewhat working, it was broken; the game would crash when a bullet was shot in a direction where there were no objects and the particles STILL didn't spawn in the proper location.

Using objects as particles is not something I'm going to do. A particle system exists for a reason, so that particle system should be used.

If you don't know how to fix the particle spawn location, just say so and stop commenting. If you do know how to fix it, THEN EXPLAIN HOW TO FIX IT AND STOP BEING VAGUE.

Everywhere I look, people keep taking the easy route by using objects in place of particles, and that's NOT acceptable. If I could find the information I need for this, I wouldn't be asking for help, but with all those people taking the easy route, the information I'm trying to find is nowhere to be found. The easy way isn't necessarily the right way, and seeing as I already found a way to fix half of the particle spawn issue, the other half should also be fixable.
 
Last edited by a moderator:

Simon Gust

Member
Saying that I'm breaking coding rules or that there's a specific habit that's bad, WITHOUT saying what you're referring to, resolves nothing and keeps what you're saying as vague information. To even expand on this, one could argue that your coding habits are bad, since using variables with names similar to built-in variables/functions or 1-to-3 letter "words" keep things so vague that a return to said location easily invites confusion and forgetfulness. You want to claim that I'm doing something wrong, then point out what I'm doing wrong, instead of lording over me with "I KNOW MORE THAN YOU!"
I didn't think I needed to explain easy mechanics because on your first attempt you went full "I want to make proffesional systems". Using delta timing, already using particles, you sounded like you knew what you were talking about.
You do not understand how instances work. You do not seem to understand what functions return. Everything I throw at you gives me a "this doesn't work". I'm trying different methods and taking my time off my projects to help you.
I did not advise you to use objects as particles at any point.

The code I've been given that uses the program's base functions didn't work.
I've never used the built in functions because I never trusted them. Make your own system, it's good practice.

If you don't know how to fix the particle spawn location, just say so and stop commenting. If you do know how to fix it, THEN EXPLAIN HOW TO FIX IT AND STOP BEING VAGUE.
Ok, I will show you how I do it. If you don't want it, your problem.

I have made 3 objects; obj_wall, obj_player and obj_bullet. obj_player shoots an instance of obj_bullet that is destroyed on contact with obj_wall.
obj_player:
Code:
/// create
global.partSystem = part_system_create(); // create particle system

// step
if (keyboard_check_pressed(vk_space))
{
    var this = instance_create(x, y, obj_bullet);
    with (this)
    {
        hspd = 400;
        vspd = 0;
    }
}
If you press space, an instance of obj_bullet is created and saved inside "this". The bullets hspd is set to 400.

obj_bullet:
Code:
/// create
part = part_type_create(); // create new particle type for that bullet (you may move this somewhere else)
part_type_sprite(part, spr_part1, true, true, false); // spr_part1 is a sprite with a small animation in the resource tree.
part_type_life(part, 32, 32); // the particle lasts 32 frames exactly, the animation is stretched over that lifetime

hspd = 0; // horizontal speed
vspd = 0; // vertical speed

/// step
var collision_obj_wall = collision_line(x, y, x+hspd, y+vspd, obj_wall, false, false); // returns -4 or the instance id if obj_wall is found
if (collision_obj_wall != noone) // check for actual confirmation of collision
{
    if (hspd > 0) x = collision_obj_wall.bbox_left; // if the bullet is heading right. set it to the left side of the collided instance
    else x = collision_obj_wall.bbox_right; // else set it to the right side.
   
    // particles
    part_particles_create(global.partSystem, x, y, part, 1); // spawn 1 particle at the exact location (can be scattered on the y axis)
   
    // death
    instance_destroy(); // destroy the instance
}
else
{
    x += hspd; // increase x by hspd
    y += vspd; // increase y by vspd
}
Every other object has a sprite of 32x32 pixels.
 
S

Shawn

Guest
I didn't think I needed to explain easy mechanics because on your first attempt you went full "I want to make proffesional systems". Using delta timing, already using particles, you sounded like you knew what you were talking about.
You do not understand how instances work. You do not seem to understand what functions return. Everything I throw at you gives me a "this doesn't work". I'm trying different methods and taking my time off my projects to help you.
I did not advise you to use objects as particles at any point.


I've never used the built in functions because I never trusted them. Make your own system, it's good practice.


Ok, I will show you how I do it. If you don't want it, your problem.

I have made 3 objects; obj_wall, obj_player and obj_bullet. obj_player shoots an instance of obj_bullet that is destroyed on contact with obj_wall.
obj_player:
Code:
/// create
global.partSystem = part_system_create(); // create particle system

// step
if (keyboard_check_pressed(vk_space))
{
    var this = instance_create(x, y, obj_bullet);
    with (this)
    {
        hspd = 400;
        vspd = 0;
    }
}
If you press space, an instance of obj_bullet is created and saved inside "this". The bullets hspd is set to 400.

obj_bullet:
Code:
/// create
part = part_type_create(); // create new particle type for that bullet (you may move this somewhere else)
part_type_sprite(part, spr_part1, true, true, false); // spr_part1 is a sprite with a small animation in the resource tree.
part_type_life(part, 32, 32); // the particle lasts 32 frames exactly, the animation is stretched over that lifetime

hspd = 0; // horizontal speed
vspd = 0; // vertical speed

/// step
var collision_obj_wall = collision_line(x, y, x+hspd, y+vspd, obj_wall, false, false); // returns -4 or the instance id if obj_wall is found
if (collision_obj_wall != noone) // check for actual confirmation of collision
{
    if (hspd > 0) x = collision_obj_wall.bbox_left; // if the bullet is heading right. set it to the left side of the collided instance
    else x = collision_obj_wall.bbox_right; // else set it to the right side.
 
    // particles
    part_particles_create(global.partSystem, x, y, part, 1); // spawn 1 particle at the exact location (can be scattered on the y axis)
 
    // death
    instance_destroy(); // destroy the instance
}
else
{
    x += hspd; // increase x by hspd
    y += vspd; // increase y by vspd
}
Every other object has a sprite of 32x32 pixels.
Firstly, the order in which a project is created and completed doesn't necessarily comply with the order of level of difficulty per step to completion of said project. Delta timing was one of the first things I looked at because I noticed the game was limited to 30fps, at default, and adjusting that framerate was messing with everything.

Next,
Every other object has a sprite of 32x32 pixels.
suggests that I'd be limited to using only 32x32 sprites, or objects of relative size, which I'm not restricting myself to, and I refuse to limit the size of the sprites I use. We aren't in the mid-to-late '90s, anymore, and using such small sprites isn't acceptable, unless you're specifically doing so for an artistic graphical style that's reminiscent of the NES, SNES, etc. eras.

I'm not sure why you're setting the hspeed of the bullet to 400, then reducing it to 0 upon its creation when doing so nullifies the speed it's given in the key_press.

Only parts of the given code could be salvaged:
Code:
Collision_Location_Tmp_Wall_Left = collision_line(
    xprevious, yprevious, x, y, Tmp_Wall_Left, false, false);
if Collision_Location_Tmp_Wall_Left != noone
    {
    if (hspeed > 0)
        {
        x = Collision_Location_Tmp_Wall_Left.bbox_left;
        part_particles_create(global.Tmp_Bullet_Shrapnel_Left_Particle_System,
            x, y, global.Tmp_Bullet_Shrapnel_Left_Particle, 3)
        instance_destroy()
        }
    else
        {
        x = Collision_Location_Tmp_Wall_Left.bbox_right;
        part_particles_create(global.Tmp_Bullet_Shrapnel_Left_Particle_System,
            x, y, global.Tmp_Bullet_Shrapnel_Left_Particle, 3)
        instance_destroy()
        }
    }
else
    {
    x = x + hspeed;
    y = y + vspeed;
    }
The rest of the code doesn't fit with the system I have in place for shooting. Using the salvaged code also doesn't work any better than a step before what I currently have, which only has the issue of spawning particles in the bullet's last-known position before impact with the wall when that bullet actually makes contact with the wall. When the bullets miss the wall, with my current code, the particles are spawned in the proper location. Since there's a lot of stuff going on, I'll throw the entire system I have in place to make this work, starting with delta timing and one of the two guns the player has following them.

Code:
//Create a variable for slowing down time
globalvar Time_Control;
    Time_Control = 240

//Create a variable for delta time
global.Delta_Timing = Time_Control / 1000000 * delta_time;

Code:
//Create a variable for delta timing
global.Delta_Timing = Time_Control / 1000000 * delta_time;

Code:
//Create binding variables for weapon swapping
globalvar Tmp_Gun_XY;
    Tmp_Gun_XY = false

globalvar Class_1_RPG_XY;
    Class_1_RPG_XY = false

//Gives a target for the cursor
cursor_sprite = Circle_With_X
window_set_cursor(cr_none)


/*
Creates variables for weapon storage,
so multiple guns can be kept and swapped
between without dropping and picking up
new guns
*/
globalvar Selected_Weapon;
    Selected_Weapon = 0
  
globalvar Class_1_RPG_Storage;
    Class_1_RPG_Storage = 1.0
  
globalvar Class_2_Gun_Name_Here;
    Class_2_Gun_Name_Here = 2.0

globalvar Class_3_Gun_Name_Here;
    Class_3_Gun_Name_Here = 3.0

globalvar Class_4_Gun_Name_Here;
    Class_4_Gun_Name_Here = 4.0

globalvar Class_5_Gun_Name_Here;
    Class_5_Gun_Name_Here = 5.0

globalvar Class_6_Gun_Name_Here;
    Class_6_Gun_Name_Here = 6.0

globalvar Class_7_Gun_Name_Here;
    Class_7_Gun_Name_Here = 7.0

globalvar Class_8_Gun_Name_Here;
    Class_8_Gun_Name_Here = 8.0

globalvar Class_9_Gun_Name_Here;
    Class_9_Gun_Name_Here = 9.0

globalvar Class_10_Gun_Name_Here;
    Class_10_Gun_Name_Here = 10.0


//New code that works with delta timing - create shoot delay alarms
globalvar Class_1_Alarm;
    Class_1_Alarm = 0 //Class 1 speeds = 480 frames

globalvar Class_2_Alarm;
    Class_2_Alarm = 0 //Class 2 speeds = 300 frames

globalvar Class_3_Alarm;
    Class_3_Alarm = 0 //Class 3 speeds = 240 frames

globalvar Class_4_Alarm;
    Class_4_Alarm = 0 //Class 4 speeds = 120 frames

globalvar Class_5_Alarm;
    Class_5_Alarm = 0 //Class 5 speeds = 80 frames

globalvar Class_6_Alarm;
    Class_6_Alarm = 0 //Class 6 speeds = 60 frames

globalvar Class_7_Alarm;
    Class_7_Alarm = 0 //Class 7 speeds = 48 frames

globalvar Class_8_Alarm;
    Class_8_Alarm = 0 //Class 8 speeds = 40 frames

globalvar Class_9_Alarm;
    Class_9_Alarm = 0 //Class 9 speeds = 34 frames

globalvar Class_10_Alarm;
    Class_10_Alarm = 0 //Class 10 speeds = 24 frames


globalvar Class_1_Can_Shoot_R;
    Class_1_Can_Shoot_R = true
  
globalvar Class_2_Can_Shoot_R;
    Class_2_Can_Shoot_R = true

globalvar Class_3_Can_Shoot_R;
    Class_3_Can_Shoot_R = true
  
globalvar Class_4_Can_Shoot_R;
    Class_4_Can_Shoot_R = true
  
globalvar Class_5_Can_Shoot_R;
    Class_5_Can_Shoot_R = true
  
globalvar Class_6_Can_Shoot_R;
    Class_6_Can_Shoot_R = true
  
globalvar Class_6_Can_Shoot_R;
    Class_6_Can_Shoot_R = true
  
globalvar Class_7_Can_Shoot_R;
    Class_7_Can_Shoot_R = true
  
globalvar Class_8_Can_Shoot_R;
    Class_8_Can_Shoot_R = true
  
globalvar Class_9_Can_Shoot_R;
    Class_9_Can_Shoot_R = true

globalvar Class_10_Can_Shoot_R;
    Class_10_Can_Shoot_R = true

Code:
//Point towards the cursor
image_angle =
    point_direction(x,y,mouse_x,mouse_y)

//Tick the alarms
//For Class 1
if Class_1_Alarm > 0
    {
    Class_1_Alarm = Class_1_Alarm - global.Delta_Timing
    }
else if Class_1_Alarm <= 0
    {
    Class_1_Can_Shoot = true
    }

//For Class 2
if Class_2_Alarm > 0
    {
    Class_2_Alarm = Class_2_Alarm - global.Delta_Timing
    }
else if Class_2_Alarm <= 0
    {
    Class_2_Can_Shoot = true
    }

//For Class 3
if Class_3_Alarm > 0
    {
    Class_3_Alarm = Class_3_Alarm - global.Delta_Timing
    }
else if Class_3_Alarm <= 0
    {
    Class_3_Can_Shoot = true
    }

//For Class 4
if Class_4_Alarm > 0
    {
    Class_4_Alarm = Class_4_Alarm - global.Delta_Timing
    }
else if Class_4_Alarm <= 0
    {
    Class_4_Can_Shoot = true
    }

//For Class 5
if Class_5_Alarm > 0
    {
    Class_5_Alarm = Class_5_Alarm - global.Delta_Timing
    }
else if Class_5_Alarm <= 0
    {
    Class_5_Can_Shoot = true
    }

//For Class 6
if Class_6_Alarm > 0
    {
    Class_6_Alarm = Class_6_Alarm - global.Delta_Timing
    }
else if Class_6_Alarm <= 0
    {
    Class_6_Can_Shoot = true
    }

//For Class 7
if Class_7_Alarm > 0
    {
    Class_7_Alarm = Class_7_Alarm - global.Delta_Timing
    }
else if Class_7_Alarm <= 0
    {
    Class_7_Can_Shoot = true
    }

//For Class 8
if Class_8_Alarm > 0
    {
    Class_8_Alarm = Class_8_Alarm - global.Delta_Timing
    }
else if Class_8_Alarm <= 0
    {
    Class_8_Can_Shoot = true
    }

//For Class 9
if Class_9_Alarm > 0
    {
    Class_9_Alarm = Class_9_Alarm - global.Delta_Timing
    }
else if Class_9_Alarm <= 0
    {
    Class_9_Can_Shoot = true
    }

//For Class 10
if Class_10_Alarm > 0
    {
    Class_10_Alarm = Class_10_Alarm - global.Delta_Timing
    }
else if Class_10_Alarm <= 0
    {
    Class_10_Can_Shoot = true
    }

Code:
//For Class 1 weapons
//Check if it's the right gun's turn to shoot
if Class_1_Can_Shoot_R = true
    {

//Check if the shoot delay alarm is reset
    if Class_1_Alarm <= 0
        {

//Check for the proper weapon
        if Selected_Weapon = 1.0
            {

//Double check that the player has the gun class
            if Has_Class_1_Gun = true
                {

//The following will define a bullet
                Tmp_Bullet_Class_1_Shoot = instance_create(Displayed_Weapon_R.x, Displayed_Weapon_R.y, Tmp_Bullet_Class_1)

//The following will set the bullet's speed   
                Tmp_Bullet_Class_1_Shoot.speed = 5 * global.Delta_Timing

//The following will set the bullet's direction
//so that it shoots towards the cursor
                Tmp_Bullet_Class_1_Shoot.direction = point_direction(x, y, mouse_x, mouse_y)
  
//The following will rotate the bullet so that
//it's aimed at the cursor
                Tmp_Bullet_Class_1_Shoot.image_angle = Tmp_Bullet_Class_1_Shoot.direction
      
//Reset the timer to create a shooting delay
                Class_1_Can_Shoot = false
                Class_1_Alarm = 480
                Class_1_Can_Shoot_R = false
                Class_1_Can_Shoot_L = true
                }
            }
        }
    }




//For Class 10 weapons
//Check if it's the right gun's turn to shoot
if Class_10_Can_Shoot_R = true
    {

//Check if the shoot delay alarm is reset
    if Class_10_Alarm <= 0
        {

//Check if the gun can shoot
        if Class_10_Can_Shoot = true
            {

//Check for the proper weapon
            if Selected_Weapon = 10.0
                {

//Double check that the player has the gun class
                if Has_Class_10_Gun = true
                    {

//The following will define a bullet
                    Tmp_Bullet_Class_10_Shoot = instance_create(Displayed_Weapon_R.x, Displayed_Weapon_R.y, Tmp_Bullet_Class_10)
                    Tmp_Bullet_Class_10_Shoot2 = instance_create(Displayed_Weapon_R.x, Displayed_Weapon_R.y, Tmp_Bullet_Class_10)
                    Tmp_Bullet_Class_10_Shoot3 = instance_create(Displayed_Weapon_R.x, Displayed_Weapon_R.y, Tmp_Bullet_Class_10)
                    Tmp_Bullet_Class_10_Shoot4 = instance_create(Displayed_Weapon_R.x, Displayed_Weapon_R.y, Tmp_Bullet_Class_10)
                    Tmp_Bullet_Class_10_Shoot5 = instance_create(Displayed_Weapon_R.x, Displayed_Weapon_R.y, Tmp_Bullet_Class_10)

//The following will set the bullet's speed   
                    Tmp_Bullet_Class_10_Shoot.speed = 10 * global.Delta_Timing
                    Tmp_Bullet_Class_10_Shoot2.speed = 10 * global.Delta_Timing
                    Tmp_Bullet_Class_10_Shoot3.speed = 10 * global.Delta_Timing
                    Tmp_Bullet_Class_10_Shoot4.speed = 10 * global.Delta_Timing
                    Tmp_Bullet_Class_10_Shoot5.speed = 10 * global.Delta_Timing

//The following will set the bullet's direction
//so that it shoots towards the cursor
                    Tmp_Bullet_Class_10_Shoot.direction = point_direction(x, y, mouse_x, mouse_y) - 4
                    Tmp_Bullet_Class_10_Shoot2.direction = point_direction(x, y, mouse_x, mouse_y) - 2
                    Tmp_Bullet_Class_10_Shoot3.direction = point_direction(x, y, mouse_x, mouse_y)
                    Tmp_Bullet_Class_10_Shoot4.direction = point_direction(x, y, mouse_x, mouse_y) + 2
                    Tmp_Bullet_Class_10_Shoot5.direction = point_direction(x, y, mouse_x, mouse_y) + 4

//The following will rotate the bullet so that
//it's aimed at the cursor
                    Tmp_Bullet_Class_10_Shoot.image_angle = Tmp_Bullet_Class_10_Shoot.direction
                    Tmp_Bullet_Class_10_Shoot2.image_angle = Tmp_Bullet_Class_10_Shoot2.direction
                    Tmp_Bullet_Class_10_Shoot3.image_angle = Tmp_Bullet_Class_10_Shoot3.direction
                    Tmp_Bullet_Class_10_Shoot4.image_angle = Tmp_Bullet_Class_10_Shoot4.direction
                    Tmp_Bullet_Class_10_Shoot5.image_angle = Tmp_Bullet_Class_10_Shoot5.direction

//Reset the timer to create a shooting delay
                    Class_10_Alarm = 24
                    Class_10_Can_Shoot_R = false
                    Class_10_Can_Shoot_L = true
                    }
                }
            }
        }
    }

Code:
//WILL BE GETTING EXPANDING WHEN MORE WEAPONS ARE CREATED
if Selected_Weapon >= 1.0
        {
        if Has_Class_10_Gun_Name_Here = true
            {
            Selected_Weapon = 10.0
            Tmp_Gun_XY = true
            Class_1_RPG_XY = false
            Displayed_Weapon_R.sprite_index = Tmp_Gun_Sprite
            Displayed_Weapon_L.sprite_index = Tmp_Gun_Sprite
            }
        }

Code:
if Selected_Weapon >= 10.0
        {
        if Has_Class_1_RPG = true
            {
            Selected_Weapon = 1.0
            Tmp_Gun_XY = false
            Class_1_RPG_XY = true
            Displayed_Weapon_R.sprite_index = Tmp_Gun_Sprite_2
            Displayed_Weapon_L.sprite_index = Tmp_Gun_Sprite_2
            }
        }

Code:
//Creates a variable for the lifespan of the bullet
Bullet_Life = 480;

//Create variables for bullet collision
Former_X = 0;
Former_Y = 0;
Collision_Location_Tmp_Wall_Left = 0;

Code:
/*
Retain the proper bullet speed with delta timing,
so it doesn't appear to speed up or slow down
when the framerate changes
*/
//CURRENT SPEED IS TEMPORARY WHILE ENSURING PROPER COLLISION AND PARTICLE SPAWN LOCATION
Tmp_Bullet_Class_10.speed = 30 * global.Delta_Timing

//Updates the lifespan of the bullet, then destroys it
if Bullet_Life > 0
    {
    Bullet_Life = Bullet_Life - 1 * global.Delta_Timing
    }
else if Bullet_Life <= 0
    {
    instance_destroy()
    }

Code:
//THIS IS ONLY THE PART FOR THE LEFT WALL, SINCE THAT'S WHAT'S BEING WORKED ON AND TESTED BEFORE FIXING OTHER WALLS
//For Tmp_Wall_Left
Collision_Location_Tmp_Wall_Left = collision_line(
    xprevious, yprevious, x, y, Tmp_Wall_Left, false, false);
if Collision_Location_Tmp_Wall_Left != noone
    {
    Former_X = xprevious;
    if Former_X < Collision_Location_Tmp_Wall_Left.x
        {
        while Former_X < Collision_Location_Tmp_Wall_Left.x
            {
            Former_X = Former_X + 1
            }
        }
    else if Former_X > Collision_Location_Tmp_Wall_Left.x
        {
        while Former_X > Collision_Location_Tmp_Wall_Left.x
            {
            Former_X = Former_X - 1
            }
        }
    event_perform(ev_collision, Tmp_Wall_Left);
    }

Code:
if Former_X != 0
    {
part_particles_create(global.Tmp_Bullet_Shrapnel_Left_Particle_System,
    Former_X, y, global.Tmp_Bullet_Shrapnel_Left_Particle, 3)
    }
else
    {
    part_particles_create(global.Tmp_Bullet_Shrapnel_Left_Particle_System,
        x, y, global.Tmp_Bullet_Shrapnel_Left_Particle, 3)
    }
There's also a drag-and-drop to destroy the bullet, set after this code is enacted.

Code:
//Create a particle system and a variable
global.Tmp_Bullet_Shrapnel_Left_Particle_System = part_system_create();

//Create a particle type and a variable
global.Tmp_Bullet_Shrapnel_Left_Particle = part_type_create();

//Create variables for updating particles to delta time
globalvar Update_Particles_Tmp_Bullet_Left;
    Update_Particles_Tmp_Bullet_Left = 1

/*
Adjust the particle's depth
part_system_depth(type variable, depth);
*/
part_system_depth(global.Tmp_Bullet_Shrapnel_Left_Particle, 3);

/*
Give particle its shape
part_type_shape(type variable, shape using pt_shape_shapehere);
Particle shapes:
    pixel, disc, square, line, star, circle, ring, sphere, flare,
    spark, explosion, cloud, smoke, snow
*/
part_type_shape(global.Tmp_Bullet_Shrapnel_Left_Particle, pt_shape_smoke);

/*
Give particle its size
part_type_size(type variable, minimum size, maximum size,
                size change per frame, random change to size per frame);
*/
part_type_size(global.Tmp_Bullet_Shrapnel_Left_Particle, 0.05, 0.25, 0, 0);

/*
Give particle its scale
part_type_scale(type variable, x axis number to be multiplied by size,
                y axis number to be multiplied by size);
*/
part_type_scale(global.Tmp_Bullet_Shrapnel_Left_Particle, 1, 1);

/*
Give particle its color
part_type_color1(type variable, color- using c_colorhere);
color2 if 2 colors, then use 2 colors
color3 if 3 colors, then use 3 colors
*/
part_type_color3(global.Tmp_Bullet_Shrapnel_Left_Particle, c_orange, c_red, c_red);

/*
Give particle its alpha
part_type_alpha1(type variable,
                0 for transparency or 1 for no transparency);
alpha2 if 2 alphas, then use 2 alphas
alpha3 if 3 alphas, then use 3 alphas
*/
part_type_alpha3(global.Tmp_Bullet_Shrapnel_Left_Particle, 1, 1, 0);

/*
Give particle its speed
part_type_speed(type variable, minimum speed, maximum speed,
                speed change per frame, speed change at random per frame);
*/
part_type_speed(global.Tmp_Bullet_Shrapnel_Left_Particle, 7, 13, -0.7, 0);

/*
Give particle its direction
part_type_direction(type variable, minimum direction the particle goes in,
                    maximum direction the particle goes in,
                    change in direction per frame,
                    change in direction at random per frame);
*/
part_type_direction(global.Tmp_Bullet_Shrapnel_Left_Particle, 340, 380, 0, 5);

/*
Give particle its orientation
part_type_orientation(type variable, minimum starting angle,
                        maximum starting angle, angle change per frame,
                        angle change at random per frame,
                        relative to direction of motion- using true or false);
*/
part_type_orientation(global.Tmp_Bullet_Shrapnel_Left_Particle, 0, 0, 0, 0, true);

/*
Give particle its blend
part_type_blend(type variable, compound colors as they overlap
                so colors are brighter as they're layered- using
                true or false);
*/
part_type_blend(global.Tmp_Bullet_Shrapnel_Left_Particle, false);

/*
Give particle its life, which determines how long it lasts
part_type_life(type variable, minimum time to last,
                maximum time to last);
Amount of time is based on number of frames, and the selected
time is actually randomized between the minimum and maximum times
*/
part_type_life(global.Tmp_Bullet_Shrapnel_Left_Particle, 2500, 10000);


//Disable automatic particle updates
part_system_automatic_update(global.Tmp_Bullet_Shrapnel_Left_Particle_System, false);

Code:
//Update the particles with delta timing
if Update_Particles_Tmp_Bullet_Left <= 0
    {
    part_system_update(global.Tmp_Bullet_Shrapnel_Left_Particle_System);
    Update_Particles_Tmp_Bullet_Left = room_speed
    }
else if Update_Particles_Tmp_Bullet_Left > 0
    {
    Update_Particles_Tmp_Bullet_Left =
        Update_Particles_Tmp_Bullet_Left -
            1 * room_speed / 10 * global.Delta_Timing
    }

Yes, this complex "mess" is necessary; the game will have 10 tiers of guns, each tier being called "Class" with a number, with the lowest class number being the strongest, but slowest, and the highest class number being the weakest, but fastest. Only one gun of a specific class of guns will be able to be used at any given time, meaning that the player won't be allowed to have 3 Class 1 guns, they'll only be allowed a single Class 1 gun. Each gun within their own class will have different abilities, appearances, animations, etc.. This is still in the testing phase, however, so the specific guns and ammo don't yet have their completed aesthetic to match how I plan on it being.

The actual gun object starts as an inactive and invisible weapon, since it has no set sprite and it's set to change its sprite based on the gun that's chosen. This was done to eliminate the need of repeated instance_destroy() and instance_create() being done, since it wasn't necessary to do so when everything can be handled in a single object.
 

Simon Gust

Member
Firstly, the order in which a project is created and completed doesn't necessarily comply with the order of level of difficulty per step to completion of said project. Delta timing was one of the first things I looked at because I noticed the game was limited to 30fps, at default, and adjusting that framerate was messing with everything.
You are not limited to 30 fps, have you looked at the room editor? You can just set it to 60 or 9999 or whatever you want.
upload_2017-9-2_22-8-38.png

suggests that I'd be limited to using only 32x32 sprites, or objects of relative size, which I'm not restricting myself to, and I refuse to limit the size of the sprites I use. We aren't in the mid-to-late '90s, anymore, and using such small sprites isn't acceptable, unless you're specifically doing so for an artistic graphical style that's reminiscent of the NES, SNES, etc. eras.
I did not say that it is limited to 32x32 pixels, I just said this for refrence. You can do whatever you want.

I'm not sure why you're setting the hspeed of the bullet to 400, then reducing it to 0 upon its creation when doing so nullifies the speed it's given in the key_press.
If you know event order, you'd see that it is the other way around.
When creating an instance, the instances create event is run before the hspd is set to 400. If I didn't initialize the variables in the object first, I may get an error.

The rest of the code doesn't fit with the system I have in place for shooting. Using the salvaged code also doesn't work any better than a step before what I currently have, which only has the issue of spawning particles in the bullet's last-known position before impact with the wall when that bullet actually makes contact with the wall. When the bullets miss the wall, with my current code, the particles are spawned in the proper location. Since there's a lot of stuff going on, I'll throw the entire system I have in place to make this work, starting with delta timing and one of the two guns the player has following them.
And again, you changed hspd and vspd to built-variables, it doesn't work for me either with those and if you read the manual you knew that you wouldn't even have to increase x by hspeed / y by vspeed. https://docs.yoyogames.com/

The rest of the code is fine I guess, make sure to compare values with "==" instead of a "=".
And maybe not put any code in wall objects you have more than one instance of.
 
Okay, I can't exactly tell if you are still haveing the original problem you were talking about in the OP, namely getting impact particles to spawn at the correct location, meaning you need to know the actual point at which the bullet hits an object.

I've used this code over and over, it is fairly simple, and gives as precise an impact location as you want. This works with or without precise collision checks turned on. Theoretically you could get better performance than this when using not-precise collision checks. What this does is use a binary search to find the approximate (although pretty accuracte) location where the bullet has hit an object. The bullet is moved to the point of impact.

Code:
    //BULLET END STEP EVENT

    if ( destroy ) { instance_destroy(); exit; }
    //------------------------------
    var _col = collision_line( xprevious, yprevious, x, y, obj_hittable, 0, 0 );
    if ( _col ) {
        //collision detected
        var _x0 = xprevious;
        var _y0 = yprevious;
        var _xd = x - _x0;
        var _yd = y - _y0;
        var _x1 = _x0 + _xd * 0.5;
        var _y1 = _y0 + _yd * 0.5;
        var _change = 0.5;
        var _accuracy = 1.0 / speed;
        var _col2;
        while ( _change > _accuracy ) {
            _change *= 0.5;
            _col2 = collision_line( _x0, _y0, _x1, _y1, obj_hittable, 0, 0 );
            if ( _col2 ) {
                _col = _col2;
                _x1 -= _xd * _change;
                _y1 -= _yd * _change;
            } else {
                _x1 += _xd * _change;
                _y1 += _yd * _change;
            }
       
        }
        x = _x1;
        y = _y1;
        //_col now contains id of whatever was hit
        destroy = true;
        //throw out particles at this point.
    }

It is a little hard for me to put into words how this works, maybe a picture will help. Imagine the red lines represent the motion of the bulelt. The top line represents how far the bullet moved in the previous step.
The dark gray line is a wall boundary. So the bullet is colliding with a wall. In order to figure out where the collision has happened, we shorten or lengthen the red line until its end point is close to the boundary of the wall.
We stop as soon as we have an acceptable level of accuracy. In that code block, that is controlled by while (_change > _accuracy), and accuracy is computed as 1 divided by the speed of the bullet (before the collision), the speed of the bullet being equal to the distance that it crosses in one step. The end result of that is the while loop will stop as soon as the red line has been moved a distance less than or equal to 1 pixel length. That should result in pretty much pixel-perfect location of impact position. If you need less accuracy, you could try setting accuracy to 4.0 / speed... which means the accuracy will be only within about 4 pixels of the true impact position.

upload_2017-9-2_13-53-22.png

You can see that the algorithm converges very rapidly on the true impact position, so the loop will not cycle very many times.

By the way, the purpose of controlling instance_destroy with the "destroy" variable, is so that if you are drawing tracers, the tracer will be drawn in the last frame of the bullet's life. Otherwise the bullet will seem to disappear just before it impacts the wall.
 
Last edited:
S

Shawn

Guest
You are not limited to 30 fps, have you looked at the room editor? You can just set it to 60 or 9999 or whatever you want.
View attachment 12455


I did not say that it is limited to 32x32 pixels, I just said this for refrence. You can do whatever you want.


If you know event order, you'd see that it is the other way around.
When creating an instance, the instances create event is run before the hspd is set to 400. If I didn't initialize the variables in the object first, I may get an error.


And again, you changed hspd and vspd to built-variables, it doesn't work for me either with those and if you read the manual you knew that you wouldn't even have to increase x by hspeed / y by vspeed. https://docs.yoyogames.com/

The rest of the code is fine I guess, make sure to compare values with "==" instead of a "=".
And maybe not put any code in wall objects you have more than one instance of.
Firstly, did you not read what I said?
Delta timing was one of the first things I looked at because I noticed the game was limited to 30fps, at default, and adjusting that framerate was messing with everything.
This framerate was changed to the maximum of 9999 when I started using Delta Timing, but it WAS still limited to 30fps when the project was started, because GameMaker's default framerate limitation for a room is 30fps.

Next, the speed issue isn't the other way around. The spacebar spawns the instance, setting its hspeed to 400. However, the speed is set while the key is pressed, AND when the object is created, in its create event, it sets its own speed back to 0. The spacebar gets pressed BEFORE the create event has a chance to occur, so when that create event does occur, the create event of that object takes over and changes the speed.

You see, THIS is why your variables are the ones with bad habits: hspd and vspd ARE TOO CLOSE to the hspeed and vspeed, so how is someone supposed to know when you're defining a variable, shortening the built-in function for ease of explaining a solution to a problem, or using the incorrect spelling for the built-in habit, due to custom variables being stupidly short?

There's NO logic in saying "if 1 = 1" makes no sense while "if 1 == 1" does. If A equals B, do C. If A equals equals B, do C. Moreover, what I've written doesn't use "==" and it still functions as intended.

The code in the walls isn't compounding with multiple instances of that wall. I have the code for particles set in the create_event of the wall so it sets up the particle system that's directly tied to that specific wall, and the delta timing adjustment in the step event of that wall isn't conflicting with multiple instances of that wall. If the purpose of not putting the code in multiple instances is to reduce framerate reduction, I'll look at changing it at a later time by throwing the global timing particle update method into the Delta_Timer, but I haven't gotten around to bothering with much in the way of working with eliminating some redundancy, due to the issues with particle spawn location being wrong.

After adjusting hspeed to Horizontal_Speed and vspeed to Vertical_Speed, as custom variables with definitions in the create_event, as per the code that was given, there's no difference over using hspeed and vspeed.

As for the manual: I've used it for some vague idea of how some things work, but, overall, the thing is pathetically written with broken English and poor grammar, and it's severely lacking decent explanations as to how things actually work.
 
S

Shawn

Guest
Okay, I can't exactly tell if you are still haveing the original problem you were talking about in the OP, namely getting impact particles to spawn at the correct location, meaning you need to know the actual point at which the bullet hits an object.

I've used this code over and over, it is fairly simple, and gives as precise an impact location as you want. This works with or without precise collision checks turned on. Theoretically you could get better performance than this when using not-precise collision checks. What this does is use a binary search to find the approximate (although pretty accuracte) location where the bullet has hit an object. The bullet is moved to the point of impact.

Code:
    //BULLET END STEP EVENT

    if ( destroy ) { instance_destroy(); exit; }
    //------------------------------
    var _col = collision_line( xprevious, yprevious, x, y, obj_hittable, 0, 0 );
    if ( _col ) {
        //collision detected
        var _x0 = xprevious;
        var _y0 = yprevious;
        var _xd = x - _x0;
        var _yd = y - _y0;
        var _x1 = _x0 + _xd * 0.5;
        var _y1 = _y0 + _yd * 0.5;
        var _change = 0.5;
        var _accuracy = 1.0 / speed;
        var _col2;
        while ( _change > _accuracy ) {
            _change *= 0.5;
            _col2 = collision_line( _x0, _y0, _x1, _y1, obj_hittable, 0, 0 );
            if ( _col2 ) {
                _col = _col2;
                _x1 -= _xd * _change;
                _y1 -= _yd * _change;
            } else {
                _x1 += _xd * _change;
                _y1 += _yd * _change;
            }
      
        }
        x = _x1;
        y = _y1;
        //_col now contains id of whatever was hit
        destroy = true;
        //throw out particles at this point.
    }

It is a little hard for me to put into words how this works, maybe a picture will help. Imagine the red lines represent the motion of the bulelt. The top line represents how far the bullet moved in the previous step.
The dark gray line is a wall boundary. So the bullet is colliding with a wall. In order to figure out where the collision has happened, we shorten or lengthen the red line until its end point is close to the boundary of the wall.
We stop as soon as we have an acceptable level of accuracy. In that code block, that is controlled by while (_change > _accuracy), and accuracy is computed as 1 divided by the speed of the bullet (before the collision), the speed of the bullet being equal to the distance that it crosses in one step. The end result of that is the while loop will stop as soon as the red line has been moved a distance less than or equal to 1 pixel length. That should result in pretty much pixel-perfect location of impact position. If you need less accuracy, you could try setting accuracy to 4.0 / speed... which means the accuracy will be only within about 4 pixels of the true impact position.

View attachment 12456

You can see that the algorithm converges very rapidly on the true impact position, so the loop will not cycle very many times.

By the way, the purpose of controlling instance_destroy with the "destroy" variable, is so that if you are drawing tracers, the tracer will be drawn in the last frame of the bullet's life. Otherwise the bullet will seem to disappear just before it impacts the wall.
For testing this, I just copied and pasted it into the bullet's end_step, then changed obj_hittable to the wall's name, since I'm assuming that's what was supposed to be done, but it's just yelling at me that "destroy" isn't defined.
 

Simon Gust

Member
Firstly, did you not read what I said?

This framerate was changed to the maximum of 9999 when I started using Delta Timing, but it WAS still limited to 30fps when the project was started, because GameMaker's default framerate limitation for a room is 30fps.

Next, the speed issue isn't the other way around. The spacebar spawns the instance, setting its hspeed to 400. However, the speed is set while the key is pressed, AND when the object is created, in its create event, it sets its own speed back to 0. The spacebar gets pressed BEFORE the create event has a chance to occur, so when that create event does occur, the create event of that object takes over and changes the speed.

You see, THIS is why your variables are the ones with bad habits: hspd and vspd ARE TOO CLOSE to the hspeed and vspeed, so how is someone supposed to know when you're defining a variable, shortening the built-in function for ease of explaining a solution to a problem, or using the incorrect spelling for the built-in habit, due to custom variables being stupidly short?

There's NO logic in saying "if 1 = 1" makes no sense while "if 1 == 1" does. If A equals B, do C. If A equals equals B, do C. Moreover, what I've written doesn't use "==" and it still functions as intended.

The code in the walls isn't compounding with multiple instances of that wall. I have the code for particles set in the create_event of the wall so it sets up the particle system that's directly tied to that specific wall, and the delta timing adjustment in the step event of that wall isn't conflicting with multiple instances of that wall. If the purpose of not putting the code in multiple instances is to reduce framerate reduction, I'll look at changing it at a later time by throwing the global timing particle update method into the Delta_Timer, but I haven't gotten around to bothering with much in the way of working with eliminating some redundancy, due to the issues with particle spawn location being wrong.

After adjusting hspeed to Horizontal_Speed and vspeed to Vertical_Speed, as custom variables with definitions in the create_event, as per the code that was given, there's no difference over using hspeed and vspeed.

As for the manual: I've used it for some vague idea of how some things work, but, overall, the thing is pathetically written with broken English and poor grammar, and it's severely lacking decent explanations as to how things actually work.
You are lacking the basic understanding of coding, I advise you to read the manual, watch a tutorial and start with easier things.
I refuse to help you, this cannot continue. I tried to help you but you aren't accepting my help so what am I supposed to do? give you a finished game?
 
you'd just need to initialize destroy to false in the bullet's create event. Note, it would be easier to demonstrate in an otherwise empty project, to avoid conflicts with your existing code. By the way, the variable "speed" is used in such a way that it is supposed to represent the distance that the bullet has travelled in the previous frame. Now, if you are using some kind of delta timing, then that distance would depend on the delta_time value.
 
S

Shawn

Guest
You are lacking the basic understanding of coding, I advise you to read the manual, watch a tutorial and start with easier things.
I refuse to help you, this cannot continue. I tried to help you but you aren't accepting my help so what am I supposed to do? give you a finished game?
= - Used to assign a value to a variable. Note that this can also be used for comparing variables in GameMaker: Studio and you may see this in examples and other peoples codes. However, this is a legacy from old GameMaker versions and you should use the == operators for comparing and = for assigning, as shown in these examples:
This suggests I'm actually correct. It says you should use both, but the way it's phrased, they're saying that it's optional, only for the sake of "neatness".
 
S

Shawn

Guest
you'd just need to initialize destroy to false in the bullet's create event. Note, it would be easier to demonstrate in an otherwise empty project, to avoid conflicts with your existing code. By the way, the variable "speed" is used in such a way that it is supposed to represent the distance that the bullet has travelled in the previous frame. Now, if you are using some kind of delta timing, then that distance would depend on the delta_time value.
Figured I'd have to do that, but wanted to make sure and there was something I had to do, so I had to rush with a response, without testing.
Now that I'm done with what I was doing, I threw
Code:
destroy = false;
into the create_event of the bullet, and it stopped yelling at me. When shooting the wall, however, I'm still left with the same problem I've been trying to resolve: the bullets that actually make contact with the wall aren't spawning particles, or, if I place the particle spawn code in the wall in addition to the end of the code you gave, it spawns the particles in the last step of the bullet's path before they make contact with the wall, setting them a good distance away from the wall.
 
Last edited by a moderator:

Simon Gust

Member
This suggests I'm actually correct. It says you should use both, but the way it's phrased, they're saying that it's optional, only for the sake of "neatness".
You are lucky, you're using this language, in any other language that is an error. Your neatness is a pretty bad practice.
 
S

Shawn

Guest
You are lucky, you're using this language, in any other language that is an error. Your neatness is a pretty bad practice.
My means of making something "neat" is for my sake and my sake only. I give variables the names I do so I know what they're used for, and it doesn't take a genius to look at code and see that "if x = 1" is comparing, whereas "x = 1" is setting the value; it simply takes basic logic and comprehension of how phrasing forms a coherent sentence. If this is a thing in another language, I'll call those other languages illogical, for there's no purpose in doing so, as it's a simple redundancy. However, seeing as I'm NOT using another language, this is a moot point.
 

Simon Gust

Member
My means of making something "neat" is for my sake and my sake only. I give variables the names I do so I know what they're used for, and it doesn't take a genius to look at code and see that "if x = 1" is comparing, whereas "x = 1" is setting the value; it simply takes basic logic and comprehension of how phrasing forms a coherent sentence. If this is a thing in another language, I'll call those other languages illogical, for there's no purpose in doing so, as it's a simple redundancy. However, seeing as I'm NOT using another language, this is a moot point.
yeah, why would they ever come up with comparing values using "==" instead of "=".
No seriously, did you know that when gml is compiled, all errors such as = instead of == are fixed to being ==.
= sets a value
== compares a value.
Ever coded a shader? doubt you have, there your luck runs out. There, real syntax is asked of you.
Data types are introduced, missing ; throw an error. Do you think your graphics card just ignores those commands you give it. Syntax is the most important part of a program.
 
S

Shawn

Guest
yeah, why would they ever come up with comparing values using "==" instead of "=".
No seriously, did you know that when gml is compiled, all errors such as = instead of == are fixed to being ==.
= sets a value
== compares a value.
Ever coded a shader? doubt you have, there your luck runs out. There, real syntax is asked of you.
Data types are introduced, missing ; throw an error. Do you think your graphics card just ignores those commands you give it. Syntax is the most important part of a program.
Yet, their site actually states that it can be used the way I'm using it.

And, as I've already stated, it doesn't take a genius to look at a line and know when something's being compared. The language should also be capable of understanding the difference, and if what you say is true, where it "fixes" that stuff, then it clearly DOES understand the difference, meaning it's still redundant.
 

Simon Gust

Member
Yet, their site actually states that it can be used the way I'm using it.

And, as I've already stated, it doesn't take a genius to look at a line and know when something's being compared. The language should also be capable of understanding the difference, and if what you say is true, where it "fixes" that stuff, then it clearly DOES understand the difference, meaning it's still redundant.
Yes the compiler knows the differences, the program doesn't, but that doesn't make it good practice. Why don't you just do what you want with your code, if comparing with = makes you think it's more logical, good for you. But if you ever want to have shaders in your game, you'll have to use ==.
 
S

Shawn

Guest
Take a look at this bare bones test project, and compare it against what is happening in your project. Just click the mouse somewhere to shoot a bullet in that direction. I set the room speed low so you can see the movement of the bullet better. My guess is you are doing the collision code before the bullet has moved?

https://www.dropbox.com/s/83iewwt349dokb3/Bullet_Collision.gmz?dl=0
A bit strange... I'll have to take a moment to throw some particles in that example project and see if it's the difference between using an object and using particles, or if it's due to my using delta timing. That project is essentially what I did when I tested the code, only it was spawning particles on impact, rather than objects. The code I had in the collision event on my game was just commented out, for the sake of the test, and all other code I had for the collision with the wall was commented out. The bullet's speed and direction was unchanged, but I don't think the bullet's creation in itself is part of the cause, since it's just an object that's spawned with instance_create(), then it has its speed fixed in a step event so that it complies with delta timing.

I'll give an update when I test particles in that example project.
 
S

Shawn

Guest
Take a look at this bare bones test project, and compare it against what is happening in your project. Just click the mouse somewhere to shoot a bullet in that direction. I set the room speed low so you can see the movement of the bullet better. My guess is you are doing the collision code before the bullet has moved?

https://www.dropbox.com/s/83iewwt349dokb3/Bullet_Collision.gmz?dl=0
Okay, I tested the particles on the example project, and they're working, so I think delta timing is messing with it on mine. Anything that has motion or uses an alarm is set to comply with delta timing, so the bullet's speed is an active variable that adjusts itself based on the framerate of the room. Even my particle system is manually updated with a variable that's complying with delta timing. I'm not entirely sure how your code works, yet, but is there something in it that allows it to comply with delta timing? To make something comply with delta timing, its actions have to have a way of being multiplied by the variable I set for delta timing, being global.Delta_Timing, since that variable holds an equation that utilizes the built-in function of delta_time.

EDIT:
HOLY CRAP! Okay, I found out what the problem was, and I feel REALLY stupid for not noticing this; after deleting the collision event in the bullet on mine, which just had commented-out information, the code you gave is working. I have no idea why the collision event was breaking the thing when it had nothing active inside it. Now, I just need to look over the code you gave so I can see if I can "translate" it to something I understand.

Thanks for the help!
 
Last edited by a moderator:
A

Arconious

Guest
Next, the speed issue isn't the other way around. The spacebar spawns the instance, setting its hspeed to 400. However, the speed is set while the key is pressed, AND when the object is created, in its create event, it sets its own speed back to 0. The spacebar gets pressed BEFORE the create event has a chance to occur, so when that create event does occur, the create event of that object takes over and changes the speed.
If you're referring to Simon Gust's example code he posted above, then you are incorrect in this case. The create event is run prior to hspd ever being set to 400. GML executes lines sequentially, and instance_create will ensure that the create event is called before it starts executing the next lines from the calling script/event -- which in the example above is setting the hspd to 400. This is pretty important to understand.
 
S

Shawn

Guest
If you're referring to Simon Gust's example code he posted above, then you are incorrect in this case. The create event is run prior to hspd ever being set to 400. GML executes lines sequentially, and instance_create will ensure that the create event is called before it starts executing the next lines from the calling script/event -- which in the example above is setting the hspd to 400. This is pretty important to understand.
Okay, after a second look at it, I guess I was accidentally misreading it.

See if I'm getting it right, this time:
The instance_create() was ordered to do stuff, so it did, only the instance that was created had code that it was ordered to carry out upon its creation, so that was done before the next step that came after the instance_create() could be accomplished. After the code in the create_event was carried out, it then stepped back to where it should be after instance_create(), so it could carry out the next step.
 
Top