...What is a specific usecase that this plugin solves that isn't in the base engine? Most plugins already have vectors and I can use atan2 (or angle expression in construct) to get the angle of the vector and vice versa.

It sounds like a barebones movement plugin like the build in custom movement behavior.

Vector normals and projection are super cool and solve alot of issues very nicely in games. They aren't particularly complicated, but if you need to use them alot then it makes sense to have them wrapped up. A dot product is simply ax * bx + ay* by, but that can be verbose in a project - for example, to obtain a vector rotation, I might have to do something like this:

localVarX = Sprite.instVarX * SomeotherSprite.InstVarX + Sprite.instVarY * SomeotherSprite.InstVarY;

localVarY = Sprite.instVarX * SomeotherSprite2.InstVarX + Sprite.instVarY * SomeotherSprite2.InstVarY;

(where SomeotherSprite represents a unit vector created earlier or replaced with sin/cos(a)

Much better to simply have something like:

Sprite.v2.TransformDirection(SomeOtherSprite.v2.x, SomeOtherSprite.v2.y);

//Results stored in: Sprite.v2.x & Sprite.v2.y

You can also do neat things with unitVectors (a vector whose length = 1) and the dot product and cross product. Also, multiplying a unit vector by a scaler is a simple oneliner: Sprite.v2.Scale(scaler); Since there is both expressions and actions that do the same thing, you can set x/y of the v2 while also retrieving the result. It just reduces verbosity, and imo improves clarity, because unlike the dot product shown above, used twice to calculate a rotation, the function is named what it does so no need to adda bunch of comments explaining what maths are being used.

For example: If I had a boat, and I wanted to know it's velocity in the lateral direction in order to apply friction in that direction, I could do so with vector projection. Custom movement handlers are big candidates for needing vectors and vector math. But I even use it for input and a few other items. If you treat up,down,left,right input as a vector 2, you normalize it and then scale it by acceleration. Dealing with rotating gravity, identifying slope normals, and relative spaces/directions all need vector math.

You are most correct though, with the last statement, as it is, many times the need involves custom movement.

Oh, as an aside, you can use vectors to help infuluence, or steer, any other behavior. For example, using 8Dir, you could add up a bunch of influencing forces and calculate what direction to simulate to the behavior...

Hey all,

I have a behavior for vector2 support. Its not ready to share, but before I put the work in to make it ready, I wanted to know if people would have any use for it and in what ways they would see themselves wanting to use it.

Also, is there already a vector 2 math utility plugin or behavior out there that people use? (making this irrelevant?)

Mine is a behavior just adds an x and y property to the object with getters and setters for changing components or the whole vector. It also has magnitude, magnitudeSquared, and some simple logic to ensure magnitude (and other properties) are never computed more than needed. I don't create any new objects at any time.

If you wanted to calculate the unit vector for a vector you would do something like this:

action: Set Vector (x,y) //if needed

action: Normalize

expression: x

expression: y

I have expressions/actions for the following:

.normalized

.normal

.dot

.projection

.rotatePoint

.rotateDirection

.RotateVector

.scale

Would people find this sort of thing useful? Would it be better as a utility plugin rather than a behavior? Any thoughts, or suggestions before I flesh it out?

one is for Edit Time, the other for Run Time.

But I agree that it's super annoying to have to juggle a ton of different files for addons.

If I recall, in c2, I remember only a few files. One for shared scripts, one for edit and one for runtime. I'm curious why there was a decision to parse them out like this.

Adding the language support is nice, but that alone adds quite a bit of redundant typing and opportunities to misspell things - But I do like that the descriptions and such aren't wrapped up in those long calls to create new aces that we had in c2.

Try this one if you havent yet.

https://www.construct.net/en/forum/construct-3/plugin-sdk-10/c3ide-construct-plugin-ide-141201

Yes, thank you! This tool is amazing. I have used it a bit, but I prefer to make sure I understand all the things it is automating before really using it...

I think the biggest issue is that it is really easy to forget to change one line here or there (or worse, misspell it lol). Obviously that is a personal problem I suppose, There are a lot of 't's to dot and 'i's to cross - erm... the other way around... and so the workflow of adding a new _function to an instance and having a complete set of ACEs and property for that function is alot. Especially when perhaps it might just be basically a property with a getter and setter.

Call me dumb, but for the life of me, I can't figure out wtf half these files are doing in the template and why they are arranged that way. The addon sdk doesn't really help either. Ideally there should be some more pictures and break down whats going on. Instead, the manual is like, "Make sure you change this line here, and here, and here, to match this line over here... What is this? American tax season? I shouldn't have to waggle around 12 files to follow what a SINGLE behavior is doing. Its ridiculous.

You think you could just read them, and they would have comments explaining what they are doing, but not really, they more or less just warn you you can break a behavior just for doing things wrong... In the c3 runtime folder in behavior.js is this:

	"use strict";

{
	const C3 = self.C3;

	C3.Behaviors.MyCompany_MyBehavior = class MyBehavior extends C3.SDKBehaviorBase
	{
		constructor(opts)
		{
			super(opts);
		}
		
		Release()
		{
			super.Release();
		}
	};
}

	"use strict";

{
	const SDK = self.SDK;

	////////////////////////////////////////////
	// The behavior ID is how Construct identifies different kinds of behaviors.
	// *** NEVER CHANGE THE BEHAVIOR ID! ***
	// If you change the behavior ID after releasing the behavior, Construct will think it is an entirely different
	// behavior and assume it is incompatible with the old one, and YOU WILL BREAK ALL EXISTING PROJECTS USING THE BEHAVIOR.
	// Only the behavior name is displayed in the editor, so to rename your behavior change the name but NOT the ID.
	// If you want to completely replace a behavior, make it deprecated (it will be hidden but old projects keep working),
	// and create an entirely new behavior with a different behavior ID.
	const BEHAVIOR_ID = "MyCompany_MyBehavior";
	////////////////////////////////////////////
	
	const BEHAVIOR_VERSION = "1.0.0.0";
	const BEHAVIOR_CATEGORY = "general";
	
	const BEHAVIOR_CLASS = SDK.Behaviors.MyCompany_MyBehavior = class MyCustomBehavior extends SDK.IBehaviorBase
	{
		constructor()
		{
			super(BEHAVIOR_ID);
			
			SDK.Lang.PushContext("behaviors." + BEHAVIOR_ID.toLowerCase());
			
			this._info.SetName(self.lang(".name"));
			this._info.SetDescription(self.lang(".description"));
			this._info.SetVersion(BEHAVIOR_VERSION);
			this._info.SetCategory(BEHAVIOR_CATEGORY);
			this._info.SetAuthor("Scirra");
			this._info.SetHelpUrl(self.lang(".help-url"));
			this._info.SetIsOnlyOneAllowed(true);
			
			SDK.Lang.PushContext(".properties");
			
			this._info.SetProperties([
				new SDK.PluginProperty("integer", "test-property", 0)
			]);
			
			SDK.Lang.PopContext();	// .properties
			
			SDK.Lang.PopContext();
		}
	};
	
	BEHAVIOR_CLASS.Register(BEHAVIOR_ID, BEHAVIOR_CLASS);
}

drive.google.com/file/d/15kPU45uWAiLnM5aEOeMbDIgXqXpkL5e3/view

I simply disable any events I don't want to run. and then look at the global variable timetocomplete to get the duration the test took. The majority of events to toggle are in the repeat loop. The loop runs one million times. A global variable is set to 50, and is the number of times the test runs. I probably made some mistake in counting so it might actually be 49 million times the test runs... or 51 lol.

As per my other related post that you linked to, I am not arbitrarily inventing performance test to run, just for fun. I am running these because they are anticipated sticking points relevant to my project. You say "just make the game and worry about this later"? That's easy to say when you haven't already undergone the pain/time of porting projects to another engine multiple times because it wouldn't work in one or the other. Obviously you know how much work it took to change the engine from c++ to js. It pays in time and money to make sure you can feasibly create your project in the workspace and I am really limited on the former.

Anyway, I think this brings up two major considerations for me, and any project:

1. Calling a JS block is, for some reason, incredibly expensive, compared to basic event sheet ACES. This means that there is no reason to replace actions with JS, unless you are using a single JS block to replace many aces. Idealy, JS should be used to minimize event sheet loops and should never be used in an eventsheet loop.

Obviously, All of this is only applicable when working with a large number of objects.... say more than a few hundreds, like my original tests were geared for and what my game is going to call for.

But this really highlights the idea that you can use JS blocks to improve performance.

2. Event sheet functions still are way bad for performance if you are structuring your project around them in a sensible and reasonable way... for example: Don't repeat yourself...

I need a vector/math library for my game. I made a prototype project that uses event sheet function calls for this. They take 4 parameters (ax,ay,bx,by) and set globalVarables to handle multiple returns (rx,ry). Anyway, it isn't unreasonable to call a function from a function from a function... Function GetProjection is going to call function Normalize 2 times. If I really practice DRY, Normalize is going to call a function to get the length squared of a vector and then get the sqrt of that vector. TLDR, a simple function call to a library like this can easily call 6 other functions to do its job. You get 100 objects all wanting to get a vector projection, and all of a sudden you have 600 function calls and now you have already chewed through a decent chunk of your available cpu budget, and thats before you call functions for all those objects, like "seek" "arrive" and "avoid" which all will involve yet more vector math.

JS seems like a good option here, but simply replacing event sheet function calls like normalize() with a JS blocks calling a module to do the same thing.... performance isn't particularly better. Its WAY better to take that library and stuff it in a plugin and use the plugin instead - because then at least it feels like the JS is married to the ACES, but this goes back to behaviors and plugins being tedious to make and having to write alot of stuff just to make one ACE. (Skymens plugin builder is amazing in this regard - As an aside, if I recall, one of the things that the c2 community really was hyped on for c3 was basically to be able to build extensible behaviors and package them up and share them, all from within construct, but it seems that never happened for whatever reason).

Otherwise, the only other option is manually inline your function calls. That is tedious, unscalable, poor design, but saves a huge amount of performance where functions call other functions as in the example above.

Ashley

I wrote such a long reply but I was logged out when I hit reply.

TLDR: I fixed the test. I also made a few more.

I am not arbitrary in these. I have had to move projects from construct to unity in the past due to performance reasons. Every construct project I have ever worked on beyond prototype has had performance bottlenecks. I am not simply making random tests for fun, but creating small prototypes that help me determine if c3 is the right engine for this project. I can achieve 80fps in unity with 100,000 objects normalizing a vector projection for movement.

1000 was chosen because that is my design goal and is reasonable. But so for construct is unable to meet my desired performance goals.

The issue is this: (JS blocks have a surprising overhead, functions unsurprisingly have overhead, and must be inlined when used frequently)

JS blocks have significant overhead even if they are empty and do nothing. If a loop is being used to iterate through objects, it is best not to use JS blocks as actions work faster. This is a confusing result. I changed the JS so it would iterate through an array of data and calculate the results to another. So long as no loop was used in the event sheet, the JS ran super fast. So there is simply an overhead to each JS block that is accentuated in an eventsheet loop.

I knew built in eventsheet functions had an overhead, and would perform worse... blah blah blah...

But the fact is, I am manually inlining functions in order to achieve acceptable performance, and that is NEVER a good thing.

I'm not clear on how you are supposed to do this atm.

I've looked through some of the examples, but they always seem super basic, or all JS is in the main.js file, instead of the event sheet.

for (const inst of runtime.objects.Character.instances())
{
	inst.instVars.vX = m.x;
	inst.instVars.vY = m.y;
}