Ashley's Forum Posts

  • The standard console logging with the Browser object should show up there too.

  • It's only available with a folder project saved in Chrome.

  • The way events work is pretty significantly different from JavaScript coding, and the typical patterns you'll use to get things done are different. So it's best not to try and think of questions like "how do I make this event in script", it's better to change your perspective to "how do I do what I need to do with JavaScript coding". For example often picking by UID is used when calling functions in events in order to pass an instance, but you should not do this in JavaScript, because you can pass an instance directly. This makes the question "how do I pick by UID?" redundant and basically wrong to ask, so (as is pretty much always the case with help anyway) it's best to focus on your goal and how to get there, not some random details.

    I must strongly discourage you from looking at the C2 runtime code. Much of it is nearly 10 years old and you can generally do much better with modern JS features. For example you pointed out some code that is far more suitable for a Map, and the only reason the C2 runtime doesn't do that, is because it didn't exist when it was first written.

  • Actually I was wrong, the current plan is outlined here: https://www.construct.net/en/forum/construct-3/general-discussion-7/construct-nw-js-desktop-app-131317/page-15#forumPost998032

    In short the NW.js desktop download is being kept so you can use it for NW.js testing, but that's all. All other features will be aligned to what you get in the Chrome browser.

  • Stop. It should stop. Like a person hitting a brick wall.

    I don't understand. This means the "push" object still runs in to it, so it still ends up overlapping a solid. From the engine's point of view, that is the same as being stuck in the wall. So there is no solution.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • But the "push" object is solid too. So if the player doesn't go in to the solid wall, it goes in to the solid "push" object. So it still goes in to a solid, just a different one.

    What else can it do?

  • No, it's exactly the thing I explained in my previous post.

  • Open source the Construct project file. Then everything works out just fine.

  • Construct's memory management works entirely by the objects placed in a layout.

    When you go to a different layout, Construct will unload everything not placed on the next layout. If you then create the same object in 'On start of layout', it will unload it when changing layout, then immediately load it again in 'On start of layout'. Obviously this is inefficient.

    Even with this change it is still preferable to have everything placed on layouts, so Construct's memory management works well. The change about loading in 'On start of layout' merely avoids drawing a few frames of the game without a newly created object being loaded.

  • Construct's code is not open source.

    You cannot redistribute Construct's code under an open source license, because it is not your code and you don't have permission to do that.

    You can open source your Construct project file, though. This is what "open source" means to most people working on a Construct project.

    That is the end of the story. There is no way around this. There is no point trying to argue around this using different formats or export options. Construct's code is not open source and cannot be distributed as such.

  • No, they can't. In practice it is not human editable. The project data is mostly held in a large block of JSON data in a deliberately obfuscated and minimised way.

  • I realised with the improved code in the C3 runtime, it's actually straightforward to make the memory management wait for objects created in 'On start of layout' to finish loading their textures before drawing anything. This is less efficient than the normal preload since it's a second step that does not run in parallel to the main loading, but it does mean that anything created in 'On start of layout' is guaranteed to be loaded on the first frame drawn. That should make it easier to manage this type of case. But note there are other reasons to place all the objects a layout will use on that layout - in particular the editor uses knowledge of which objects are placed on layouts together to optimise the arrangements of images on spritesheets and minimise memory use, so it's still a good idea to do that anyway.

  • I don't see how "On before layout loads" helps. The way it works now, if you create an object there it would work identically to how it does now, because it still hasn't pre-loaded the object. You might want to take a look at the system memory management actions.

  • The NW.js export option is not being retired. Only the desktop download of the C3 editor is.