Okay,

These are my givens:

v = (x,y)

v2 = ?

a = The angle between v and v2

I want to solve for the projection (P) of v onto v2.

I have two ways I can do this (that I know of).

a.)

P.X = (v.X * cos(a)) + (v.Y * sin (a))

P.Y = (v.X * cos(a+pi/2)) + (v.Y * sin(a+pi/2))

b.)

v2.magnitude = sqrt ( v2.X^2 + v2.Y ^2 )

v2.unitVector = v2 / v2.magnitude

DotProduct = v.X * v2.X + v.Y * v2.Y

P = DotProduct * v2.unitVector

Which is better? More efficient, etc...

Colludium - did you get it working?

Colludium - Here is the code that can be inserted into the vanilla behaviors. If you don't understand anything let me know.

To start with, locate the behavior file "Physics". You should make a copy of this folder someplace safe so if you mess anything up you can restore it without reinstalling construct.

You can use this code to modify either ams.js physics or box2dweb physics. Either way, you need to open up both the edittime.js file and the runtime file (or both runtime files if you want the changes available in both physics engines).

You need to add this line of code to the actions are in the edit time file. This creates an action that can be used in the construct 2 editor:

AddAction(28, af_none, "Set body to Kinematic", "Object Settings", "Set {my} Kinematic", "Set this object to be a Kinematic body.", "SetKinematic");

This goes in at around line 195. Do you see the first parameter in the AddAction call. Currently it is set to 28. This number has to be unique. If Ashley updates physics and you have this attached to the vanilla behavior and have to re add it, you may have to change that number (you can tell by looking at the last AddAction call and see what number it is using. In my case, this number was 27.

After that, add the following to the runtime:

Acts.prototype.SetKinematic = function (k)

{

if (!this.enabled)

return;

this.body.SetType(1);

this.body.SetAwake(true);

};

I added to where all the other Actions are (denoted by "Acts.prototype...."). You can find it easier by typing "cntr + f" to find it. The physics behavior is 13,000 lines of code, so reading through it to find where to put it can take a while. (it is at the very bottom though, right above exps.prototype.... for the expressions.

and that's it!

If you want to create your own behavior instead of modifying the existing one, you should copy the whole physics folder, rename the folder what you want the new behavior to be called and then change the top lines in the edittime file to reflect the new name. Replace the name with your new name (as you want it to appear in construct) and then replace the ID. I know it says never change it, but as you are making a new behavior, you need to change it to be something unique, else construct will think the vanilla physics and this new one are the same thing and then you will have problems

Let me know if it all works out!

stupid simple... Its like 5 lines of code. I never understood why this wasn't included in the behavior >.>

troublesum - I new it was bad for those reasons, but making an ai in a behavior that uses physics sort of needs that dependency.

Aphrodite - To all points, I agree fully. Especially the first. ..."write behaviors in events, or more logically to add event sheets to objects themselves" Both are desperately needed. This is one of the reasons I find unity so much more useful when making larger games. In unity, you add a script (ie behavior) directly to an object. Everything you want that object to do is contained in the script(s) you put on it. ..

but implementing this might be quite hard. I haven't really thought about how inter object references and dependencies would work. In Unity, you have to have a pointer to another object or script to be able to access it, which doesn't seem easy or uncomplicated for most people not having coded.

As for behaviors... I really don't use any of the canned behaviors straight out of the box. First of all, it's hard to have that unique all your own feel when using another persons implementation. To get the most out of any behavior, you have to understand the behavior in and out. at that point, you don't really need the behavior and can write your own (depending on the time). I much prefer to role my own platformer code every time I make a new platformer prototype... But I am also a perfectionist and knowing specifically what is happening in a behavior is important to me... And ya, that 8 direction code is no good when interacting with solids.

troublesum - though, honestly, as construct doesn't have a large team building the software... I think the likelihood of this happening is already quite low. I did look at how the events run though in the runtime, and its interesting. It simply loops through a list of events making the aces calls. I figured scripting that loop explicitly shouldn't be too big of a deal.

troublesum - well.... ya, but couldn't that same info be used to run an intellesense? I mean, when coding, you can always write non functional code. The way expressions are currently filled out already runs in a smart way... , so I don't see why it couldn't be done for the rest of the ACEs. If that in turn allowed for actually being able to code functions instead of using the function object,a and so on (loops, methods, etc) that would be really awesome.

But uh the above code needs fixed anyway, based on what I was thinking... I forgot overlapping is a system condition... done

troublesum - other programmers comments make me happy

lol

//BECAUSE PROTOTYPE IS UGLY.

but I like what you have done here.

edit

troublesum - did you just add that png to the comment? I didn't notice that the first time I read your comment. Ya, ya, that makes it much cleaner, which was part of my beef. Documentation is lacking which makes it hard to get into the sdk (in the time consuming sense of the word), and the adding of aces makes adding simple stuff a bit tedious.

troublesum - "I feel like saying the SDK sux is a bit unfair" - I agree. I should change that in the post. I don't think you being a literal pro at JS makes you biased, it gives your assessment authority.

I must admit that I have learned JavaScript on the fly through reading the c2 core source code and behaviors. I admit I am no pro in javascript, and much prefer C# or C++, consequently I make stupid mistakes and spend much more time mucking about simply because it isn't c++. That having been said, Most of what I meant by the sdk sucks, is that, it is poorly documented. My problems with javascript aside, the lack of documentation is what I find irritating. You have no choice but to read the core source files to find out what the difference between pretick, and postick are (plus the other two similarly named ones) When they are called, and on what objects they are called. The documentation mentions none of that. But at this point, I do understand it, and what happens, but I don't think the hurdle to get into the sdk was as low as it should be. Especially when compared to say, Unity,. C2 user manual is better than unity, but not if you want to script.

But I must read this plugin of yours. I would very much like to see the changes you made.

On a final note, I do remember that ashley told rexrainbow... or someone on the forums that it was a bad idea to call the aces of another behavior from within a behavior. none the less, It seems that this is quite normal amongst 3rd party devs, and I do it myself with no problems. But it is annoying that the documentation has next to nothing on the whole process of how c2 works internally.

nice!

I think it would be cool if all the text could do classical gameboy animations (you know, how the text types itself, and characters can wobble and so on)

I want to something like this as a possibility...

If (system.IsOverlapping(someObject, someotherObject))

someobject.X = 42;

camera.setposition(someobject.position);

//you get the idea