UncleHo74's Forum Posts

  • Something like this works for me. I don't know how different it is from what you're using.

    start of layout
       local number value=0
       repeat 10 times
          wait 0.1*loopindex seconds
    	  add 10 to value
    	  sprite: set effect "tint" parameter 0 to value[/code:j0v4w6s6]
    A variable is used instead of using loopindex below the wait because the wait action doesn't save the value of loopindex.
    

    Sorry, it took a while for me to answer..

    Hmm.. I just don't seem to get it.. this is my code (it's a sub-event of "start of layout"), doesn't work for me, it doesn't change the value of the blur parameter at all

    (..sorry, imagebucket link, you may have to click to get the full size image and I don't know what evil things they're doing at imagebucket ad-wise..

    guess I'll have to set up some of my Dropbox or OneDrive folders for public access for future images here ...)

  • It's a good practice though

    Who am I to ignore good practice? I'll keep this in mind, thanks!

  • Neat!!

    This "browser->execeute javascript" action is something which I have to keep in mind... thanks!

  • Let's assume I have set an effect - BlurHorizontal in this case - for an object. It's set at 100 percent for this object via settings.

    I want to decrease the effect over time, right after (or at) the start of the current layout.. so something

    like a "fade in" effect (yes I know there's a behaviour which is already very similar.. but let's ignore this for the sake of the question here).

    I tried several methods.. using the "On start of layout" event, the "On Loader Layout Complete" event... in combination with

    "for" and "repeat" loops and "wait" commands and decreasing the value of BlurHorizontal within this loop .. and yes, already having the "wait issue in loops" in mind ..

    https://www.scirra.com/tutorials/723/us ... t-in-loops

    .. but.. to no avail.

    The loop is finished instantly as it seems, but I DID use "wait * loopindex" method which is mentioned

    in the link above.

    The only way I can implement the feature is via "System->on every tick" in combination with a simple "wait x seconds" action and some other simple conditions (in order to avoid the effect to be continued

    indefinitely). This works like a charm. ("every X seconds" works too)

    But I don't think it's very effective.. I don't like the "on every tick" approach.. and I don't get why it's not working with the loop in the "On start of layout" event in the first place.

    It doesn't help finding the root cause that I can't set a breakpoint because this is a triggered event... (speaking of breakpoints, they seem of very limited use in Construct anyway because of the limitations.. how are YOU guys

    using the debugger in practice?).

    Any ideas?

  • Use a "assets" layout that you never go to on runtime to only place all your objects. That's what we usually do on our projects and it works and keep your game layouts clean.

    Yeah, as I said in my first post, I usually already do this, my "scrap layout"..

    Still not elegant in my eyes, and occasionally I started this scrap layout when I click the "Run Layout" Button...

  • you can destroy them or use their settings to set them disabled.

    If it is a bullet I destroy it and create when needed. For buttons and other objects I use disabled and enable as needed. I set all my buttons on the layout and make them visible and enabled as needed.

    Yeah, I know that there are some objects which can be disabled via the settings.. I do that already, my problem was specific to bullets, particles etc. which have to exist at the start but can't be disabled fully (well, you could like setting the speed to zero etc. etc. but it's not THE solution for me either).

  • Destroy them on start of layout then create them when you need them. If they are outside the layout but then destroyed then they are loaded in memory and any lag is avoided.

    Okay, that will work.. quite a "brutal" method and somehow rough around the edges, I would have guessed that Construct has a method to handle objects which are needed later on in the game a more elegant way, but doesn't seem so.

    Thanks for your help!

  • Maybe your problem and the one I was having are related? See here..

  • Hello,

    I've seen that it is common practice to place objects which will be used later (aka "they will be spawned dynamically") outside the Layout.

    This is somewhat weird to me... Objects with bullet behaviour are flying off screen as soon as the layout starts etc, so you have to place them at the "correct" border of the layout so they not come into the players view during the start while they're flying off.. or place them on a "scrap layout" altogether.

    Is this really the "normal" way of handling the "unused" objects? Or is there a better one?

  • Same here

  • Well, still a Construct noob myself, but are you sure that this isn't the typical tile problem which is the reason tiles are often set up with "smeared pixels" around the actually used pixels so the GPU doesn't render blank space if resizing the tiles?

    In GameMaker this is a common problem even documented on the official YoYo page:

    (Sorry for a link to the "competition".. but the article seems to be fitting here..)

    https://docs.yoyogames.com/source/dadio ... tiles.html

    I think I've read somewhere that construct takes care for this problem itself.. but who nows.....

  • Wow, thank you.. I've seen these "Pick" methods, but couldn't wrap my head around their implementation... Your example is perfect! Thanks!

    Only problem which remains is the order of actions which are to take.. As I said, I've some actions which are only fitting for some of the family members, I can pick them by UID in a subevent now (thanks to you), but the actions for the family itself are already done at this point.. which is unfortunate in my case. Let's say the last action of the family "EnemyFamily1" is "Destroy", then in the subevent the picked "Enemy1" will never see an action.

    There is no way to "get back" to the family after drilling it down to the family member in the subevent via the Pick method, or is it? There's "Pick all" method but I think that means something different.

    And starting another event.. well, as I said, I want the whole collision handling with the bullet in one event, seems the best solution to me...

    EDIT: Okay, MAYBE I've found the solution myself.. I first write all the actions for the family which can be done at the start in die beginning, THEN create a subevent and pick the right family member, perform the actions regardings the family member, THEN create another subevent and Pick the Family via UID again and perform the rest of the actions regarding the family...

    At least that's a solution which worked for me.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hello,

    I have a problem with a - seemingly - simple problem.

    Let's say a bullet hits an enemy. All enemies are in a family because there are always the usual actions (like destroying the bullet and the enemy etc.)

    But some enemies are different, they have a different behaviour or an effect which has to be disabled while "dying" and so on..

    Let's say there is EnemyFamily1, and Enemy1 has a "Sine" behaviour (and the family has not), Enemy2 another behaviour..

    The condition (on collision with EnemyFamily1) won't allow me to set specific behaviour for Enemy1 (every action regarding Enemy1 will change ALL instances of Enemy1.. and not only

    the instance which was part of the collision...

    What is the solution for this problem without checking for the same collision for every different enemy type? I mean, families are meant to avoid redundant code right? But how to

    achieve this if I cannot "break down" the object types in the collision handling with the family?