Thanks, it works great!

I've been trying to get heightmapping lighting to work with the mouse position, and the coordinates when the screen is at the top left are about mousex*0.00155 and mousey*0.002. It works until I scroll the screen, then the lighting gets misaligned again.

Is there anything that can be done about this?

Will do, thanks.

I'm making a shooter and have tried to set it up to use both the timer and a variable for timer based events, but both don't work when it comes to pausing via a modal layout.

The timer doesn't pause when using a modal layout, so that won't work. Neither does using a variable and 'trigger once' because the modal layout resets the events so after closing the modal layout, all the trigger once events activate again even when they shouldn't.

Are either of these bugs? It seems like they shouldn't work that way. Using timers, a whole bunch of the level will suddenly appear (whatever passed while it was paused) and using variables, the level up to that time appears at once. I can think of a clunky way around this that involves deactivating all the behaviors and sticking almost all of the events into a couple subevents, but it seems like they shouldn't work that way.

Floating point coordinates. If you want to keep the gaps from showing up, add an event:

Always

scroll to x: round(scrollx)

scroll to y: round(scrolly)

Either that or make them all overlap slightly (a pixel or two) if you want to keep the smooth scrolling.

Edit: It might not work if you're using the 'center screen' attribute. In that case you'll have to use:

Sprite: set x to round(sprite.x)

Sprite: set y to round(sprite.y)

Edit 2: whoops, thought you said sprites - right, overlapping the tiled backgrounds won't work, but the rounding still will.

My 3d program uses 'isometric' for a perspectiveless camera, I should've looked it up. I didn't convey what I meant properly by that, I know boxes are rendered with perspective, I meant for the entire camera because it seems like the camera's fixed at orthographic, and so can't move around freely in a 3d world with perspective (I shouldn't have mentioned that since I don't entirely understand how the camera(s?) work). Is there another camera for the 3d box? I guess my head isn't wrapped around the concept of moving the camera around in 3D when it's rendering both orthographic and regular perspective at the same time. Forget that point.

Again, I still have to disagree though, via the point you made - construct already has a lot of power to make 3d games as it is now (if you don't mind using boxes). I think even an 3D RTS or a 3d mario-type game could be done with only adding animated meshes and lighting (and being able to click on a 3d object, forgot that one).

Making a 3d box jump or run around is easy already. For the RTS, you can use a sprite with RTS movement elsewhere on the layout to control the x and z position of the box (mapped to the x and y positions), as well as the yaw, and solid sprites as obstacles, so while it seems like the box is navigating around obstacles in 3D, it's really a normal sprite doing it offscreen with 2d pathfinding. It's a little clumsy, but it works.

Animated meshes I don't know anything about, so I won't comment on.

I should have said basic 3d box collisions. I know exact 3d collisions are hard, but simple ones can be done now via events (I know how to check if a point in 3d space is in a box, but if not two boxes are overlapping). They can be faked to some extent by checking in 2d for two dimensions (like I mentioned above for the RTS) and use events for the third. It wouldn't be the most exact method in the world, but it would work for basic games.

Sprites are already setting their X and Y - I remember someone saying it would be possible to make a 3d sprite object, if it required too much modification of the normal sprite.

Honestly, I think you overestimate the difficulty. I don't mean to suggest that I know better than the developers, or how long it should take but from what I know about 3D, they don't seem like either insurmountable tasks or unreasonable requests.

Clarification: I think they're right that they should concentrate on the 2D part first. This is post 1.0 stuff.

Sorry about the wall of text.

I have to disagree. I think that there is a lot that can be done with relatively simple additions to construct. It won't be crysis, but with some basic controls I think some really awesome stuff could be made.

My list for what would be needed:

3D model object

play animations (no need for inverse kinematics, ragdolls or any of that complex stuff)

3d collisions

3d lighting (again, basic stuff)

camera controls (set xyz, etc)

set sprite's Z position

perspective rendering (<--As far as I know, construct renders things with an isometric (no perspective) camera.)

If we were able to set that to a normal perspective-based camera (perhaps on a per-layer basis?) and had the abilities listed above, we could make all sorts of awesome 3d games.

A couple 3d behaviors might be nice too, like 3d bullet. I'm not a 3d programmer, so forgive me if I underestimate the task of what I've listed, but as far as I know those would be relatively simple as far as 3d goes.

Every few versions I've felt like re-putting up a thread "Construct is awesome". Cuz seriously, it is. Another thanks, I really don't think I would be able to make my dream games without this.

Forgive me if this is a stupidly easy question, but I'm having trouble getting an exported screensaver to work. I've exported as a screensaver, used the .scr extension, but each time I try it crashes. Also, how do I set the name of the screensaver?

I've been having trouble copying and pasting events/actions/conditions for a while now. I would have posted a bug report but I can't find a common way to reproduce it. For example, I clicked one event, scrolled to another, held down shift, clicked the second event, did ctrl-c, went to another layout and pasted, and it worked fine the first time - but the second time I did that series of actions to copy and paste another bunch of events, it refuses to copy and it pastes the first batch that I copied.

It IS awesome It would be even more awesome if it was translated in english. GRR!

The technique they use and the paper doll thing are the same thing. They just use a lot of images, but each segment of the mecha is only rotating on one axis. The technique is basically moving, resizing and rotating images. This can all be done in real-time - as they show - all that's needed is an efficient way to tell the program how to place them. Another benefit of this is the animation size is very small.

Look at this page: http://www.spriters-resource.com/other/ ... g_rgun.png

Those are the pieces that make up the sprites. Not to intimidate you or anything. But that's how they get a lot of the crazy movements.

It's actually not all that hard in theory - they're masters of it though, so it looks more complex than it is.

Not stupid at all. Lots of people use this technique - one example is the super robot wars series - they really push the envelope of what can be done that way. Check it out:

http://www.suparobo.jp/moviearchive/index.html

Click on the one at the bottom of the top section (the one that's 101mb - don't worry, it streams - unless of course you don't have broadband), then scroll to about halfway through to get to the sprites. There's a high-res version somewhere but I'm not sure where at the moment.

I was even debating writing my own little animation program with construct to do stuff like that - construct is capable of it. Some programs out there that can do stuff like that are flash, the tab and anime studio. There are more but I don't know of them all. You should download demos of a bunch of them and find out which one works for you.