R0J0hound's Recent Forum Activity

  • I don't a lot of time either. I guess I'm confused with what you want to do. Do you want to re-arrange the units to be in a different formation? Like go from a 5x5 to a 4x7?

    I guess you could pick only the units that need to move like you might be trying to do? A simper way would be just to reassign all of them:

    global number x=6

    global number y=5

    For each unit

    --- unit: set col= loopindex%x

    --- unit: set row=int(loopinde/x)

  • Ah, so I guess families don't work then. Well they do partially but they're setup differently so we get that object is no callable error. Basically it's some issues with the runtimes source itself, and let's say I'm purposely avoiding going that route to avoid a myriad of errors because compiling with a different compiler introduces too many issues. Most of which I was never able to solve.

    So I guess just listing all the object types would work though, barring any other gotchas.

    It's quite the Pandora's box. The work needed to work around stuff or even trying to fix the source itself quickly seems to exceed re-writing something from scratch...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • More layers I guess. I'd recommend using the paster object to help with this. You can draw to them so you can probably draw one color light to one paster and another color light to the other then blend the two together somehow.

  • Hmm, I don't know why it does that. I really don't enjoy diving into javascript to debug something I didn't write.

    You could probably do something else, maybe with just the physics behavior? Either by modeling how the car physics really works or fake it somehow. What i'd do is make a list of things I want to do and figure them out. If any are too complex, I'd break them down further till I just have a bunch of simple things I can do that I piece back together.

  • Yeah, the python errors are kind of obscure in Construct, for one the line numbers are way off. That "NoneType' object is not callable" usually means that object doesn't exist.

    The function is not iterable error and probably some others could be if the object names conflict with the python names.

    A cap could help me knock out a few of the bugs. I'll have time tomorrow.

    That last major problem intrigues me, probably some issues with my load function.

  • I'll have to work with it more. There are probably some typos and bugs I still need to work out. It should work with families as is, they just don't show up in the editor.

    I'm not by the code currently but I'm curious how that index error can happen. As long as the objects are just sprites and tiledbackgrounds it should work. I'll see if I can add more error checking to give more readable errors. If you need other objects to be saved I can tweak it I think.

    As far as accessing the tiledbg variables, there is a solution, but it would require some Python files to be included with your game. Basically it would access the memory directly. It could also solve the issue of accessing the collision mode.

  • You can use the "linear damping" property to make the gems more floaty, also you can improve the bounce by giving the walls an elasticity of 1.0 as well so bouncing won't lose speed. You could also tweak the gravity as well. Making the gems have a circle collision could make the bounces less jarring. One last thing I noted is the gem would be attracted toward the player, which you can do by applying some forces.

  • But what you replied with is math too, and actually it's basically the the same as what I referenced.

    Velocity is a vector. Or basically it has a x and y value. The magnitude of a vector is it's length which can be calculated with the Pythagorean theorem:

    sqrt(sprite.physics.velocityX^2 + sprite.physics.velocityY^2)

    Or just use the distance expression, which does the same thing:

    distance(0, 0, sprite.physics.velocityX, sprite.physics.velocityY)

    In your example the "sqr" means the value is squared so that would be this:

    sprite.physics.velocityX^2 + sprite.physics.velocityY^2

    or this

    distance(0, 0, sprite.physics.velocityX, sprite.physics.velocityY)^2

    just repace "obj.velocity.sqrmagnitude" with one of those.

  • I guess it could happen if it doesn't close correctly. So after closing them all, if you re-open your game and close it are there any still running?

    If stuff is being left behind after one run then that's bad and good. The bad is self evident. The good is it's repeatable, so it should be quicker for nw.js to fix I suppose.

  • The last code block above should work for that by changing the center variables.

    If you like you can poke around my capx I made to try it out. I got a little carried away but it might give some ideas.

    https://dl.dropboxusercontent.com/u/542 ... ation.capx

  • Chrome and in turn nw.js like to run in multiple instances like that. If the instances are still running after closing you game then that's a problem, but if they all close too I guess it is normal.

  • Maybe try this behavior:

    The normal car behavior doesn't play well with physics