blackhornet's Forum Posts

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 2

  • 12 Mar, 2023
  • Quote

  construct.net/en/forum/construct-3/plugin-sdk-10/lightning-generator-156145

• Try Construct 3

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

  Try Now Construct 3 users don't see these ads
• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 8 Nov, 2022
  • Quote

  It's common for sprites to bleed when scaled if there is no buffer around the image. Make sure each character has 1 or 2 blank pixels around all four sides.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 5 Aug, 2022
  • Quote

  You apply the force but you don't enable Physics until after. Get rid of event 7, and enable Physics before the Apply.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 15 Apr, 2022
  • Quote

  Unfortunately I can't fix the aliasing - it's a Microsoft restriction with the framework I use. The best I can suggest is that you use version 1 (link in the original post) and you'll have to pull out the spacing data manually from the generated text file.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 23 Mar, 2022
  • Quote

  I've fixed the link on my page: construct.net/en/forum/construct-3/plugin-sdk-10/plugin-converter-123855

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 6 Mar, 2022
  • Quote

  The issue is different. A precision difference was introduced. Making the DrawingCanvas use int sizes fixed the discrepancy.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 6 Mar, 2022
  • Quote

  Actually this was trivial to fix, so I've updated the template.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 2

  • 4 Mar, 2022
  • Quote

  Confirmed. I'm the template author, and it seems this broke in 257. I'll have to build a test project to submit a bug to Scirra.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 2

  • 2 Mar, 2022
  • Quote

  You need the trigger at the top level, so that's better, but it also looks like your main event is running constantly, which means the timer is constantly being reset, so never triggers. Add the extra check for whether the timer is not already running.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 14 Feb, 2022
  • Quote

  The item won't be picked on return from the function. You could pass back the UID of the new object and pick it before proceeding, or, as lionz suggests, pass in the other values to the function.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 2

  • 7 Feb, 2022
  • Quote

  You can implement your own timer mechanism, but it's a bunch of work for no gain. You'll have plenty of run-ins with "For each" as you you keep going.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 6 Feb, 2022
  • Quote

  You can't cancel a Wait. Use a Timer instead, which you can stop.

  EDIT: you also want to make sure event 2 only runs once. Right now it's running repeatedly for 1/2 a second, until the visibility changes.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 2

  • 5 Feb, 2022
  • Quote

  Give your family the Timer behaviour and try this:

  

  If you want the time to change also, just reset it in the "size" event.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 2 Feb, 2022
  • Quote

  We can't see your parent event, so the question is; is the attack code being called only once, or repeatedly, which would keep making the layer visible.

  You may need an "attacking" state, so you don't keep repeating the attack state.

• • blackhornet
  • 
  • • Joined 28 May, 2012
    • 
    • 57 topics • 4,431 posts
  • 1

  • 2 Feb, 2022
  • Quote

  Triggers should always be placed as a top-event, as they run outside the usual loop. The Wait will not affect the "On tap" event.

  A better mechanism is to put the On tap code in a Group, disabled by default. Then when your attack mode is triggered, run the Wait code, adding "Group enable", at the end to turn on the input tracking.

  Disable the group again, when appropriate.