Ashley's Forum Posts

  • This is by design. The runtime saves the layer using a unique ID rather than its name or index, so that if you rename or move the layer, it can still correctly load a savegame or restore the state of a saved instance. The unique ID identifies a specific layer on a specific layout. Therefore if you change layout, that specific layer is not available, so it defaults to layer 0.

    You could work around this by storing its layer index in an instance variable.

  • Can't reproduce here. The layers bar scrolls with the mouse wheel just fine. I'm on Windows 10 64-bit too.

  • Closing, see the bug report requirements.

  • Can't reproduce here - everything looks just fine in the Layout View, but I'm not sure what it looks like when it's not working. I suspect it's a graphics driver bug. Yes, the latest drivers can still be buggy.

  • The blog post I wrote around 2 years ago on the case against native engines is still pretty relevant. For us, for the foreseeable future, going to multiple codebases would do more harm than good. For example say goodbye to regular releases as all our engineering time is sucked in to huge porting projects to multiple platforms.

    HTML5 is definitely a viable platform for games - all the games built with C2 and C3 prove that, and it's even more the case with technologies like WebAssembly, WebGL 2 and (in future) WebGPU. If the console manufacturers don't recognise that yet, then I think they're behind the times. Remember though that Microsoft have seen what's possible - you can already build and publish Xbox One games using Construct! It's only Sony and Nintendo who are behind the curve on this.

    There is also a third-party console porting service with Chowdren, so that's an option, although it's entirely independent of Scirra so I can't comment much further on it.

  • Yes. It can do so, so much more, too. Take a look at the Features page!

  • We'd upgrade to C3 but there are so many facets of this thing that I imagine are unsupported right now that it could be a mess.

    Have you actually tried?

    BTW I'm away next week, so I'm afraid I won't be responding any further to this until the week beginning June 18th.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yes, this will be fixed in the next beta of C2. To work around it I think you can just change that line to the following after export:

    useOgg = false;

  • Well I think this is more of a feature request to add a properly supported feature to load external audio files. At the moment you're using the "load a project file by name" action which somehow works with a file path in NW.js mode; that's not something that's officially supported right now.

  • Closing, please see the bug report requirements for posting in this forum. If you are just asking for help please use another forum.

  • It should be supported soon, but I do not think you should be publishing anything important with the C3 runtime at this stage. It's still very early on in development so there could be a number of unexpected issues, and downgrading back to the C2 runtime can be complicated.

  • Facebook appear to be moving their games platform to Instant Games. Use the Instant Games plugin to integrate with it.

  • The Audio plugin was not designed to play external sounds at all. I had no idea that the "Play (by name)" action would even work like that if you passed it an external path, so this is, at least at the moment, a totally unsupported case that only works by accident. So I'm not surprised that there would be issues if you use it like that.

    Why do you need to play audio files externally like that? Why not just add them to the project? That is a supported way of playing audio and so the memory management should work correctly.

  • When you say it's an NW.js memory leak, is that because you tested Chrome and it did not reproduce there?

  • As newt pointed out this is not possible in the general case: when you use an expression, the editor cannot know to update the name automatically. Therefore you have you go and check all the events anyway to update any such references.

    Additionally layers are even more difficult since you can share event sheets across layouts, and the layouts can use layers with the same name. So then if you rename just one of the layout's layers, should it rename references to that layer name in the events, or not? It's not clear which layer the event really refers to. So it can't update it, so again you have to go and check all the events anyway.

    C3 provides a "Find all references" feature to make it easy to find all the events that are certain or possible references, so you can easily review them and update them if necessary. That's probably all the editor can do to help you, since as mentioned automatically updating them is impossible in the general case.

    Closing as I don't think this can be solved better than C3 does, and it's a feature request anyway.