How do I Keep Two objects near eachother

  • I looked at it, and it seems like it just cant keep up, for some reason. Not sure how to solve something like that. I tried to just use a every tick and set the Y value, but it was the same thing. Not sure it will work even with a pin or overlapping check, if it cant keep up without. It might be more solid, but might result in it seeing like its lagging or something. Maybe someone have made something similar that have a solution.

    I think the best thing to try at this point is to have the line pieces also spawn the new lines from themselves. I think then, I wont have to worry about lines separating over time.

    Do you think you could help me with using pick nearest/pick top object.

    Not exactly sure how this works and how to use it properly.

  • [quote:rwhfpleo]I think the best thing to try at this point is to have the line pieces also spawn the new lines from themselves. I think then, I wont have to worry about lines separating over time.

    The problem is that it shouldn't matter from what I can see, the problem occurs as the speed get to high. The way you have already done it with the custom movement is as far as I know the most basic way of doing it. Meaning that you simply apply the same speed to all objects and checking the debugger and the different lines, it does indicate that they are all in fact moving at the same speed. And that the problem happens within a very few ticks, maybe 1 or 2 I would guess. So exactly where and why it goes wrong im not sure. But if the most basic way of doing it doesn't work. I cant see how adding more complexity will help. And its not a consistent problem, some of them works fine, and doesn't seem to be linked to any specific lines, but just random ones at random times, but definitely as the speed increases it becomes more and more. I have checked the imagepoints to see if it could have been one of them that was off, but that doesn't seem to be the case. But I would like to know the solution as well. But at the moment I don't have time to try to solve it as im not really sure where the problem is in the first place.

  • [quote:d1syx27o]I think the best thing to try at this point is to have the line pieces also spawn the new lines from themselves. I think then, I wont have to worry about lines separating over time.

    The problem is that it shouldn't matter from what I can see, the problem occurs as the speed get to high. The way you have already done it with the custom movement is as far as I know the most basic way of doing it. Meaning that you simply apply the same speed to all objects and checking the debugger and the different lines, it does indicate that they are all in fact moving at the same speed. And that the problem happens within a very few ticks, maybe 1 or 2 I would guess. So exactly where and why it goes wrong im not sure. But if the most basic way of doing it doesn't work. I cant see how adding more complexity will help. And its not a consistent problem, some of them works fine, and doesn't seem to be linked to any specific lines, but just random ones at random times, but definitely as the speed increases it becomes more and more. I have checked the imagepoints to see if it could have been one of them that was off, but that doesn't seem to be the case. But I would like to know the solution as well. But at the moment I don't have time to try to solve it as im not really sure where the problem is in the first place.

    My guess as to the problem. Is like you said, over time the way speed works causes this separation. However I think it becomes an issue because the spawn rate is determined when an object gets destroyed. As things get faster, they might hit or detect a collision with the "end line" later or further away than they should.

    I did an experiment. Destroy the lines when they exit the layout. This actually made some decent improvements. It took much longer for the issue to occur. I think this is because the detection for leaving the layout is more efficient and accurate than the collision check.

    So I believe because when speed goes faster it moves more pixels at a time. That means that eventually it will move a large amount before getting destroyed(the collision would be in the middle of the object) and consequently make the next piece spawn with that gap.(when an object is destroyed a new one is made).

    I don't actually find speed to have a problem keeping up necessarily. If you notice, even with the gap. Objects move the same speed and that gap stays consistent as it grows.(I am also using 144hz monitors which let me see this gap pretty clearly as it moves)

    My new theory and I would go as far as a solution removes the possibility of this gap altogether. If each line segment is capable of spawning a line on itself, there can never be a gap.

    At least I think that makes sense enough

  • [quote:dohcoijd]My guess as to the problem. Is like you said, over time the way speed works causes this separation. However I think it becomes an issue because the spawn rate is determined when an object gets destroyed. As things get faster, they might hit or detect a collision with the "end line" later or further away than they should.

    Yeah this crossed my mind as well, and might be the problem.

    [quote:dohcoijd]At least I think that makes sense enough

    It might very well work, please post the solution when you have solved it, would like to see it as well.

  • I cant seem to get any sort of "pick" events to work whatsoever.

    I have tried pick top.

    Pick nearest.

    Pick bottom...

    Doesnt matter.

    https://dl.dropboxusercontent.com/u/58392676/pick.JPG

    Do I have this set up correctly?

    am I using the pick event completely wrong?

    I would think this picks the nearest line to that point.

    Any sub events should refer to that picked line.

    No?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • No you have ended up with the same picking mistake as so many others

    Every time you use an object, like you have done in the area I have marked with red, you do picking. It doesn't matter if it says "pick" in front or not.

    Rule

    [quote:7tdgzrfo]Whenever you use an object in a condition it will do picking!! doesn't matter what thing you are using, width, opacity, a variable or something else.

    So the problem occurs as you already in the Trigger pick one object which is the line that are destroyed. So now you have 1 object selected.

    So no matter what conditions you add afterwards, they will only be checked against this object. So you need to reset the picking. You can do that if you use the system action "Pick All Lines". That will Pick all lines regardless of any former conditions,

    From manual

    [quote:7tdgzrfo]Pick all

    Reset the picked objects back to all of them. Subsequent conditions will pick from all instances again instead of filtering from only those meeting all the conditions so far. See How events work for more information on how instances are picked in events. Useful in subevents to start affecting different instances again.

  • No you have ended up with the same picking mistake as so many others

    Every time you use an object, like you have done in the area I have marked with red, you do picking. It doesn't matter if it says "pick" in front or not.

    Rule

    [quote:3qedcqas]Whenever you use an object in a condition it will do picking!! doesn't matter what thing you are using, width, opacity, a variable or something else.

    So the problem occurs as you already in the Trigger pick one object which is the line that are destroyed. So now you have 1 object selected.

    So no matter what conditions you add afterwards, they will only be checked against this object. So you need to reset the picking. You can do that if you use the system action "Pick All Lines". That will Pick all lines regardless of any former conditions,

    From manual

    [quote:3qedcqas]Pick all

    Reset the picked objects back to all of them. Subsequent conditions will pick from all instances again instead of filtering from only those meeting all the conditions so far. See How events work for more information on how instances are picked in events. Useful in subevents to start affecting different instances again.

    Such a beautiful post to get back from work and read. Expect a full (hopefully working) demo shortly!

  • Changed things over, fixed a few new bugs and, I must say, results are rather nice.

    Here is a non-gameplay visual demo of what was done! https://dl.dropboxusercontent.com/u/583 ... index.html

    Simply click to get things moving!

    Things to note:

    Randomly generated smooth/flowing line! No Gaps! Even with speed changes!

    The above post gives an idea of what i did. I ended up trashing the idea of using set spawners and instead each line segment acts as its own spawner! The trick was picking the correct line to spawn from.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)