WackyToaster's Forum Posts

    I actually like the idea. Set vectorY does not give you jumpsustain. Simulate jump doesn't work off the ground. Doublejump is doublejump.

  • What about classes though? I don't think there's a problem with classes, they should work fine for that purpose. 

    class Weapon {
 constructor(whatever) {
 this.x = 25;
 this.y = 5;
 this.whatever = whatever;

 }
}

var object = new Weapon("whatever")

  • Remove the key once you selected it. On the next round you just have to fill back all the data (e.g. load from json) or use a copy of the dictionary.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Quite simple: System > Is in preview

  • It is a possible risk but I'm pretty sure apple really doesn't care.

  • I think you can do that with system > evaluate expression. Or worst case put logic like that in javascript.

  • What do you mean? Virtualbox runs on your own pc. Nobody has access to your data.

  • I have done this before and you CAN do it relatively easy with a virtual machine.

    virtualbox.org

    You just have to... "find" an up to date mac ISO file and set the virtual machine up. Give it some good amount of RAM unless you want to work with a slideshow.

  • There's a lot to unpack there. First of all, you do know you can rename your sprites, right? Because otherwise you are gonna get really confused soon about what sprite is what :)

    As for the pathfinding, here's a very basic setup that does the trick. You probably want to put the "wandering around" pathfinding into a function. You also probably should avoid to "find path" every tick. You should also know that pathfinding will fail sporadically when the target point happens to be inside a wall, that's why there is the "failed to find path" condition.

  • Are you sure you shared the right project? There's no enemy or ai in it.

  • Being able to cap/uncap fps has been a little bit overdue imo. Right now we have 60 fps vsynced or 7000 fps maximum overdrive, no inbetween and no "underclocking". I'm not sure if that's really related to the issue you are having tho.

  • If it's only slow in debug mode I wouldn't worry, since it's most likely a chrome bug (that is currently worked on). If it happens without the debugger, you are probably checking to many objects for overlaps or similar every tick.

  • The physics behavior has the option to enable/disable collisions with object types. This however (sadly) cannot be done per instance.

    One way of doing it would be to entirely disable physics for all objects on the lower layer (which does work per instance). You can pick these objects with the "pick objects by comparison" and pick all objects that are on the same layer as the ball. This will not work if you plan on having multiple balls on different layers at the same time.

    I cannot go more specific than this since I do not know how you set everything up, but this should give you a general idea.

  • Here's another solution that doesn't need any counting. Just a family, so it's potentially limited if you need to create a variety of objects.

  • Bad optimization

    Memory leak

    These are my guesses. Instead of guessing you should try and debug your app. Haven't touched this in years so I don't remember the specifics on how to do it but you'll install a debug apk, connect your phone to your pc, and check logcat in android studio.

    developer.android.com/studio/debug/am-logcat