Yes, agreed. Would love to have a better runtime debugger for Construct 2. I don't know why a user would care about crash dumps besides curiosity.

Ashley I am curious why crash dumps aren't useful for the developers though. For some of these intermittent bugs that we have trouble duplicating, I would think a crash dump would provide value to the developer. Just wondering how the testers can better help the developers eliminate bugs.

A "persist state" would be awesome for Construct 2!! If more people get into action/RPG games it will make their lives easier.

Yaraslau Windows already has a built in just-in-time debugger called DrWatson. During a crash, by default, it will post a minidump of the crash info to c:\documents and settings\All users\Application Data\Microsoft\Dr Watson. You can then read the crash dump with the free debugger Windbg. It also dumps a .txt file that is readable by any text editor.

Unless, you are good at reading crash dumps, the minidump info is not particularly helpful though. I would think that this would help the Construct developers, but they have told me it is that useful. I would agree that it isn't as nice as having the actual .cap.

If you have ever had Construct crash on you search for drwt32sn.log and user.dmp and you will see what crash dumps look like.

The Editbox works fine for me for user input. However, if the player leaves the layout and then returns.... the editbox is broken. The other layout is using the editbox and dialog panels as part of the "inheritance layer" option. However, this creates new Editbox and Ok buttons, etc.. I thought that the inheritance layer should just re-use the same objects?? So what happens is that when the player returns, the input is going to the new editbox, but the parsing of the box happens on the old editbox. Therefore, nothing works.

Has anybody else experienced this bug? Is there an alternative or workaround to this?

p.s. I just realized after I posted this that because I physically layed out the editbox ,each time I enter and exit the layout a new editbox will be created... I could solve this by dynamically creating the editbox at runtime, but then I can't use the inheritance layer feature. Any ideas?

There are several times where I'm trying to figure out how a certain object works or how to implement some complex game logic. When writing regular code I'll turn to the debugger or old trusty print statements. Don't get me wrong... I think Construct is awesome and I get by with only print statements, but it would be less frustrating if we could single step in the debugger when troubleshooting.

Unfortunately, I don't think this will eliminate many questions since most beginners will probably never bother using the debugger or will just ask questions instead trying to figure out on their own. So I guess this is mostly a Construct 2 request.

Mipey lol... Yes, it isn't that hard for each of us to reset them, by heh if the developers want to do it then it wouldn't bother me.

If you have an object physically placed on a layout and then destroy with an event. When you leave the layout and then return the object reappears. Is this expected behavior or a bug?

The easy workaround for this is to not place any objects manually that you wish to destroy, but instead place them with events.

You need to package up all of your files into one zip file to make it easier for people to test out your game. When I saw all the files I would have to individually download I gave up on this. Also post a pic or screenshot.

This problem also affects Windows XP as well. I reported bugs for ComboBox and for ListBox Plugin on 7-26. Just can't get them to trigger on anything.

Cool example. Thanks for sharing your .cap so all of us can learn!

I came up with an ok solution for this. I pretty much set all moving object's speeds to zero and then save their location. I then make sure that no events will trigger in the new layout (through collisions etc.. I also set the global sprites to invisible so they don't show. Then with some simple checking if you have been to a layout or not you decide whether to instantiate an object for the first time or just use the saved location. Will send it out in a week or so when I send out the next tutorial. Still interested in an grand ideas though.

Yes, I second this! Would really come in handy.