AHH! Found bug! In the cap, double clicking the 10 event (set velocity) makes colour settings popup.

I know, I've been having a problem with that too, I just haven't gotten around to reporting it yet. I should be more on the ball <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />

Whenever that happens, I've been having to just delete the action and write it again from scratch. Alternately, you should be able to "soft click" the numbers themselves to change them right on the event line without having to open the edit action window.

Edit:

Doh! Beaten by Ashley.

Also I think this is a bug : why there's a delay when the detector should be in the player position? I mean, jump, and the detector will work like an elastic.

The delay is there because the physics engine is updating before running the events, so there's a bit of a lag. Since it's just detecting when you're on the ground, it shouldn't be too much of a problem. If you were using it to, say, detect if you're stomping on an enemy's head, there would definitely be a problem.

So for example, positioning an object to the mouse coordinates, so you can make a brick follow the mouse, and move/slow down with the force of the mouse. So you could use the mouse to pick up an object and wack other objects with it.

I suppose you'd do it by checking where the mouse is, and where the object is, and working out how much force it would need to have moved to that position.

You could do it manually by setting up some "lastMouseX" and "lastMouseY" variables, then check them against the current mouseX and mouseY. You could calculate speed and direction that way, and translate it to the object you're dragging around. Even if you're "teleporting" it to the mouse coord every frame, if you're manually setting it's x and y velocities then other objects will still react to it in a proper way.

As a test, I created two objects and added physics movement to them. Then I made this event:

Always: 
[ul]
	[li]Sprite: Set velocity to (20,0)[/li]
	[li]Sprite: Set X to mouseX[/li]
	[li]Sprite: Set Y to mouseY[/li]
[/ul][/code:u3qrhsk8]

When I move the mouse around, the sprite sticking to it jitters, because it's trying to "escape," but I can drag it into the other sprites and they'll fly off toward the right as if they were hit naturally.  It even calculates the angles of impact correctly, so they're not just flying straight to the right, but angling up or down depending on where they made contact.

If you were fully calculating the speed and trajectory by doing something like comparing "lastMouseX" with "mouseX," you might be able to avoid the jitter that comes with manually updating the velocity of the object you're dragging.

Alternately, when you click to drag an object, you could make it invisible, then position a "dummy object" that matches it at the mouse's xy coord.  Since it's just a regular sprite with no physics, it wouldn't jitter.  Then when you release the object, discard the dummy and make your original object visible again.

With some clever collision routines you could even check to see if there's an object to impact with between lastMouseX and mouseX, and change the mouse position manually to compensate for it so that you're not intersecting things.  Hell, you might even be able to fake velocity, mass, etc. for the mouse itself by manually updating it's coordinates.  I'll have to play around with it some to see what I can come up with.

There's also the ability to include multiple event sheets on one layout, so if you have a section of events that you need to run on multiple frames, you don't have to copy them repeatedly to different frames.

Ah, I see. Well, I was way off. But hey, we both learned something today <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

I decided to try using Construct's physics engine to make a fancy screen saver, since a screen saver is basically just an .exe labeled as an .scr. And hey, what do you know... it works.

Just one problem though, and that's when I install the .scr in my system32 folder and go to select it in my screen properties, the name doesn't show up in the screen saver list properly. Instead, it's labeled as a number. The first time I did it, it showed up as "3." I exported another .exe, making sure to label all my layouts and such properly, thinking that maybe it was just because I left the program title blank in Construct, but then when I checked my screen saver list again it showed up as "4."

I can select this number and set it as my screen saver, and it works fine, but it was kinda bugging me that it didn't show the actual name.

Anyway, I opened up the .scr in Resource Hacker to check the string tables and see if it was pulling the 4 from one of them. The only listing in the string table is this:

STRINGTABLE
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
{
1,    "4"
}
[/code:2wrptwbe]

I guessed that this was where Windows pulls the name of the application from, so I changed the string with ResHack.  Sure enough, it showed up in the screen saver list properly... but changing the table also made my screen saver crash.

Should Construct be filling this spot on the string table with the app name when it exports an .exe?  Is this a bug, or am I just being fussy?

1) 3D Boxes don't manage collisions. This is annoying, you have to create colliders for everything! There are 2 problems : neither starting the condition from a 3D box nor from the object that must collide with it works :

When sprite collides with 3dbox = events (nothing happens)

And, you can't even manage collisions in 3Dbox.

2) Depth too high by default. The "1" depth we have now should be 5, since we can't use decimal numbers.

I'm really begging you to add collision support

I've been working with the 3D Box quite extensively and I'm afraid I can't recreate any of the problems that you're having.

I made a test .cap to see if I could test for collision between a sprite and a 3D Box. I gave the sprite 8-Dir movement, and added this event (just as you described:

Condition: On collision between Sprite and 3D Box:

Action: Sprite2: Set X to Sprite2.X+10

Every time I collide Sprite with 3D Box, Sprite2 moves ten pixels to the right. Here's the test .cap to see for yourself:

http://projectbrimstone.googlepages.com/3dCollisionTest.cap

This is with the 3D Box's "Solid" attribute turned off.

Now if you turn on Solid, then I can recreate it. Your sprite and the box won't be able to overlap and register a collision, at least with the default movements. It seems like Construct is checking objects against their Solid attribute before checking the event list, so objects with Solid turned on will be pushed apart before the collision condition occurs.

As for the Depth, I'm really confused. I can enter in decimal values just fine:

<img src="http://xs321.xs.to/xs321/07465/3dboxdepth.jpg">

The Depth and Z values for these boxes were entered into the 3D Box Properties without any problem.

As for collisions with the 3D Box, you have to keep in mind that the box is just a rendered overlay on top of a 2-dimensional bounding box:

<img src="http://xs321.xs.to/xs321/07465/3dboxbound.jpg">

The collisions between the box and other objects occur at the bounding box, regardless of it's Z depth. This means that even if it appears "above" or "below" your sprite, it will still collide at the bounding box.

--------------------

EDIT:

As Ashley said, the "bounding box" is actually a mask of the back face, but the idea is still the same. It's a 2D area that stays on the same Z plane as your sprites.

--------------------

As for your back face rendering: The faces are one sided. This is the default with just about every 3D program. The faces won't render unless they are facing toward the display. Try changing the yaw of your box to rotate the back face forward and you will see it.

I've been meaning to ask if Ashley would put a "Render 2 Sided" option in the textures panel, but he's busy with other stuff right now and I've already asked for a crapload of features for this object <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" />

Hey everyone, i was wondering why i do not have this:

It's not a bug. You have to add the Physics movement type to your sprite under the Movements section of your sprite's Properties panel. Just click "Add" next to New Movement and select Physics from the list.

<img src="http://xs221.xs.to/xs221/07465/movement.jpg">

<img src="http://xs221.xs.to/xs221/07465/new.jpg">

You will see the default Physics settings for your sprite in the properties panel.

Now when you insert a new event in the Event List Editor you will have access to your sprite's movement values and actions.

Here's a tip: If you want an event to begin by comparing your sprite's mass, or whatever, don't start off the condition by picking your sprite. For some reason the Get values don't show up in the sprite's condition panel (I believe that is a bug). Instead, double-click the System icon and scroll down to the Values section and select "Compare." You will see a generic compare panel. Under Value 1, delete the zero and then double-click your sprite. Now you will see your physics tab. Select the physics value you want to compare and go from there.

I've found that the generic Compare under the System events generally works better than trying to call up values directly from your objects, at least until the bug is fixed.

not much on this site in terms of actually creating something!

I know <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />

I've been toying around with the idea of making a series of "Mini-Tuts" for beginners that just cover some of the basics like how to use the interface and understanding events and commands and such. It would be beneficial to me as well, since I learn best by teaching. Noobs helping noobs, as it were.

Another reason to do it is because having some sort of content in the help section would likely draw in more users. Construct is seriously lacking any sort of reference material right now, which is likely keeping at least some new users away.

And since I support Construct, I feel I should help in some way, other than making suggestions or bug reports. I might not be able to help out with coding, and I might be too poor to donate, but I can write <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

When i mentioned my game running slow, it was when using the game maker program. At most, 3 of my NPC's had at -most- 1000 events running at the same time, and it lagged my system:

One thing you should know before using Construct: it is very different from Game Maker.

Instead of defining every action and event on a per-object basis, there is an "even sheet" that is separate from your objects. This means that instead of putting, say, control actions in your player object, you tell the event list to get the input, and then tell the event list how to move your player sprite. And instead of 1000 events per NPC object (for 3000 events total), you would just have to put that 1000 events in your event list one time, and each NPC would use that single list. All higher quality game dev programs use this method, from Construct to Torque to MMF, etc.

Game Maker by comparison is a clunky, inefficient piece of junk. For instance, the "Your First Game: Catch the Clown" tutorial is almost two and a half megabytes when it's compiled, and that's just for a single sprite that bounces around the screen for you to click on. And when you run that program, GM is so choked up that that single sprite is jittery and blurry.

I made a platformer demo from scratch in Construct in under a day, which has twenty-seven 3D objects, a player sprite with animation, and a tiled, parallax scrolling background. The .exe it exported is only one megabyte, and... get this... there are only 15 events in the whole program. Eight of those are events that manually make one of the 3D objects do something that it's not designed to do automatically. And it runs as smooth as silk on my crappy-ass computer.

So yeah, it's fast. And it's efficient. And even though it's just in beta right now, and still has a few buggy problems, it's a damned sight better than GM. I've read that Yoyo Games is re-writing GM from scratch in C++ so version 8.0 should be a bit faster, maybe even "twice as fast." Construct by comparison is already hundreds of times faster.

Also, Construct will probably be a little confusing at first if you're used to GM. After using it a while, though, I think you'll see how it's more logically organized and ultimately easier to use. GM is just so backwards it boggles my mind.

Unfortunately, no. Sorry <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />

I first noticed the icon was incorrect a few days ago, before v0.84 came out. I figured it was just a tiny little bug, and I could just edit the icon any time. When I finally got around to editing it this morning, I discovered that the problem was bigger than I first thought.

It's not a terribly big .cap though, I can try recreating it from scratch and see if it happens again. I'll let you know what I find, if anything.

Can you send me a .cap with the wrong icons? ashley@scirra.com, cheers!

A .cap file was sent.

Good luck![/code:3j32doto]

One of the object icons in the Layers panel has an incorrect icon. It's a 3d Box object. I'm sure you're not totally sick of hearing about that object yet <img src="{SMILIES_PATH}/icon_wink.gif" alt=":wink:" title="Wink" />

Anyway, sometimes the icon displayed is my player sprite, sometimes it's the Mouse&Keyboard icon. It switches around to different icons, which is strange enough. When I open the picture editor to edit the icon, I get a couple of different errors. Sometimes I get:

An invalid texture handle was used.  

Good luck![/code:2q1myh74]

And other times I get:

[code:2q1myh74]Runtime Error!  

Program: C:\blahblah\Construct.exe

R6205
[ul]
	[li]pure virtual function call[/code:2q1myh74][/li]
[/ul]
I'm also getting incorrect icons for other objects in the event conditions and actions selectors, and in the event sheet editor, which makes it a little confusing.