Ashley's Forum Posts

  • This bug makes very little sense to me. The Steam version of C2 is for all intents and purposes identical to the standalone version. The sole difference is that it doesn't read a license from c2license.txt like the standalone version, it communicates with Steam. It seems unlikely this relatively trivial change could cause such a serious degradation of performance over time. Further, the autosave system is certainly identical between the Steam and standalone versions of C2, so I am at a loss as to what the problem could be. I presume it must be something about the Steam client or the way it launches C2. Further still, as far as I know most Steam users use it successfully without this type of issue, so it seems unlikely that we could reproduce it (and I never have).

    I think Steam does some things to the programs it launches. It's designed for games and the "in-game Steam overlay" is enabled by default. Turning that off is almost certainly a good idea since it's designed for games and might just be incompatible with C2. I think it does some other things though, like at least timing how long it's running for play time stats, and possibly other behind-the-scenes alterations. I have no idea what any of these things could be, what to do about them, or how they could interact with autosave to cause any problems. (Autosave is basically a lightly modified version of the 'Save' button that just directs the result to a different file. If the problem does not reproduce by clicking 'Save', then I am pretty sure it really is just a random problem that only interacts with autosave by chance, rather than actually being anything specific to autosave).

    The symptoms sound something like a memory leak, but from the numbers you have reported, there is no corresponding increase in CPU or memory. I'd expect either the CPU usage would keep increasing (such as having to process a longer and longer list every frame), or memory usage keeps increasing (exhausting memory, caches and falling back to disk). Either would explain degrading performance, but neither seems to be the case. So no leads there either.

    I'd email Valve but they rarely email me back. These days they have thousands and thousands of developers using the store, and their focus is probably on their AAA games.

    If you are happy to work around it by disabling autosave, then that is OK I guess, but I feel like it's probably a random issue that may still happen in other ways. If you absolutely cannot use the product at all, then unfortunately we can't issue a refund, since all Steam purchases are processed by Valve - your only course of action would be to obtain a refund for Construct 2 from Steam and purchase again directly from our site.

  • You're both right, the manual entry actually contradicted this. I've updated the manual to note amplification is not supported.

  • Should be fixed in the next build.

  • Note your .capx URL is incomplete.

    This is occasionally reported, but it is a bug in Windows itself. Each process can only create up to 10,000 graphics objects, which is a limitation in Windows since the 16-bit days and has never been lifted. I am amazed that anyone would actually run in to this limit; I've no idea how you could need so many frames, and anyway this seems contrary to our advice on conserving memory.

    Anyway there's not much we can do about this in C2, but C3 is being architected with this limit in mind. Exporting your project is a slower way to test, but the spritesheeting on export usually brings the image count back under the limit. If another browser works then you can always test with that as well, I guess maybe Firefox have their own graphics engine that doesn't depend on the OS and can go further.

  • Closing as by design. As per the Web Audio API you cannot amplify audio, only attenuate it. Given that much digital audio content is already normalised (reaching to peak level), allowing amplification would probably be something of an anti-feature anyway, since even slight amplification would immediately cause clipping and distort the audio. Certainly amplification as high as +50 would cause such severe clipping as to probably render the original sound unrecognisable.

  • Closing, please see the bug report guidelines, or report this to wacom if there is an intermittent issue with your mouse/hardware.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Closing as won't fix. The platform behavior is designed for the player, and one of its features is to support moving platforms. So when the bottom object moves it is treated as a moving platform, and the objects on top of it move with it. So actually it is working correctly.

  • Closing as can't reproduce: it works correctly in Firefox Nightly here. As per the previous report it seems to be a Firefox bug, and one workaround is to create a new Firefox profile.

  • Closing, please see the bug report requirements.

  • 1. Under some circumstances the host (or signalling server) may not notice immediately that a peer has become disconnected, but on both ends it should time out after about 20 seconds if they cannot communicate. It's not clear from this report if you have checked if this is happening; I assume the timeout mechanism does work correctly, otherwise the signalling server would clog up with zombie peers, and I can see it is not.

    2. I'm not clear what you mean by this: if you get disconnected then the multiplayer engine should time out all peers as it realises it can't communicate with anyone. It may or may not destroy your own player depending on your own events. I am also confused as to how you appear to report that the bug is objects are not destroyed, when your "attach a capx" instructions indicate to change the game to not destroy objects, which makes it sound like it is simply a consequence of that change.

  • Should be fixed in the next build.

  • Closing, please see the bug report requirements.

  • Closing as by design.

  • Closing as won't fix: this is just weirdness in the Windows shell. Similar problems can happen if you create a folder with a dot at the end of the name, which has affected the C2 editor itself in the past. It's not a C2 or NW bug, it's Windows! If we modify filenames before acting on them that probably just opens another can of worms, so I think we will leave it up to you to make sure all file and foldernames are valid, as all Windows developers have to.

  • The only issue I can reproduce is if you leave any of the project ID, version, author or description fields empty, these get left empty in package.appxmanifest and cause VS2015 to say the file is invalid. In the next beta C2 now prompts for these to be filled in if exporting for Windows 10 which should prevent this happening. I believe all other issues are either just having the wrong components of VS2015 installed, or are otherwise unrelated, so please file separate issues for those if you still have trouble and are certain you have VS2015 installed correctly and have filled out the project ID, version, author and description fields.