Is it worth updating to the new plugin now? Or better to wait. Just curious on what you guys feel. O rwill Construct eventually put a stable version of the new cocoon in an update sometime soon.

flurry has seen some pretty big updates, with video advertisements and more features. Is there a planned update for this plugin anytime?

Keep up the great work! Didnt realize how many versions behind I was on spriter went from b6 to b8! Glad to see an auto updater now haha.

please quote the text there i write "i do not want learn for my goal"

pls show me this quote. i can not remember.

I think people just notice you have not asked for any help to learn.

Generally we take it as a sign of little effort or no attempt to actually use construct.

If it is learning and help that you want. A refund won't get you there

It also won't get you any closer to making and publishing a game.

I actually live stream construct 2 as I work on and play with ideas.

I do a number of videos and cover whatever viewers want to go over.

It's good learning and fun all around.

You can send me a Personal Message if you want all my information.

Otherwise, these forums are for you!

If you ever need help, have questions, or wonder if something can be done, just ask!

On a separate note, I am curious. What about construct2 had you originally asking for a refund?

Was there something not working? Or something in particular you didn't like?

which ways are easier?

yes i know. make very little games, which are fast to develop and put them into the stores till one app arrives the top 10.

I can not write good in english, have i understand you correctly?

What is easy for me and what is easy for you could be very different.

My advice:

Try making a very simple game. For ideas look back at old arcade games.

There honestly isn't an easy way to do things. Everything comes down to personal taste.

When I first tried construct I hated it. I viewed it as useless because I couldn't code and felt restricted. Certain concepts clashed with what I learned and know about programming in Java and c#.

But I kept using construct and now I love it. I had some walls to climb and still do. But I feel pretty comfortable with using construct and generally prefer it over alternatives.

Construct also has a great community. People are actually helpful and mature about things. That alone is worth it. I couldn't stand the vast amount of "trolls" in the gamemaker forums.

The lesson to be learned here:

Construct2 can make some really great games. But it can't do it on its own. You will have to try it out for probably a few good months of trial and error before you start getting awesome results.

Read the manual. It wasn't until I read the manual that I actually saw construct as being useful. It helps a ton and is a fun read.

Open and look at the tutorials/ templates!

I wish I did this sooner as well. Tons to learn here.

Goodluck!

i know i know. learning. i want only the "Big" money.

I guess I will be the one to tell you not to only want the "big" money.

If thats why you are doing this, the only reason why. There is NO EASY WAY. Some ways are EASIER. But in the end you need a ton of time, work, and perseverance.

I am just going to tell you to fucus on the "small money" have many games with little income and they all add up.

Only trying to get that one BIG AWESOME ANGRY BIRD type game. Only setting sights on a big success. This makes all the little success and achievments you make invisible. Being blind to that will only discourage you and keep you from a big success.

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.

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!

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?

[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

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.

I have thought of two possible solutions but would love some help in implementation.

1. Pick the nearest line piece from the top and spawn the next piece from it.

-What I need help with-

I dont know how to actually pick the nearest piece. Or rather, I dont know how pick nearest works.

Pick Nearest Line
{
  Line spawn(another line)
}
[/code:2ss8yw0c]
That is sort of how I thought things should work. I have the condition set as pick nearest line. and then the action is for lines to spawn the next piece.

Anyways an explanation on using pick nearest would be awesome.

2. My other idea is to use the check overlapping offset.
I ran into the problem of this seemingly not working at all...
I tried to stop it from picking the bottom line with an inverted pick bottom object. But still I would need some help with this method as well.

Those are my two new ideas of implementation.

But I still need help with either my former code, or these new ideas.