oosyrag's Forum Posts

  • You can load array on message received.

  • How about this:

    You (The Scirra team) make a list of ideas that could be implemented, and let us vote on those?

    This was addressed in Ashley's last post...

  • If you did not file a bug report at github.com/Scirra/Construct-3-bugs, following the guidelines, then no it is not on the list.

  • Spotted a Nepeo out in the wild and figured a ping might be appropriate to call attention to this. Would it be possible for you to provide the algorithms you used to generate cellular and voronoi noise? Or at least how you generated the original random distribution of points for the noise, which the rest of the noise can be calculated according to. The goal would be to get the node, vertex, and edge data if possible.

  • I think it's not so much black and white as accepted or denied.

    For my own projects I have more ideas that I would love to implement than I have the ability to do so. Add outside suggestions onto that... And with the immense volume of suggestions possible from the interwebs, all the time spent triaging suggestions is time not spent implementing them.

    Even if I see an amazing suggestion/idea I didn't have before, I don't know how long it will take or how feasible it is to complete in a reasonable amount of time (especially for the more involved, big suggestions - the ones that have a lot of popularity). I wouldn't want to promise something that I wasn't ready to deliver on.

    Same for denied. If I love the idea, but I'm not going to do it ahead of everything else I'm doing at the moment, I wouldn't want to straight up deny it. Also if it can gain traction and more and more people down the road are interested in it, I'd want to leave it there for that possibility and not just say denied.

    The idea of promising something I am (or not) ready to deliver is related to disclosing what is actively being developed, which can actually be seen pretty clearly in the betas. Often there are many things being worked on a time, which may gain or lose priority, but if something like the 3d object is ready to be committed to, it will show up in a beta. And if it's in the beta, that's prooooobably what they are working on right now to get it ready for release.

  • If it really bothers you and you still want to try getting it changed, I would describe the bug, or unexpected behavior, as: When dragging to relocate multiple events, sub events are no longer selected upon dropping.

    This could be considered inconsistent behavior with the fact that when dragging multiple events at the same level, they all remain selected upon dropping.

    It doesn't seem like an intentional design to me, so it could very well be a bug. Or it could be a specific workaround for another issue.

  • Here's the thing, your actions are different in either case. If you don't collapse the group (not necessary), you can see it clearly.

    Clicking an event (or group) selects the event and its sub events.

    Dragging an event will leave only the dragged event selected.

    This doesn't have anything to do with groups in particular, nor top level or sub level events. It will happen if you drag anywhere, from top level to sub or vice versa, and it happens with sub events as well.

    If you drag a group to the top level, then click it, it will select all sub events as well.

  • Set a global variable upon reaching a checkpoint.

    On start of layout, check if global variable is set. If it is, position the player object accordingly.

    Use Local Storage to persist across play sessions.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hundreds of objects should not be an issue. With the perftest, my phone only starts losing frames at 100,000 objects and my computer at 150,000. And that's just from max frames per second, it probably wouldn't even be noticeable until significantly more.

    You should definitely isolate your events in scope though, there's no reason for any events to not filter out only the things they should be affecting.

    On that note, even creating/destroying hundreds of objects at the same time normally wouldn't cause any noticeable lag, so there was probably something else acting on it in that case as well.

  • While I'm not familiar with the tutorial you linked and I don't plan on spending hours watching it, I assume the swing speed of a sine based grapple would be based on the period, not the magnitude, which determines how far/wide the swing is.

    Granted if you've been using a constant period, then a larger magnitude will be faster as it has to cover more distance in the same amount of time. Anyways, wouldn't it make more sense to adjust the period based on your starting velocity instead? Then you wouldn't have to fiddle with the cycle start position either, which I'm guessing works fine if you follow the tutorial.

  • Use whatever size of tile of the tileset you like the look of and want to utilize.

    If you're creating your own assets, same idea. Are you happy with the look of what you can fit into 8 pixels, 16 pixels, 32 pixels, or whatever?

    Scaling doesn't really have anything to do with performance. What is worth considering is your total VRAM usage - higher resolution assets will use more VRAM, limiting the total amount of assets you can have in a single layout. It's still a huge amount available though, so you probably won't have to worry about that unless you're making a humongous game. Even then, you can use multiple layouts to manage your memory.

  • Your issue is not diagnosable with the information you have given. Try uploading a minimal project with only the problem.

  • You could just make your inventory layer invisible and add conditions to disable relevant events when it is not visible.

  • Modern desktops with dedicated GPU's generally have have 4-8 GB of vram. Mobile devices don't have dedicated VRAM, but I'd say they generally also have 2-4 GB avavilable. If you don't go nuts with huge levels with thousands of unique sprites, or giant sprites that span areas larger than your viewport regularly, you're going to be fine. Long animations can also be a source of heavy VRAM usage.

    If you see your estimated VRAM usage going up over 1GB, then you might want to reconsider your approach and think about optimizing.