R0J0hound's Forum Posts

  • Prominent

    Ah, that does make sense. I forgot about that.

    megatronx

    Doesn't Prominent's idea work?

  • If the mask is just a sprite, you could duplicate it for each layer and use blend modes. Just be sure the layer has "force own texture".

    The only other alternative would be to draw to a canvas or paster object for such grouping. I haven't been able to get the paster object to paste a layer at a time but the canvas plugin can, but doesn't use webgl. The flow would be to paste the two top layers first then paste the mask layer to a second canvas and then use a blendmode to paste to the first canvas.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I take it .def files are a format that M.U.G.E.N. uses. I can't find many details about the format other than it's a text file, so I assume it's human readable. If there's no existing tool to do it I suppose you could write one with python or something. Honestly I know nothing about it. It's out of the scope of things I'm interested in. But rest assured if you can get the images C2 can load them. However 500+ images may deplete your video memory, it just depends how big they are.

  • In short: visually sorting isometric objects is often a royal pain.

    If all the objects are roughly square and on the same ground level then the "for each ordered" way works well, but you need to be consistent where the origin point is on the sprites. A common solution is to use the bottom center.

    If the objects are thin and long (like the walls in your capx) then the above way won't work as well. The behavior I made can handle objects like that, but you need to set up the isometric sizes correctly. Here's a tutorial on it:

  • MINI TUTORIAL #1:

    When using this behavior it's required to setup the isometric size of the sprite. Here's a quick guide how for to do it for two kinds of shapes.

    The first thing to setup before anything else is to put the sprite's origin to the center.

    Next, just for reference here's the isometric coordinate system:

            +z
        *
        *
        *
        *
        **
      **  **
    **      **
  **          **
+y              +x[/code:35sfwrt5]
The iso size x is along the x-axis, the y on the y-axis, and so on.

The first kind of shape is this:
[code:35sfwrt5]      **
    **  **
  **      **
**          **
* **      ** *
*   **  **   *
*     **     *
*     *      *
**    *     **
  **  *   **
    *** **
      **[/code:35sfwrt5]
Basically any shape where the sizeX is the same as the sizeY. Here's how to calculate the sizes:

sizeX = sprite.width/2
sizeY = sprite.width/2
sizeZ = sprite.height - (sizeX+sizeY)/2

The second shape is this:
[code:35sfwrt5]**
* **
*   **
*     **
*       **
*        *
*        *
*        *
**       *
  **     *
    **   *
      ** *
        **[/code:35sfwrt5]
Basically a shape that's flat on the x or y axis. 
The size of the above can be calculated with:

sizeX = sprite.width
sizeY = 0
sizeZ = sprite.height - (sizeX+sizeY)/2

You can handle a shape that's flat in the x direction instead by swapping the sizeX and sizeY values.

Often you'll want to make the actual sizes a bit smaller to keep the objects from overlapping in isometric.  This is especially important if positioning on a grid since you don't want the sizes to be bigger than a grid size or it won't sort right.

Here's an example:
[url=https://dl.dropboxusercontent.com/u/5426011/examples29/iso_walls.capx]https://dl.dropboxusercontent.com/u/542 ... walls.capx[/url]

One side effect of the sprite's origin being centered is in isometric the bottom of the sprites won't line up if their heights are different.  To correct this just set the isoZ of all the objects to sizeZ/2.

  • "I need to find the three closest Big Rooms to a selected Big Room, then do that for all the following Big Rooms."

    You can do something like the following. The first event is to select the big rooms. The second event picks only big rooms, loops over each, and then loops over all the other big rooms sorted by distance. The pick by uid condition skips identical big rooms. After that rooms_family will be the the three closest big rooms depending on the loopindex. You can then store the uids any way you like.

    rooms width>32

    rooms height>32

    --- rooms set selected to true

    rooms is selected

    rooms_family is selected

    for each rooms

    X [negated] rooms_family pick by uid rooms.uid

    for each rooms_family ordered by distance(rooms.x,rooms.y,rooms_family.x,rooms_family.y) descending

    --- loopindex = 0

    ------ "1st closest"

    --- loopindex = 1

    ------ "2nd closest"

    --- loopindex = 2

    ------ "3rd closest"

    --- loopindex >2

    ------- stop loop

  • My capx will keep the enemies from piling up. If they are piled up they will spread out very quickly. The only drawback is they can be pushed into the walls a bit if things are crowded.

    Prominent's solution is to basically have a second object attached to the object with the pathfinder behavior. That bypasses the pathfinder overriding the physics positions, and probably is the best way to Incorporate physics. The rest is to stop the velocity of the objects so all we get is the pushing action. I'm unsure of the purpose of the force though.

  • —

    Yeah, that should do it.

  • —

    For that you could create two different families with the same object types in them.

  • delgado

    An "is moving" condition would only make sense if the behavior was automatically moving the objects. As it is now you control when it moves so you can either do stuff there or set a Boolean to do stuff later.

  • One way is to add a family that only has that object type and then use that to pick two separate instances.

    Another way is to pick one of the instances, save the x and y to variables, and then pick the other and do the calculation.

  • Have you looked at the examples? There is an example of a platform movement.

    You can use the iso "move by offset" action to move the ball, and the "iso overlaps" condition with the "push out" action to make it stop at walls.

    Up and down motion can be done like in iso_test3b.capx, events 11 to 13.

    You basically just need a vertical velocity (or as in the capx a z velocity "vz").

    The motion is simple:

    Every tick:

    --- subtract gravity*dt from vz

    --- iso move by offset (0,0, self.vz*dt)

    iso overlaps by offset(0,0,0)

    --- iso push out

    --- set vz to 0

  • balsh

    The easiest solution is to have a layer with a top view of the iso blocks and pathfind around that.

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

    It's just a matter of setting the position from the isometric position or vice versa.

  • The easiest way to do it would be to create a family and put only the player sprites in it. That way you can pick two seperate instances independently. A side annoyance is you won't be able to access the instance variables from the family unless you recreate them as family variables, change over the events and remove the old ones.

    So for example if you called the family "other" then your events could look like this:

    Fighter: control = -1

    Other: control = 0

    Fighter: X < other.x

    --- fighter: simulate left pressed

    Another way to do it without a family would be to pick one fighter, save it's values to variables then pick the other fighters and compare with the variables. It's doable but is tedious.