R0J0hound's Recent Forum Activity

  • worm1

    This doesn't really work with any other behaviors. Motion should be done with the set isometric position actions. The example capx show some ideas how to do this. You'd basically be creating the behavior with events but this provides some useful things to make that easier.

    Actually using some other behavior to do the motion could possibly be done by using a separate object and setting isometric position with that, but eh, it's simpler to just do it with events than to wrangle something to do something it wasn't designed for.

  • No problem

  • Why don't you want to use "move at angle"?

    You can do it with:

    Set X to self.x + dist*cos(angle(self.x,self.y,door.x,door.y))

    Set y to self.y + dist*sin(angle(self.x,self.y,door.x,door.y))

    Where dist is however far you want to move.

    You can use 100*dt if you want it to move 100 pixels per second.

  • You're probably better off just duplicating obstacles off screen to handle that.

  • Use a separate identical sprite that you position manually.

    So say the screen width is 640

    player.x < 320

    --- clone: set position to (player.y, player.x+640)

    else

    --- clone: set position to (player.y, player.x-640)

  • YoHoho

    A simple way to do multiple would be to clone the band object, duplicate the events and change the old band of the new with replace.

    The length and location of the band is hard coded into the events. You'd have to change the positions of the bands, change the event that resets the band's angle and length when no can is on it (event 1), and change the event that sees if the can is on the band (three conditions on event 3).

    To appear and disappear it's probably as simple as destroying and creating the bands, and setting the length and position from what can be figured out with the previous question.

    Overall the capx wasn't really designed for a lot of that so it would have to be reworked. Maybe understanding what is done would be useful in making something that makes everything easier.

    basically it just checks if the can is between and below two points. When the can first falls in that area then the distance from the can to the the two ends is measured, this is the rest length of the two halfs of the band. Than after that both halves apply a force to the can. It's a spring force and both are calculated with F=-k*(length-rest_length) for each band half. We then apply those forces in direction to the endpoints and that's what moves the can. The spinning and slipping along the band are more of a fuzzy thing. The capx condenses that stuff and also using the band sprites as a visualization.

    Anyways a fixed capx or a redesigned one that supports what you want to do more easily is left to someone else to do. I won't get around to it.

  • mikehive

    If the events are the same and the image points are placed in a clockwise order in the sprites then it should work.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • orangpelupa

    link updated

  • As stated elsewhere spriter, spine or any other third party plugin that draws is waiting on this issue as far as i know.

    https://github.com/Scirra/Construct-3-bugs/issues/510

  • 100x100 x 30x30 x8 is 72Mb

    100x100x 100x100 x8 is 800Mb

    Saving it to disk as json will be quite a bit larger since each number no longer only takes 8byte but usually more depending on the number.

    But idk. you can always generate less than a row in an array at a time. Still i only have a vague idea of what's going on. Good luck with the project.

  • Sounds like a logic issue. It shouldn't get progressively slower and use more and more ram. It should stay constant.

    100x100x25x25 is nothing.

  • It doesn't sound like an absurd amount of data. As you sure reading each pixel of the 100x100 image isn't the issue? That's a slow action.

    Javascript can be a much faster at running but you lose the ease of interacting with the rest of C2. I wouldn't recommend it. Using just javascript with some other game library and not use c2 at all would be simpler i think.

    Anyways, if doing everything all at once locks up the browser you could redo your logic to do the generation over multiple ticks instead of all at once.

    so instead of this:

    start of layout

    array: for each xy

    --- do something

    you could do something like this:

    global number y=0

    y<array.height

    --- for "x" from 0 to array.width-1

    ------ do something

    --- add 1 to y