R0J0hound's Recent Forum Activity

  • If AirConsole.Message is "{ touch: 999 }" then you could do this the get the value of "touch"

    Browser.ExecJS("var a="&AirConsole.Message&";a.touch")

  • The runtime errors are generally due to the events, not the objects. At this point I guess it can be assumed that the fixer cap does nothing, at least for your cap. You can start disabling events until you identify the offending event, but my money is on the "or" condition. Don't ever use it, it causes crashes. The only other common issue is with instance variables causing runtime errors, but this is less common and there is no fix.

  • It's probably possible.

  • It's probably a bug in my code, but I can't test it without the webgl renderer being used.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • —

    You could go at it from another angle. You could use a 1x1 sprite and just paste that, or you could just use a tiny tilemap instead of the paster object. If the map doesn't change you could also use the canvas plugin, since it only has a performance hit with webgl if you constantly change the texture.

  • You could do this:

    global number index =0

+------------------------------+
| while                        | set index to int(random(5,8))
+------------------------------+
   +---------------------------+
   | array: value at index <99 | array: set at index to 5
   |                           | stop loop
   +---------------------------+[/code:3re0ismd]
Basically pick a random index until the value isn't 99 before setting the value.

You could probably do it all without an array though.

  • I took a look and the events look correct. I don't use webgl so if there's a webgl related issue I won't see it. The minimap was oriented correctly, but the colors were faded except for the right and bottom edge. I have no idea why that occurs, but using a "additive" blend is on solution.

    Edit:

    Fixed the faded issue in the plugin.

  • I just tested it here and there is no issues going to a max speed of 10000. The speeds are in pixels per second btw.

  • mattb

    My behavior wouldn't work here because the isometric view is for 2:1 instead of 60 degree isometric. It could be an idea to somehow work with it, but I haven't given that much thought.

    My idea may not even be simpler. I've been working on a example off and on to get a working example of my idea. but I haven't put a lot of time into it yet.

    The z-ordering is too hard if all the cubes are placed. So only sorting them per hexagon is much simpler. To actually sort them i'd use the filimation approach which compares all the blocks and builds a tree graph of what is in front of what. Which is what my behavior does and works great for sorting isometric in most cases.

    The collision detection is simple enough. If the player and a cube are visually overlapping you can then compare their isometric positions to do a bounding box collision check in iso. You could populate a 3d array as a 3d grid of cubes as a lookup but it shouldn't be necessary.

    Everything is per hexagon and is the player overlaps multiple hexagons, then each would need to be updated.

    What i'm currently working on is a way to update the cube positions on a hexagon. For that I need to know which of the six sides the the blocks exit and the the order of each of the three axis (x,y,z). Like if only the y and z line were used like in your top right image: x in front of z, y and z the same, z in front of y. I can move any line forward by adding the same value to each isometric position, which won't change the visual location.

    The player's position can be different per hexagon because of this order, so to remedy the transmission from one hexagon to another, it needs to keep track of what line the current block it's touching is on (x y or z).

    It may end up not being easier than what you're doing but it works in my mind. Once I get it working I probably can identify some unneeded cruft and simplify it. It's just taking longer than expected because I haven't had much time to work on it.

  • Here's a discussion of ways:

  • With a tilemap I don't think any of them will help, since all those get a collision shape either by using imagepoints or using the size and angle of the object to calculate the collision polygon. Tilemaps are different. For them to work we first need to find the tiles the player overlaps, then treat each tile as a separate object. It's doable, but I'm very slow at coding lately and I have other things I'd like to work on first.

    Another way to do it is to use a different approach. Instead of figuring out the collision polygon, we could use collision checks with moving around a little to find the approximate angle of the hit edge. The closet existing capx to that would be this, but it would need more work to get it to handle sliding on more angles.

    By far the simplest thing to do would be to just use the physics behavior, which probably would look alright.