Oh hey, so it does. Managed to miss that in the system actions because I was searching for "window", but yeah, the description for that even says "Set the size of the canvas (also altering the 'Window size' project property)", so that should sort it out. Then there's just the matters of exposing game scale control to events as well as the vsync division for framerate capping. First one is something that you could technically work around with in events already (by manually controlling scaling for all layers through events), but the latter is something that would require changes to C2 runtime itself (ping Ashley).

A two-part question (or more of a feature request, really) related to providing performance-related graphics options to users.

First part relates to fullscreen scaling. Right now C2 provides the option to use low or high quality scaling, but it would be nice to have more granularity in this regard. Basically what I'd like to do is control the rendering resolution for low quality mode, so that you could provide more options between Window Size and Screen Size. One way this could be achieved is if you could simply adjust the Window Size project property on the fly with events (EDIT: already possible with the System: Set canvas size action, my bad) - then you could combine it with the LQ fullscreen mode to achieve the desired effect (you could for example make an "Internal rendering resolution" slider in your options similar to what eg. DOOM 2016 offers). Although for ease of use it would be nice if C2 also provided an option "one level up" from layout scale to game scale, which would scale even layers set to scale rate 0. Considering that C2 already uses this kind of scaling for fullscreen mode to begin with, it would be nice to be able to adjust it on the fly with events as well. It would also make rolling your own aspect ratio and resolution handling through the "Fullscreen in browser - Crop" option easier as a bonus.

Second part is about framerates. For mobile games and lower-end hardware it would be desirable to provide eg. a option to run the game at capped vsynced 30FPS (ie. running at "half" vsync for 60Hz displays). I managed to find this thread from last year on the subject, but reading through the Chrome issue nothing seems to have gotten done on the browser side yet. However, there is a potential workaround. C2 uses requestAnimationFrame internally, right? So for 30FPS, it could simply run its updates on every other rAF call to achieve constant 30FPS on 60Hz screens. I tested this out with a webapp of my own and it worked as expected. This kind of vsync division (a potential C2 project property could be just that - an integer for vsync division - 1 updates game on every rAF call, 2 updates on every other, etc) could also be useful for all those 120Hz/144Hz displays out there to allow for better control over game performance for the end-users.

rexrainbow

An update notification tool for third-party plugins is especially the kind of thing that you should have semantic versioning for. The current system "works" because you have to download and install things manually. Semantic versioning will be more and more important as installing and managing plugins becomes smoother. You don't necessarily want to always update if a new version is available - what if said new version of a plugin is a major redo of the way it works and is used? With no established versioning semantics, this could be a jump from version 1.3 to 1.4. Poor is the chap who decides to upgrade said plugin for a project that heavily relies on the way it currently works in 1.3, only to find out that most of the functionality is deprecated and he/she should redo it to be safe (since no new code with the old deprecated ACEs could be done).

With semantic versioning, this kind of jump would require bumping the major revision number, and any update tool could instantly tell that "yeah, you probably don't want to update that plugin or something's gonna break." Incidentally, this is also why project-specific plugins should really be a thing - so you could have multiple versions of plugins with no issues! Again, I point to Node.js and npm - this is practically a completely solved problem over there, and semantic versioning is a big part of it.

It's nice that being logged in makes the site default to HTTPS for most things, but there's an unfortunately large number of pages that still get served over HTTP, like any section using the old site layout, and curiously the "Create New Topic" page is also served over HTTP.

If you want to keep your user's cookies secure, it's really a binary thing - either everything is served over HTTPS when you're logged in, or the cookies aren't really secure. It would be nice to see this addressed.

As a sidenote, the website field in the profile editor is prefixed to always use http:// - it'd be nice if you this could made part of the field itself. To avoid any linking issues, you could simply stick http:// in front if someone were to forget to include the protocol.

It's a good idea, but I don't think it's really necessary right now.

I'd say that's a very good reason to start supporting them now / as soon as possible. As I mentioned, the transition could be made very painless: Simply treat existing version numbers like X.Y as 0.X.Y. This way the old version numbers would basically always be treated as earlier versions in comparison to semantic version numbers. The old version numbers would be easy to support for a long time, all the while encouraging existing and new addons developers to use semantic versioning.

This would lay a solid foundation for further developments in addon management - it'd be much easier to do the "official" switch now on its own rather than doing it at the same time with some other potentially much larger changes. Not to mention that semantic versioning is simply a good development practice in general, and encouraging people to use is only going to be beneficial.

So I've been dealing with the SDK for a project I'm working on, and something caught my eye. Namely, the versioning:

b]version

This is a float in the format x.y which identifies the version of your plugin. [emphasis added] You should keep this updated whenever you make a new release. Construct 2 uses it to verify projects are compatible when opening. For example, Construct 2 will show a warning if a project was saved with version 2 of a plugin, but is opened with version 1 of the plugin installed.

Using a float is not exactly a great system for versioning. You could consider it as a major.minor scheme, but if compared as a float you can easily lock yourself into having to do new major revisions every 10 updates if you limit yourself to a single decimal (1.8, 1.9, uh oh, 2.0), or at some point if you don't want to increase the major version number you'd end up doing version numbers like 1.992 or so. Not exactly ideal.

As such, I'd like to suggest that Construct 2 switches to semantic versioning for addons. It would remove the pitfalls mentioned earlier, and also bring, well, semantics, to addon versioning. For example:

• Addon Version 0.X.X means that the public API (in Construct 2's case, ACEs and parameters) is still potentially changing in compatibility-breaking ways, and should be used in production with care.
• Addon Version 1.X.X and onwards would have solidified the public API. Any notable changes that break backwards compatibility would warrant a bump in the major version (to 2.X.X and onwards).
• New features that do not break backwards compatibility would bump the minor revision number.

For example: 1.0.0 -> 1.1.0

• Bug fixes and other patches that do not change functionality would simply bump the patch number.

For example: 0.5.12 -> 0.5.13

• Version numbers could go above 9 in each category without breaking parsing (which you can't do with floats - 0.9 would be treated bigger than 0.10 and 0.11, so you'd have to do 0.9 -> 0.91).

And probably the biggest thing: Semantic versioning makes dependency management actually feasible. If your project uses Addon version 1.2.23, then the project should keep working perfectly fine with Addon version 1.X.X, as long as the exact version is above or equal to the one that was used. Construct 2's addon system will hopefully evolve to have project-specific (local) addons eventually, along with a proper addon management system, and semantic versioning would be the solid foundation to build such a system on.

Transitioning to semantic versioning should not be hard either. Existing version numbers in the format X.Y could simply be treated as 0.X.Y until the plugin authors update to actual semantic version numbers.

(As for implementing semantic version parsing in C2, for inspiration here's the semver module that npm, the Node.js package manager, uses. Also, as a sidenote, package management in Node with npm is absolutely fantastic, so following suit with what has been done there most certainly wouldn't hurt.)

Hello, I'd like to bring some attention to this bug that has seen no activity in almost two years.

Basically you can't disable/enable the shadowcaster behavior during runtime. Considering that it's pretty much the heaviest feature in our game at the moment it'd be pretty nice to be able to optimize the engine by doing selective shadowcaster disabling/enabling on the fly.

Ok, plenty of food for thought.

While I try some of the suggestions, here's the most basic way I could find of making the "Not Responding" message happen using 2 nested loops, with minimum reading and writing to an array.

http://www.smileydesign.co.uk/FreezeMe.cap

How would you go about stopping that from freezing?

Krush.

The simplest way would be to split the x over 100 ticks, like this:

http://dl.dropbox.com/u/326175/freezemeunfreezed.cap

An unfortunate side effect is the set volume action will only affect the most recently created instance of the sound.

No, it's not just that. Set volume for sounds simply doesn't work at all. Try out a code like this:

+ System: Start of layout
-> Audiere: Load Sound ("sample1.wav") as "sfx" (Play now: Yes, Volume: 100)
+ System: Every 100 milliseconds
-> Audiere: Set Volume of sound "sfx" to Audiere.GetSoundVolume("sfx")-5[/code:2toxfxj5]
The sample just keeps playing at volume 100 for the whole time.

Also, even if it worked, with a limitation like that (only being able to set the volume of the latest instance) it makes the whole thing pretty useless for my purposes (creating dynamic ambient soundscapes). Guess I'll have to resort to using the music actions for everything.

Is there any difference between using the Music actions and Sound actions? Because sound actions are lacking the option to repeat sounds plus "Set volume" doesn't seem to work for sounds.

As the title says, the Light object is currently as of Construct Classic r1.2 missing actions for setting the width & height in events, which is quite damn baffling. It'd be pretty important to get something like this working as soon as possible.

EDIT: In other Light-related news, this bug that I reported over a year ago still exists... which makes me pretty sad since it hinders the usability of the Light object tremendously. You practically can't do anything dynamic with them.

> I read somewhere that Konjak tried getting one of his games on there, but they didn't go for it simply because it was made with MMF2. So, um. Nevermind

>

Isn't Nifflas' Saira made with MMF2 too? I've been under that assumption.

Indeed it was. Besides, there are also games made with Adventure Game Studio available on Steam. In other words, whatever tool you make your game with shouldn't be a limiting factor in regards to getting your game on Steam provided that your game is good.

> and thats pretty racist if you ask me, what if a game is made with an instrument? when the game is great and competitve with other indie games?

>

Hardly racist. It's easy to think that an indie developer wouldn't have the resources to provide localisation and support to meet the platform standards. It's not like you can just throw Valve an exe and expect to see the money flow.

It's not like Steam requires any localization from games, though. Indie developers surely aren't expected to do that. Neither do they really require the developers to give any more support to their game than they normally would, though I guess one could expect more support requests due to having more visibility thanks to Steam, but I don't think the developers would mind that at all.