lionz's Forum Posts

  • Hiya, this is a common issue I see people get stuck on. Due to Construct's top to bottom running of events what is actually happening here is it's setting something in event 1, which makes event 2 true and then it runs event 2. So in the same 'tick' which you won't see with the naked eye, it is toggling something on and off again. Some people try to resolve this with waits or timers which can also cause problems, I prefer to pass toggle options through a function, see my screenshot in this post : construct.net/en/forum/construct-3/how-do-i-8/how-do-i-create-a-character-sw-142015

  • Great, glad it's working :)

  • I mean replace low and high with numbers as described in the second line. I don't know what your range of layout numbers is.

  • Go to layout by name : "Layout_"&floor(random(low,high))

    where low= lowest layout number and high = highest layout number+1 (it rounds down)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's not as easy as it sounds but you can accomplish this with some tight function work. You replace every x seconds with the timer behaviour on the zombie object so each has their own timer. Whenever a zombie's state changes you run a function with the zombie UID as a parameter. Then when you call the function you use the condition where zombie.UID=function.param(0), that's how you identify the one zombie object. You can then run things like on zombie.timer ended, run function sending through the zombie UID, and check if you want to make it run a random path and start a new timer on that zombie. If zombie is in proximity of the player you can run a function with the UID to stop it from pathing then change its status to chasing and finding a path to the player.

  • You can assign behaviour to family group then say on enemy A created, set speed to this, then on enemy B created, set speed to this. So you have different speeds but can keep general logic such as 'all enemies(family) path toward player when they have LOS'.

  • In project properties bar, reverse the window size xy. If it's currently 720,1280 then change it to 1280,720.

  • Sorry, I don't really have the time to make this. Try using sprites with bullet behaviour that are created in 2 places and angle toward a cursor object in the centre.

  • It's useful if you are still applying some of the behaviour conditions to all members of the family. For example if you have enemy A, enemy B, enemy C, enemy D all who will move towards the player when they have line of sight of the player, you do not need to say individually enemy A LOS of player, enemy B LOS of player, but you can say enemy family LOS of player. It's up to you to decide if grouping behaviour for all enemies will minimize some code. I can't see anything wrong with applying enemy family behaviours because at least then you do not have to add behaviour to individual objects, they will all adopt the behaviour, then you can set the values separately for each object if you need.

  • Seems fine if the bottom 3 panels are also buttons you tap. I'll have to download and play it rather than just watch the video ^^

  • The sickle looking bits on the table that you move left and right touch, or so it seems. Maybe that's where the player is tapping actually now that I think about it, they might just be arrows where you touch.

  • This looks interesting, what do the 2 end bits on the table do, give you the ability power? Seems fast paced and competitive ^^

  • It's a small bug but not a big problem, just don't use line breaks for redundant 'organising'. The bug is to do with line breaks, not the compare two values condition which the topic suggests.

  • Compare two values is for comparing one value or expression against another. I'm not sure what you're doing here but it's not a bug.

  • Hiya, families work well for applying logic to all objects at the same time and you will be fine to spawn a random object inside family when you opt to create the family object. When you start trying to identify individual object types within a family this is where it becomes difficult because you can't do it. For this type of logic you need to return to using the object types and instead of spawning a 'family object' you would do something like for example, pick a random number from 1 to 5 and spawn the object related to that number, if that object is already on screen or count > 0 then destroy it and run the randomizer again. You would need to break it down to check if Object A exists, Object B exists etc, not the family.