The pathfinding behavior is very CPU intensive. In your code, you are using a loop inside which you are finding a path. This starts the process of finding a path repeatedly and you will eventually run out of processing power to complete the task so, it is no wonder the game is crashing. Have you read through the documentation and tutorials on pathfinding? If you had, you would see this is not how to use the behavior.

There is a really good tutorial on combining 2 behaviors to get an enemy to chase the player:

https://www.scirra.com/tutorials/474/pa ... e-of-sight

Read through it. You may find an easy way to do what your are trying to do. Also, make sure to read all the documentation on the pathfinding behavior in the manual and check out a couple other tutorials.

I hope that gets you what you need and good luck with your project.

Here is a breakdown of what is going on:

LayoutWidth:

400

Distance between the two paddles:

400 (or equal to the LayoutWidth)

Maximum position to the right the paddle can move:

600 (equal to 200 or half the LayoutWidth to the right of the layout)

Maximum position to the left the paddle can move:

-200 (equal to 200 or half the LayoutWidth to the left of the layout)

Distance to add or subtract from the X value when one of the max positions is reached:

800 (or LayoutWidth * 2)

No, it was my fault. I used hard coded numbers when I created it and tried to modify it to go off the window width. See the modified version of the attachments. I put back the hard coded numbers. It's going off a window width of 400.

Take a look at these 2 events. If you use 2 paddles exactly 1 WindowWidth apart and both with all the same behaviors (remove the wrap behavior), this will give you exactly what you want.

[attachment=0:202mhz17][/attachment:202mhz17]

The reason the example you found doesn't work is, it just moves the paddle to the other side of the screen. You can't split the paddle into two pieces to show on either side. My version fakes splitting the paddle by using 2 paddles. As 1 leaves the screen, the other enters the screen. When the paddle off screen gets too far to the left or right, it jumps to the opposite extreme. Since it's off screen when it jumps, the player never sees it and it just looks like the paddle is wrapping around.

The attached capx shows how my method works.

[Edit] modified the attachments to fix a bug

This is covered in the tutorials.

https://www.scirra.com/tutorials/318/ho ... ng-screens

The common way to handle this is to have a layer just for the user interface elements. Then you set the layers parallax settings to 0,0. This will make it so the layer doesn't move while the rest of the layout does.

It sounds like you have a work flow that works great for you. Being a Construct 2 and Unity user myself, I can agree with a lot of what you are saying. There is power in coding that is lacking in a visual event system like C2s. I have also written games in C++, C# with XNA and straight Java (both PC and Android). I would definitely choose most of these over C2 for a large scale game project.

However, In defense of C2, for most current games that are built for the web or mobile devices, C2 is considerably faster than coding. For example, my son wanted to build a tower defense game and I had not built one myself in C2 yet. I decided to throw one together so I would have some understanding of how to help him. It only took me about 2 hours to have a near feature complete tower defense game working even without starting with the template. That is a really impressive build time for any engine for a game type that is new to a user.

Also, there are a lot of C2 users that are afraid (yeah, I said it, AFRAID) to try to learn to code because it seems so complex to them. A graphical event system can really ease a persons mind removing the stress of learning the tool so they can get their ideas into a playable product. I think this is the greatest strength of C2. People are at ease while learning it.

While it is far from the best or most powerful tool, it really has proven itself to a strong contender in the 2d game engine industry.

Hello ex32,

I am a programmer. I mainly work in Java and Javascript. To answer your question, it is possible. However, it is quite difficult and time consuming to create native exporters. The overhead of creating an exporter that could handle all the different systems Construct 2 supports would really take away from the progress of the program. All the great features getting added all the time would have to be put on hold each time a new feature was added just to ensure it worked properly with all supported languages. While Java and Javascript kind of sound like the same thing, they really aren't. In many instances they use completely different methods to accomplish the same tasks. Also, you specifically mentioned making a Java exporter to handle different systems natively. Even just a Java exporter would still take a lot of effort because many devices (Android, Blackberry, PC) that use Java require different code libraries. An Android device is programmed using Java but it has very different ways of accessing it's features than a PC and thus needs a different code base.

Since an Html5 game can be supported on all these devices using their built in browsers (or a wrapper that makes the browser look like a native program), the devs decided it would be better and/or easier to create an Html5 game engine. That is all Construct has ever claimed to be and, at least for the foreseeable future, all it will be.

Since you asked specifically about Java, I have just one more point to make. Java programs are not "native" programs. They require a Java Virtual Machine (JVM) to run. A native program is compiled directly to computer language where it can be run directly. Java isn't compiled to computer language. The reason Java can run on so many different systems is because of this intermediary program. In truth, the way Construct 2 exports to different systems is exactly the same. Java has just had more years to optimize it's performance.

It seems Jermfire and I understood your question differently. He understood it as how to make a health bar that stays pinned to the player. I understand your question to be, how to make a health bar that handles multiple player levels so no matter how high the players health is, it still shows the correct length. I have attached an example if that is really what you are looking for. Take a look at it. Basically you set the length of the health bar to 100 * (CurrentHealth / MaxHealth).

I hope you get what you need and good luck with your project.

There is an open source program called VirtualDub that will open many video formats and allows you to save it as a sequence of images. It is no longer updated and has very few options but should be able to do what you want easily.

If you want a more full featured tool, Blender 3d has a built in video editor that can render out the result to a series of png files. The video editor has a pretty steep learning curve but would allow you to modify and export your video including adding effects if you want.

Both of these tools are free and have no restrictions when it comes to using the result commercially. At least as long as the source you are working with is your own.

I hope this helps you with what you need and good luck with your project.

This actually may be a bug in the physics system. I downloaded your capx and did some tests. I was able to get the joint to work on single click if I applied an impulse to the box between creating the Sprite2 object and creating the joint. I gave the impulse a power of 1 in the direction of the Sprite2 so it didn't really cause the box to move but it still did the trick. It appears the problem is caused by the box sleeping. If you quickly grab a box on start up using your current settings, it will grab it with a single click. So, when you create the initial joint on a sleeping object, it wakes it up for a couple ticks but the joint doesn't connect properly. If you then click again before the box sleeps, the joint is created. Using the impulse wakes the box up so the joint can be created.

You may want to do some more testing given the above information and submit a bug ticket. Whether you do decide to submit it or not, the impulse should get you what you need. Good luck with your project.

Found another thing that could possibly be a bug. World 2 level 3 the mouse at the beginning sometimes starts facing left and other times facing right. I haven't seen this with any other enemy.