seven's Forum Posts

  • Also the ability to zoom in on the tilemap window with ctrl + mousewheel like you can in the layout would be nice. I'm working with 16x16 tiles on a 2560x1440 monitor and it's hard to see what I'm doing.

  • The new Tilemaps feature is fantastic. Now I don't need to sort through a hundred different tiled background objects to find the one I'm looking for; you should have seen my folder tree for Tiles, it was a mess. x_x

    There are some UI improvements I'd like to see in C2 which would speed up workflow without reinventing the wheel. Using keyboard keys to select an adjacent tile in the tilemap (e.g. using WASD while drawing tool is selected) would be much faster than moving the mouse across the screen every time I need to switch the tile I'm drawing with.

    codeproject.com/Articles/106884/Implementing-Auto-tiling-Functionality-in-a-Tile-M

    Autotiles (see link above) are a very powerful feature that would save me tens of hours of busywork. Something similar to this feature exists in Tiled, but it's a time-consuming and unintuitive hack, so I hope you would still consider implementing this anyway.

    Thanks for all your work on C2.

  • If you haven't played a megaman game, here's a good approximation of how the jump feels: scirra.com/arcade/example/4847/mega-man-engine-by-siksteen

    (Press S to jump; there's no capx released unfortunately)

    I implemented gravity manually because I'm not sure that C2's pixels/sec/sec gravity is the same as a constant change in velocity of 15pixels/sec.

    It could be that the platform behavior doesn't like small numbers; it would require subpixel precision to implement the jump properly. Or maybe it's just the values I put in? I'm comparing it to the thread I linked in the first post and I'm not seeing a difference.

  • I am trying to replicate the (very simple) jump physics from the Megaman games, using this thread as a reference: forums.tigsource.com/index.php

    I thought I understood C2's platform behavior but I guess not; in this capx, the player moves 2 pixels off the ground, then very slowly comes back down, or hovers a pixel off the ground:

    dl.dropboxusercontent.com/u/25752478/megaman.capx

    I can't figure out what is going on. Please help.

  • — cells based on the dimension of the object: yes. I think it's still safe to assume that all objects for which sight is calculated will be a multiple of the tile size; but if the object is 2x2 (in grid cells) or is a Tiled Background that is extended outward, more than just the origin of the object should be recognized.

    —: sorry for not being clear. the player can be to the left of a sight-blocking object (presumably to the left because that is the origin of the object) and have all sight cells disappear, as if the player actually went inside the wall. I haven't been able to isolate the problem, but it's enough to ignore the tile the player is currently occupying when calculating fov.

  • I'm impressed at the performance of this, compared to event-based field of view. However, there are a number of bugs with pathfinding. I've modified your demo to demonstrate: here.

    You can cause a crash a number of different ways:

    -Place a second instance of the Enemy object.

    -Require the Enemy to find a new path as often as it moves.

    -Right-clicking excessively will eventually cause a crash. This usually happens when the Enemy is adjacent to a Blocker object (orthogonally or diagonally) even when the object is not in the way of the path. Oddly enough, this never becomes an issue if you control the player with the arrow keys.

    There are also some unexpected behaviors which, although not exactly bugs, would still be considered unexpected:

    -The behavior assumes all objects are equal to the grid size. This becomes an issue e.g. if using a tiled background for the walls.

    -In some cases, the behavior thinks the object for which fov is being calculated is inside a wall. I haven't yet been able to reproduce this outside of one project, but one solution is to ignore the tile the object is currently occupying.

  • I ran the update and 8Direction.MovingAngle still returns values like 44.9999... If the player walks diagonally long enough, the value gradually corrects itself, but this takes an unacceptably long time to occur (greater than three seconds). This is probably true for both versions.

    Also, rather than having angles more than 180 degrees, the values instead switch to negative numbers (so moving upward is -90 instead of 270, etc.). Here is a quick illustration:

    <center>Expected behavior:

    <img src="http://dl.dropbox.com/u/25752478/8dirbug/standard.png" border="0" />

    In Construct 2:

    <img src="http://dl.dropbox.com/u/25752478/8dirbug/inconstruct.png" border="0" />

    </center>

    I understand this is intended behavior and is independent of issues with float rounding, but it's still nonstandard, undocumented behavior, and it works this way for no obvious reason. You can see an example of this making code more complex in the .capx file in the first post.

  • http://dl.dropbox.com/u/25752478/8dirbug/8dirbug.capx

    8Direction.MovingAngle is unpredictable when moving at diagonals, because of what I'd guess to be a float rounding error. To see why this is a problem, walk orthogonally in the demo and move at a diagonal in the opposite direction without stopping.

    This bug can be mitigated, but not wholly solved, by using the floor() function; the value returned by MovingAngle can be slightly below the correct value rather than above, and floor() only rounds downward.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • NEW plugin: I look forward to it.

    In the meantime, though, could you upload an example project using this plugin? The download doesn't come with one, and I can't figure out how light cells work. :c