WackyToaster's Recent Forum Activity

  • [quote:2e3sdtht]Please let me know if there is a more elegant solution.

    There is a more elegant solution.

  • The button has the "Set CSS style" action. You can apply all sorts of CSS to it, in your case you want to do "opacity" "0.00001" to make the button essentially invisible. and overlay it on the sprite.

  • You probably can just use every tick --> set X at the bottom of the event sheet.

  • You don't need a subevent, just add it in the on collision event.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You can set the sprite flipped/mirrored. Should do the trick.

  • You just put the png above the buttons (z-order) so the buttons go behind the png, that still won't work with the button object tho. The png just has to look like the background it is on or be created to look like a menu.

  • [quote:2278jzx7]In any event, another route might be to use separate text objects instead of buttons, but the issue still remains: how do I mask (clip) the display of a set of objects? A single object works fine using the Source-In blend mode, but for a group of objects?

    I rarely used these blend modes so I can´t really tell. But food for thought, you could also just use a png with a gradient to transparent for very simple masking. No effects needed.

  • What you want is to send inputs from the phone to a different device. So your best bet are probably Websockets, maybe the multiplayer plugin but it might be overkill. You have the app on the phone that connects with the game, then transfer button presses to the game and have the game react to it.

    https://www.construct.net/at/make-games ... /websocket

    https://www.construct.net/at/make-games ... ultiplayer

  • As of right now, buttons will always be above everything else. What you can do is to use custom sprite buttons, is there a reason you are using the regular buttons? If you really really want to use the regular buttons, you could maybe pin a sprite to them and set the css opacity of the buttons to 0.000000001, so you still use the regular button object for all the logic, but you can get the visual effect you want. But at that point you might aswell drop the buttons entirely and just use sprites. In the current state, what you intend is not possible. iirc. there was a mention in a blogpost about this and that it might change in the future. (but I might be mistaken about that)

  • [quote:89k7o52y]4 different (Animation Tiles) to use on 400 Tiles is not a good idea to use the TileMap I guess

    4 different tiles are fine, BUT you cannot animate them. So if you don´t intend to animate them, use the tilemap.

    [quote:89k7o52y]I thought that I read in other threads that if the Tiles are the same it counts the draw call as 1

    Is should be sort of true if you use the same tile. So if you use the same tile 100 times it should be 1 drawcall (I´m not sure if it´s actually only a single drawcall but it should be faster) if you have 100 different tiles, each will have a drawcall.

  • This has already been filed as an issue --> https://github.com/Scirra/Construct-3-bugs/issues/1396

    Where Ashley said that it´s an issue with chrome --> https://bugs.chromium.org/p/chromium/is ... ?id=823247

    Where it was fixed a couple of days ago actually. Based on https://www.chromium.org/blink/when-wil ... -or-canary this will take ~10 weeks before it´s shipped into the stable chrome version, so we need patience, or use https://www.google.com/chrome/browser/canary.html (I wouldn´t though)

    The problem is if you search for the issue on github (with "zoom") you will not find it unless you delete the "is:open" because Ashley closed this error. I think what would be great is some sort of bugtracker, possibly even inside of construct, that shows the current open bugs and if they are beeing worked on. So if you encounter an error, you could quickly check if it´s already been filed aswell as it´s status without even leaving construct. This will likely lead to some amount of overhead, but also might lead to reduce duplicate bugreports and frustration. I mean the bug has already been filed, fixed and will roll out soonish, so a user shouldn´t be left uninformed needing to make a "help pls" thread, and Ashley doesn´t need to be told for the 15th time that there is a bug.

    At minimum, Ashley shouldn´t close an issue unless it´s actually been 100% fixed and released, because else users won´t find it (that easy) when they search for it and just end up filing them again, posting suggestions, make threads about it, etc. I personally almost filed that zoom issue again recently, I don´t even know anymore how I found out it has actually been filed and is beeing worked on already.

  • Absolutely, basically just have it like the "Else" I think this has already been suggested on several occations, but the more the merrier

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 25 followers

Connect with WackyToaster

Blogs