Just to be clear, this isn't a feature request, rather it's a proposal to merge some changes I've made to the physics behavior's custom collision mask editor with the version on the SVN. These changes are all usability related, simplifying the mask creation process with some nifty new features.

All of the changes take place in two files, Edittime.cpp and Main.h. Here's a download link to the altered files and a compiled version of the plugin:

Physics Changes

[CHANGE] - The first and last vertices are marked; the first vertex has a red minus symbol inside while the last vertex has a blue plus symbol inside. This is so users will know better where the next point will be placed.

[ADDITION] - Vertex dragging. If a user left clicks and holds the mouse over a vertex, the vertex can be dragged around. All newly placed vertices are also placed in drag mode. Holding the control key will disable this, allowing the user to place vertices on top of one another and place many points quickly without worrying about dragging them.

[ADDITION] - Rick clicking on any vertex will delete it, instead of having to delete all the vertices after it sequentially just to delete it.

[ADDITION] - Holding down the shift key will display lines running from the first and last vertices to the mouse, showing where new collision lines will run if a point is placed.

Variable and function additions in the code include:

POINTF* dragPoint in the EditExt class in Main.h - This is a pointer to the vertex currently being dragged.

bool setWindowFocus in the EditExt class in Main.h - This is set to true when first starting the mask editor. If the value equals true, the focus is set on the frame editor and the value is set to false.

bool MouseOverPoint(bool deletePoint) function in EditTime.cpp - This is used to detect if the mouse is hovering over a vertex and for deleting any such vertices if specified as true through deletePoint. Also, if a vertex is being hovered over, dragPoint will be pointed to it.

Most of the feature additions are contained in EditExt::OnMessage() and MouseOverPoint(). These are where point dragging and point deletion are handled. The shift key preview is contained in EditExt::Draw().

So, there it is for your consideration. I've tested everything and it all seems to work properly, but since I don't entirely know how parts of the plugin work, some of it may not be properly handled -- mostly these concerns lie in the point deletion aspect of MouseOverPoint().

Cheers.

I imagine you're probably not using the whole expression I mentioned. The "global('stuff') = " part is actually part of the expression, since the conditional operator checks that value and decides what value to return based on whether it meets the condition or not. Here's an example, just press space to toggle the value:

Boolean Toggling

I hope this clears things up.

On the issue of the number is between thing, would you mind posting a CAP with the problem? It's hard to understand exactly what's wrong without one.

You can use the System object's "Number is between..." condition to see if a value is within a given range.

There are no actual booleans in Construct, but you can use regular values to represent them. A simple way to toggle one of these values between 0 and 1 would be to use the conditional operator("?"). Just set the value to this:

global('stuff') = 0 ? 1 : 0[/code:2ud6rw4m]
This basically means:

if "stuff" equals 0 [b]then(?)[/b] return 1 [b]else(:)[/b] return 0

Hope this helps.

Unfortunately, the "Else" condtion doesn't work in some cases, and that's what's messing things up here. Just replace it with an inverted copy of the "Text is "Exit" (case: Yes)" condition(right click the condition, then click "Invert condition").

I haven't encountered any problems at runtime involving WM_KEYUP messages. In fact, it worked just fine when I tested it. It just seems to be the edittime, which poses problems since it works fundamentally differently from the runtime.

For now, I've found a way around this for my particular setup, but it's less than ideal.

Well, I've been messing around with the way the physics behavior handles Windows messages for the custom collision mask editor.

I've achieved some success by checking for "WM_KEYDOWN" messages, then using the GetKeyState() function to see if the key I'm looking for is down, which works fine, but no "WM_KEYUP" messages seem to come through the pipe. Here's the code:

void EditExt::OnMessage(int message)
{
	switch (message)
	{
		case WM_KEYDOWN:
		{
			if (GetKeyState(VK_SHIFT) < 0)
			{
				shiftDown = true;
			}
			break;
		}
		case WM_KEYUP:
		{
			if (GetKeyState(VK_SHIFT) >= 0)
			{
				shiftDown = false;
			}
			break;
		}

	}

}

void WINAPI ETOnMessage(editInfo* editObject, int message)
{
	editObject->objectPtr->OnMessage(message);

}[/code:1apw4ljp]
No matter what I do with the keyboard, I never receive any WM_KEYUP messages.  I've double checked for this by having the program throw itself into an infinite loop upon receiving a WM_KEYUP message, but it never does.

I can't imagine this is intentional on Construct's part, but I could be wrong.  Is there some way around this, or am I just doing something wrong?

Yeah, that's what I need. I suppose I should have been more specific about that.

I agree, a field to put parameters would be helpful. However, one way to kind of clean it up at the moment is to have a global variable dedicated to calling functions, calling the function in a "Set global variable" action with all of the parameters.

Is it possible using the current SDK to setup a proper event handler for the edittime side of plugin development? I know the physics plugin has a basic one, but since you can only get the message, you can't detect, for example, which keyboard key is being pressed or anything.

Anything I can do here?

Great batch of fixes. Thanks again, guys!

This is because you have the "Solve IK" action before you position the first leg object. Since the second bone is positioned to the current position of the first bone, a gap will occur if the first bone is positioned after the IK action. Just place said action after the action where you set the position of the first bone and it works fine.

Unfortunately, there's no object that handles microphone input. Somebody would have to write a new plugin for that functionality. I was looking into it earlier, but I couldn't find much information on getting input from a microphone.