While it might not be terribly helpful to all users, don't be discouraged from posting tutorials like this. We need more stuff like this on the forums.

After Monday I'll be releasing my current project (my TIGSource competition entry) along with the .cap to anyone who's interested in it. I'll also make a thread going over a few of the tricks I used to make the game (like jump-through platforms and platform AI). It's almost complete, I pretty much just need to do the music and the level editing.

If I were to vote it'd be "no" but that's only because I just made a menu like this for my project about a week ago. Only instead of highlighting the menu options with color I used a pointer sprite:

<img src="http://i28.tinypic.com/2l8aed5.png">

Basically the same though

But I won't vote "no" because that would be rude. I'm sure this will be useful to some people.

Okay, I had previously posted a thread here where I got a corrupt .cap back in v0.91 that had to do with global variables in events. Now I have another corrupt .cap that behaves the same way (opens to 90% then crashes Construct), only instead of global variables I was working with private variables in events.

This is what happened leading up to when the crash occured:

I had an event that was set up like so,

+ Always
[ul]
	[li]Sprite: Set position to object spriteBody (image point 0)[/li]
[/ul][/code:3jbg4zcd]

I added the private text variable "status" to the sprite, and set it's default value to "alive."

I went to the event sheet I was working on to control the sprite and changed the "Always" by double-clicking it and backing up to select the sprite instead of the System object.  Then I changed the event condition to test the variable "status," like so:

[code:3jbg4zcd]
+ Sprite: Value 'status' Equal to "alive"
[ul]
	[li]Sprite: Set position to object spriteBody (image point 0)[/li]
[/ul][/code:3jbg4zcd]

After making the change, I started making a new event:

[code:3jbg4zcd]
+ spriteBody overlaps spriteCollider
[ul]
	[li][/li]
[/ul][/code:3jbg4zcd]

I didn't finish the action in the event because I noticed that the change I made before didn't take.  Instead of showing "Sprite: Value 'status'" it said "Sprite: Value 2."  So I double-clicked the event and re-set it to "status," and it showed up normally.

That's when I noticed that the icon for the sprite wasn't the sprite's icon, but the system icon instead.  I immediately saved a new version and quit Construct.  When I tried opening it again, it crashed.

I think that the corruption came from changing the condition from a system trigger to a sprite trigger rather than just creating a new condition from scratch (hence the sprite icon changing to the System icon).

And that's about as specific as I can get.  Here's the corrupt .cap:

[url=http://www.mediafire.com/?oruo4ojtoly]http://www.mediafire.com/?oruo4ojtoly[/url]

That really sucks. It's weird that some people get all the bugs. I've only had like two corrupt .caps ever, back in .86, and one in .91. Both were fixed, and I didn't really lose any work.

I never got the family-file bloat bug either. I kinda wish these major bugs were more universal so they were easier to straighten out.

Great... now I've probably gone and cursed myself.

Edit:

WOW

That could not have been more perfectly timed. I just got a corrupt and un-openable .cap. It wasn't having to do with layout order, though. Guess I'll make a new thread.

The problem why eventing in Construct is slow is because you're required to scroll down to get to several actions.

I think a simpler solution is to replace the list with a tree. All items are collapsed by default, and a single click on an item will expand it. This will pretty much eliminate the need for scrolling, and will make eventing much quicker.

I don't know about anyone else, but I've done so much event coding in Construct now that I pretty much have the list memorized. When I code events my scroll-wheel finger is on auto-pilot and stops where it needs to. Having a tree that you need to click on would just slow the process down by adding extra clicks.

Unless Construct could memorize what nodes I have expanded so I don't have to click them every time. That would be okay.

The one major thing I think would speed up event coding is sorting objects into folders, and having the option to exclude objects or folders of objects from the event lists (for instance, background tiles that don't have any purpose except decoration). But that's on the to-do list I think, so I'll just wait patiently.

Wow, that is funky. I didn't get what you were driving at before, but I can see it plain as day now.

Yes, you just put the name in quotes.

• System: Go to layout "layoutName" with transition "None" lasting 0 MS

Well, there's something buggy going on. I'm able to reorder my layouts without any problems. Hopefully Ashley can help you out.

Huh? It shows all of my event sheets in my project tab:

<img src="http://xs125.xs.to/xs125/08125/project_window458.png">

All of those event sheets were created separately except for "Layout 1," "Layout 2," and "testScreen 2" which are the default event sheets. They're all there whether I'm on a layout that uses them or not.

> Deagle... Deagle...

>

> Why does that name sound familiar?

>

Becouse it's short for Desert Eagle?

No, I think there was someone in the click community named Deagle. I dunno. The name just rings a bell is all.

Deagle... Deagle...

Why does that name sound familiar?

oh and curious, how do i access event sheets that i have added through the "Manage event sheets" button?

Click "edit" next to the event sheet in the App properties.

Or double-click the event sheet name in the project window.