DiegoM's Forum Posts

  • The Instances bar largely solves this.

    You can copy and paste an instance from it, or drag it into the layout to create a copy of it.

    Create sub folders to group the ones you know will be used frequently, that way you don't need to actually look for them in the layout.

  • In that case I don't think Construct is the right tool for the job. Web applications just don't lend themselves to that use case because you don't have control over what the underlaying browser wants to do with them.

  • I am not sure what you are trying to do, but most people that want something like what you are describing are usually interested in keeping some kind of simulation going, even when the game is closed.

    Games that do this keep track of the last known time they were active and then look at the new current time when the game becomes active again, with both numbers they calculate the difference.

    With that difference the game then simulates all the things that would have happened in that time, should it have been active.

    This is the correct way to approach the problem, because you can never know what the OS will decide is better for your application. This is particularly true for mobile devices where the OS will aggressively try to save battery power, and in most cases that means stopping any process which is deemed not useful, such as applications that are in the background and not being interacted with.

  • I don't have the precise numbers on this, but I think it is safe to assume most C3 users use it to make "closed" games, with any persistence a game might have handled by the browser's local storage, in a similar fashion older games used to work where the game has some save space but it can't really be shared.

    Currently C3 doesn't have any built in system to simplify working with databases, so anyone that wants to do that has to implement their own server.

  • Check the browser console for any errors regarding the request. Press F12 while the preview window has focus to bring up the browser's console.

    Make sure your server includes Access-Control-Allow-Origin: * among the response headers for any of the HTTP request methods (Ej. POST)

    Unless your C3 application and your server are in the same domain, the request from C3 will be cross origin and will be blocked by the browser, unless the server allows it of course.

  • It's likely that PHP is not so popular around here because most people that use Construct are interested in developing games without traditional coding. If you do see any talk about coding it will likely be Javascript and still in the context of the frontend.

    Having said that, if you already are familiar with PHP and MySQL, there shouldn't be any problem in using that for your backend stack, it's a reasonable choice.

    Despite being an absolute meme, PHP is a perfectly serviceable language!

  • Have you checked your Admob account? Maybe your application was flagged for some reason and is not being served ads. Nothing has changed on our side.

    As for preview showing ads... preview is pretty much the same as a web export, so it shows test ads as if the application was hosted on a website. They look very similar to a mobile exports ads, but are shown using a different library.

  • I can only guess what might the problem be because Admob doesn't really tell the developer anything when an ad is not served, so it's really hard to figure out anything at that point.

    Having said that, I don't know how often the ad requests are being made in your app, but Google Mobile Ads SDK (which takes care of the request under the hood) might just be ignoring them for iOS devices if it determines you are making too many.

    Try checking your Admob account for any hints about "limited ad serving" or something similar, maybe your app has been flagged for some reason and that's why not all requests get back an ad.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Try this:

    1. Remove the Wait from the top
    2. After creating each object set their Visibility to false
    3. After that add a Wait of "Some fixed value" * (loopindex + 1)
    4. After the Wait action, set the Visibility to true

    This should add a bunch of Wait actions each waiting more than the last. As the timers complete each instance will become visible, giving the illusion they are being created in a sequence instead of all at once.

    You can later change how the instances become visible so it is more interesting than them just becoming visible immediately.

  • Have you tried opening and closing your project in the latest beta? Just to verify if the problem still happens in that version.

    It is possible the problem has already been fixed. If it is fixed in the latest beta but you don't want to use beta versions, you will have to wait until the next stable release.

  • When you draw a tile, a model is created to represent it, it mainly has the position and the index of the tile. Those models are never actually deleted after creating them because it is infinitely easier to keep them around than figure out what needs to be recreated and with what information depending on what changes.

    Since the tile models don't hold any image data themselves they are rather lightweight memory wise. They could probably be made to be more compact if they where represented in some unorthodox way (thinking about storing all the information directly in an ArrayBuffer instead of a class so all the bits can be packed as neatly as possible and using static methods instead of class methods to reduce the memory footprint even further), I don't think it's worth the trouble though.

    When it comes to drawing, only the visible tiles are looked at, so that part is as efficient as it can be.

  • I think in the first snippet, the problem is a misunderstanding on how those events work.

    The mouse event is a trigger, so it is only executed when the left mouse button is clicked. So far so good...

    The following event is not a trigger, so it is executed every tick. That means that as soon as CanAttack is set to false the first time, the actions for CanAttack = false start executing every tick.

    So every tick you have this timer being setup to wait for 1 second and after that setting CanAttack to true.

    The problem with all of that is that by the time CanAttack is set to true the first time, a whole bunch of other Waits for 1 second actions have also been set up, and after each of those finishes, CanAttack will be set to true, making it seem the clicks are not setting CanAttack to false.

    If I understand correctly, to get the behaviour you want, you need to place all the actions in the Mouse trigger. That way CanAttack is set to false, then you wait for 1 second and after the wait is done you set CanAttack back to true. Because everything is in the trigger it will only happen when the mouse is clicked.

  • If you don't want to share your whole project, try removing as many things as you can from it, while still reproducing the problem.

    If you could share a trimmed down project, it would help a lot to solving this.

  • The crash suggests that there is a problem loading the state of a tween or a timeline. So maybe it has to do with a save being done while a tween or a timeline is playing and then there is a problem restoring that state.

    That might explain why it doesn't happen consistently... I am just guessing though, so the conditions that cause the crash might be different.

  • Can you share the project, and give steps to reproduce the problem?

    Without that it's very hard to figure these problems out.