R0J0hound's Forum Posts

  • I wonder if that limit is enforced if you change the layout size with an event.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • True. You need to change the Ray for the second iteration. Probably a "for each laser" instead of the repeat so that each Ray could be used.

    As a rough overview it's kind of like this:

    For each laser

    ---"set Ray" to laser

    --- for each wall

    ------ "cast to" wall

  • Ken95

    I won't have time to look at your capx, but if it's only working for one laser then you need to repeat the actions for the other lasers. A loop would be useful.

  • That's more than I'm willing to help with. The library I used can't load excel files, but it's the only one I found that can add images.

    Anyways I guess a way to do it would be to take the xml file, do your replacements, then use the xml plugin to access all the data in it. Finally it's a matter of transferring it all over to a format the excel js library can use to create the file. At a glance it should support all the features you need but maybe not. It'll be a lot of digging to get it working either way.

  • For the first you can use x.pickedcount.

    For the second if it's tile based i'd use and 2d array for the grid and use a "for each sprite" to add each sprite to the array and if a spot is already occupied just delete the lower one.

    Or you could finagle picking to do it. A condition like "sprite is overlapping sprite" will pick all the sprites overlapping but that isn't what you want, and putting that after a "for each sprite" won't work cause then it would only check for collision with itself because only one instance would be picked.

    The simplest way would be to make two families of the same object types (or only one family if only one type is needed). Then do an event like this:

    for each family1

    family1 is overlapping family2

    pick top family2

    --- family1.zorder > family2.zorder

    ------ destroy familly1

    --- else

    ------ destroy family2

  • There's a "resize canvas" action, that sets the texture size used by the canvas. By default it uses the size on the layout but for high quality scaling you'll want the texture size to be bigger. So for a canvas covering the viewport you'd want the texture size to be (windowwidth, windowheight) for example. Keep in mind that that action to change the canvas size will lose what was previously drawn.

  • To be clear the physics behavior issue and chipmunk behavior issue are two independent issues.

    I can only speak for the chipmunk behavior though.

    A save/load will do nothing for the chipmunk behavior, and in fact I didn't make saving/loading do anything.

    The only way to "refresh" is to reload the webpage.

    I probably won't have time to track down where the leak is in the behavior.

    In the meantime a practical solution is to maybe diminish the amount of leaking so it can run longer.

    Creating less physics objects is an obvious thing to do, but it's probably not the issue here.

    Less obvious is every time a physics object changes size, or changes animation frame, or in the case of the tilemap is modified then that actually causes stuff to be recreated in the physics engine.

    So if you want an animated Sprite to have physics then instead pin the animated Sprite to another Sprite with physics.

  • It has to do with color profiles and chrome/nwjs

    Look here

  • SuperSushi

    In you second image change the top "rect" to "polar"

    Rect lets you give a X and y impulse

    And polar lets you set an angle and direction like the physics action you used in the first image.

  • Concave shapes are fine with the physics behavior.

  • Right. It's a simple thing to merge the tiles when it's known the tile's collision polygon covers the entire tile. This is probably a flag or something per tile. Custom polygons would be more complex and slower to merge because the actual collision polygons would have to be checked. The principle purpose of the merging is a quick way to reduce the number of collision polygons.

  • Off hand it looks like you can get microphone input with the "user media" object. When you get it you use a tag that can be used with the audio object. Then you can add the audio analyzer effect to that tag and get frequency data and such. There's an example of using the analyzer effect included with c2.

    That should be enough to get you started. A working example would have to wait till someone has time to make one.

  • It sounds like an issue like this:

    http://gamedev.stackexchange.com/questi ... wall-tiles

    The tilemap object merges the collision polygons of tiles with the default box collision. The result is the right wall is probably one full rectangle so there is nothing to snag on. Usually at least, it mainly depends on which tiles are merged.

    Custom polygon tiles can't be merged together so that's probably why it still trips on corners.

    The link above talks about solutions that probably are mostly usable from the engine level. As a user we could post it to the bugs forum and see if there's any fix that could be done.

    Other ideas could be to use a second tilemap with half sized tiles. That way you can still get that tile merging and avoid corners to snag on. There are probably some other similar ideas. If it becomes too tedious you can automate it with events. If that gets too slow then you could just run the events once after you tweak your level and copy th tilemap's json to load when you actually want to run your game.

  • The bouncing should be handled by the behavior itself. Just give the objects the chipmunk behavior and make the edges have the immovable property. Setup should be identical to the built in physics behavior.

    To make everything bounce like pool balls, set the elasticity to 1 on everything. The apply impulse action is only needed to initially launch a ball. No math is needed.

    You can calculate the KE of a collision with the physics behavior with a little math, but that's mainly just useful to adjust the volume of the hit sounds.

  • I don't use mobile but the manual entry lists iPhone being registered as such as I recall when I read it initially. I suppose it's possible for the browser to lie about what it is.