linkman2004's Forum Posts

  • How is this different from the default Common Dialog plugin?

    You don't get the side bar for selecting from drives, libraries, and what else have you when using the Common Dialog plugin.

    Sweet plugin, Lucid. I've been hoping for this style of dialog.

  • Were you thinking of this plugin, perhaps? It allows you to create a new instance of an object and give it a custom width, height, and/or angle in one event.

  • The way I achieve this is by using Cubic(a, b, c, d, x) instead of Lerp(a, b, x). Just set "a" and "b" in Cubic to what you set "a" to in Lerp and "c" and "d" to what you set "b" to and you should get the smooth movement you want. So basically:

    Cubic(a, a, b, b, x).

    I hope I explained that well enough.

  • I say go with 98.9. That's the version I'm using. It doesn't have all the spiffy new features, but certain things like sound and music work. You have a few more bug fixes about certain things in the latest version though, but the fact sound and music doesn't work in it is probably a bug too, so... Just download a few, try 'em out, I guess.

    Sound and music work just fine in the latest versions for me, unless you're talking about playing files that are in the "Sound" and "Music" folders. The XAudio object only gives you the option of playing files from the "Files" folder for whatever reason.

  • kindly add to you ninja game the following weapon: the sword or katana, throwing stars and nanchaku

    You realize this is over a year old, right? I've pretty much abandoned this game by now.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Linkman's IK solver plug-in can do almost everything you just learned, but I don?t use because im kind of stubborn in my ways, and it doesn?t seem to account for the ?circle inside circle? problem (if and when you read this linkman! Fix that bug if you already haven't )

    I'm fairly certain I fixed that back in November, when Newt brought it up -- unless the problem you're talking about is different from the one I am. However, maybe I should go back and make a true new version of the plugin.

    Cool tutorial, by the way. Very in-depth and informative.

  • There's no plugin for generic joysticks/controllers yet, and I don't know when or if one is coming.

    Last thing, I've recently seen somewhere that an object developpment kit does exist. Is that right?

    If it is, can anybody tell me where I can find it please? I'd like to look at it, even if I'm not sure I would be able to do something with it.

    I imagine you're looking for the Construct plugin SDK? If so, you can find the latest version here. Keep in mind that you'll need Visual Studio version 6 or later to make anything with it.

  • This formula should do essentially what you're looking for:

    X: enemy.x + cos( angle(player.x, player.y, enemy.x, enemy.y) ) * 100

    Y: enemy.y + sin( angle(player.x, player.y, enemy.x, enemy.y) ) * 100

    This will have the enemy move in the most "away" direction as possible from the player.

  • Sweet, thanks, David!

    The changes you made were all things I never got around to, so it's nice to see you put them in there.

  • 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?