Noncentz705 , I modified your behavior to work with wordwrapping. Just have to include the lineBreak expression in an event like shown in the example capx. Hope you don't mind.

R0J0hound , okay, makes sense. I'll continue experimenting with your behavior.

Thanks for the help, this is a great behavior!

R0J0hound , that looks much improved- can actually see them connecting correctly. Yea, the joint fighting is pretty bad, hope that can be solved. Is that something you'd need to address with how chipmunk is implemented?

edit: actually.. I tried moving all the imagepoints outwards 1 pixel on each sprite so that the polygons won't touch when attached, and it got rid of the fighting syndrome. Works perfectly like this. There's a visible gap between objects, but that can be solved by moving the polygon points inwards instead of moving the imagepoints I think..

Do you know why it would act crazy if the polygons touch? I'm wondering if that is something that needs solving even though this approach works.

Also, it's cool seeing your changes to the events, I saw some new ways of doing things that I hadn't seen before which will make my life easier.

R0J0hound , hmm.. I think that is confusing. Here's what I'm trying to do:

[attachment=0:3dm1cfar][/attachment:3dm1cfar]

Basically join objects together if their imagepoints are close enough..

If the joints are being added as if they're at an angle of 0 instead of the current angle, then I'm not sure how to do that easily. I'd have to somehow calculate where the imagepointX would be based upon how many degrees off from zero the object is. Seems like a lot of extra calculations.

Edit: btw, the capx shows that it's not working how I'd expect it to. If you could help me figure out how to make it work, that would be cool.

R0J0hound , been trying out the new version. Seems as if it no longer pins objects together correctly. I try add pin joint, with x y location of where the pin should be based upon object.imagepointX-object.x, but it isn't accurate..

edit: i'm doing more tests.. might be my code since it works with simpler situations.

okay, must be a node issue.. I tried it with the newer node version and it works as expected. I was using node 10.5 when I experienced the issue.

Sorry about that..

Problem Description

____ Using textarea property to allow text to have multiple lines for scrolling in a text box doesn't work. ____

Attach a Capx

____ [attachment=0:1v10pr5e][/attachment:1v10pr5e] ____

Description of Capx

____ Has text box with textarea property, and runs in node-webkit. ____

Steps to Reproduce Bug

• run with node-webkit
• type text into box so that it fills up and goes past bottom. Observed Result ____ Text box disappears ____ Expected Result ____ Textbox should stay visible and have a scrollbar. ____ Affected Browsers
  • Node-webkit: (Yes) Operating System and Service Pack ____ Win vista sp2 ____ Construct 2 Version ID ____ r190 ____

I have never really heard of "Game programming." I've heard people program games, but not "game programming." You can't really program a game without learning to program. With Construct 2 you create games using its event system, which shares some resemblance to certain programming concepts, but it isn't true programming from the user's point of view. That's why I suggest using it for demonstrating game concepts, how certain events in a cycle over time produce certain things like a moving object, etc. And then focus more on actually writing code that you'd expect to find in those situations.

That's how I'd do it, but you might be a bit constrained if you're expected to teach "game programming." Because I'm not sure how a person is suppose to learn that without learning to program.

What I would do is use Construct 2 to demonstrate game concepts and refer to the events as a means to introduce people to the thought process behind those concepts.

Each event requires some understanding/expectation that leads somewhere.

The javascript, I would focus mainly on, with the understanding of what was demonstrated a motivating factor. If people will potentially have no programming experience, I would focus on the programming. I wouldn't mix the two unless you can show specifically how one affects the other- which is easier with basic programming concepts like for loops, functions, etc. Making them understand why something works the way it does is more important in the beginning than knowing all the creative things they can do with it.

Okay.. just went and built a capx that loads a local xml file using node-webkit.

this is my first time doing this sort of thing.

[attachment=0:3sx149dv][/attachment:3sx149dv]

You'll need to export the project to node-webkit and put the document.xml file in the app's folder.

Then run the program and it'll load it. It won't work in preview.

Sounds like a useful feature, which would allow more variety to the types of games that can be made.

R0J0hound , here's a capx. don't get confused by the collisions looking off(the polygons are set in a bit on the squares).. But when you just press the up arrow key and allow the player to collide with a box, afterwards, when you try going forwards, the direction is all off-kilter and wobbly so you can no longer go forwards..

[attachment=0:1ty8o84e][/attachment:1ty8o84e]

as for the line thing, that sounds good with the start at left-center and end at right-center, I do that when I have to make lines with sprites anyways, so it makes sense.