I had an issue like this, and I fixed it by tweaking the manifest file (app.manifest and offline.appcache) location in the raw HTML that Construct exports (since we moved everything around on the backend for security). Once I had these pointed to the actual files, it worked fine.

We are exporting in HTML5.

If you want sprites to be dynamically downloaded by event within the Construct action sheet sequence, then you have to have a blank placeholder sprite and reference the URL of where it is stored.

If you are asking about where native sprites are stored, it depends on what you are exporting in. In HTML5 exports, they are stored in .../exportDirectory/images (assuming you use the default option for "Subfolder for images") otherwise it will be in .../exportDirectory/customSubFolderForImagesDirectory where the ... is whatever you have in the "Export files to:" field.

If you are asking about where the Construct client keeps the sprite image files in preview mode, I believe it just references the image files directly on your hard drive when you initially created the sprite.

What format are you saving your save game data in(file and data structural)?

You should never give up. There is always a solution, it just depends on how much refuse you have to pick through to find the jewel that is your answer.

Spine will do this too.

I've had all kinds of odd issues with SpriteFonts especially when resizing them. I had odd vertical lines show up and other peculiarities. I think we will just eat the performance loss to use the nicer looking Text objects.

That is how physics works. You need to give you ball more lateral (x-direction) velocity.

You can attach files by uploading to various file sharing sites (Google drive, Dropbox, Jumpshare, etc.) then posting the link.

Did you assign the sprite.level variable somewhere? What is it's value by default?

Are you dragging tin cans behind like a marriage ceremony?

I am not sure how you intend to have objects move "with the box" while still colliding with the ground?

You might have to parse out the x and y directions of the particles and limit each one separately.

The backup file exists in the same place as your main file. Usually it is named: mainFileName.capx.backup1 or mainFileName.capx.autosave

Just rename mainFileName.capx.backup1 to mainFileName.capx (remove the .backup1) and it should open normally, assuming you didn't corrupt that one too.

If all else fails, you get to use a program like 7-zip to unzip your .capx file, go through all of the xml files and find out what you screwed up and fix it.

We use rexrainbow's Hash object to parse JSON from our server (delivered via AJAX HTTP get calls). It works exceedingly well.

We are running a multi-server proxy system (for security) and several backend databases (PostgreSQL).

You could use it to parse JSON flat files just as easily though or JSON stored in web storage or cookies.

Please save it using a non-beta version of Construct (like v r206?)

I don't get people's fascination with beta-level development products. You don't need to tempt fate when it comes to bugs, you create enough for yourself...