See the section "Using it in Construct".
See this guide which might help.
It does property renaming but keeps the existing name, e.g. UglifyJS will rename obj.apples to obj._$apples$_. This can help you figure out why some code doesn't work in 'Advanced' minify mode, as it still renames properties, but you can still read the code.
You can export in 'bundle only' mode and then use an external tool - including UglifyJS - to minify yourself with custom options like source maps.
The addon is already updated in the latest beta release.
It's not possible to show an error for features that are not compatible either. Doing so means using a time machine to predict what changes are made in future and ensure a useful error message is shown for them.
It's not possible to detect features that are not compatible, as the older version doesn't know they even exist.
You should expect beta releases to be occasionally broken. If you don't want to deal with that, stick to stable releases and don't use beta releases.
It's impossible to reliably allow projects saved in newer versions to be opened in older versions. What happens if you use a new feature which the older version doesn't support? There's no solution to that.
I don't think "preferred" is the right word. It's an extremely difficult format for us to support and I don't think it even makes sense for the ad networks to support it either. For example base64 encoding increases the size of files by about 30%, so it bloats the download size unnecessarily. Allowing separate files avoids that. Presumably ad networks want efficient ads that show promptly? So why would they invent a weird and inefficient format?
A single file with base64 encoded images is actually an unusual format and as far as I'm aware not needed anywhere else in the industry outside of ads. Every single other platform uses separate asset files, including some ad platforms that now accept zips. It's unclear why this single-file format is even needed - why can't they just have normal separate asset files? By the zip format I mean a zip of web assets, with separate HTML, CSS, JS and image files. This is the only format it's easy for us to support, and if supporting an unusual format with extreme restrictions ends up causing major problems or otherwise holding back improvements to Construct for all customers, that would be untenable and so we'd rather drop support for the single file format in that case. We are doing our best to forewarn people of a possible outcome, so people can advise the ad networks of the change they want, and any ad networks that can be upgraded to support a much better format can do so ahead of time.
These are beta releases. Their purpose is for testing and they will always have issues like this coming up occasionally. If you'd prefer to avoid this, stick to stable releases.
This article covers a range of possible problems and there isn't one release that you can always go back to. It depends on which version the project was last saved in and what type of invalid names the project uses.
I think it is indeed better off in the main manual - it's now moved to here.
This is nothing to do with the Addon SDK v2 - the situation here does not involve addons at all, and I think it's unhelpful to try to bring it up where it's not relevant. Projects using valid names are entirely unaffected by this, which we believe is the vast majority of projects. Projects using invalid names were already broken in certain ways, such as being unable to save folder projects; trying to frame this as us breaking people's projects is also unhelpful. Even though we suspect there are few affected projects, we are taking steps to comprehensively document the changes and help people update their projects - I don't think anyone can reasonably claim that means we have "no regard" for them.
See this forum thread: construct.net/en/forum/construct-3/general-discussion-7/new-admob-sdk-20-x-deprecated-182891
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.