lionz's Forum Posts

  • I still can't get it to work. I thought I could change the direction platform behavior objects fell and that would make lining up/setting the cards easier, but I couldn't find how.

    Using instance variables didn't really make it work. I tried using frame tags too. I am not sure how R0J0hound recommended. The problem right now is that I can't figuere out how to make it so that cards that have the same variable/frametag/are-in-same-animation-and-frame to interact the way I need them to without interacting with every version of that object.

    In general it is to do with picking, you narrow the picked instances with a condition such as 'on object clicked' or 'variable=n', otherwise it picks all instances. In terms of merging, because it is difficult to pick card vs card that's why the suggestion comes above from Rojo about using card vs family to specify object A against object B.

  • why would you change colour of the text on an object you are immediately destroying? how do you know it destroys it 'at the end of the loop' if it is running every tick, it would just look the same no?

  • You should set up some instance variables on those cards so you have more control over what's happening particularly the level of the card. I don't know your upgrade mechanic and how outcomes are created but if for example you want to combine 2 cards you could only allow if a lvl 1 is selected to click on another lvl 1 card, then combine into a lvl 2 so destroy both then create a new lvl 2 card and pick the frame at random 3 or 4.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Nice! good luck!

  • put the backpack on the HUD layer

  • The globals can remain in one sheet so it must be a different problem. The events that modify the globals need to be on an event sheet linked(included) to the layout you are on.

  • You could give the dummy two variables one to say what it is assigned to, unit or building, and another to track if it meets the condition of being close to a unit. Then if the dummy is of type 'building' and var unitNear=true then don't target it by a condition on the main target event.

  • Not sure what went wrong here but you definitely can set the string in general. Are you trying to use 'current.layoutname' specifically because you just need 'layoutname'. Is the variable of type string? If it's number it would produced NaN as a result you can see this in debug view.

    Or possibly it is to do with how your event sheets are linked, it may not be reading the event at all or running it (though if you say a number worked then maybe it is running it). You can also share the file if you need further help.

  • Forgive me if i'm thinking about this all wrong but isn't dragging both axes simultaneously just default drag and drop behaviour? The locking to one axis is the custom behaviour which you want to remove.

  • It doesn't really like on animation finished, for a looped animation. If you remove 'looping' from swing animation in the image editor it is fixed.

  • Yeah you are right this would have to reach the original destination and wouldn't keep checkingif that's what you need. You could use the timer behaviour on the unit which I find is always better than system every X seconds, 'on timer finished' you can check certain things then start the timer again for individual units.

  • Looks like some weirdness with using every X seconds and for each. I would try something safer like state = chase and unit is not moving along path, then find path. This removes every tick and every X seconds with pathfinding. Also there might be a better way to do your units that what I'm seeing with the two identical families, the picking looks really convoluted. In a game like that you may want to keep Enemies as a separate family to Friendly units. And the extra layer of confusion with spriteUID variable, it seems like there could be a simpler way.

  • But in this post you are listing all the limitations you are coming across by using a single object for every enemy in the game while also saying it is a good thing. Not sure what to tell you :D

  • For setting the head variable use 'snake set head to true' instead of family, this is still the inherited family variable. For the collision you can probably make the collision boxes smaller than the sprite, should be no harm done.

  • You've limited yourself by using one sprite for all characters but there is a way out, for the ones that shouldn't persist just create a 2nd object that doesn't have the behaviour. For when you need to pick all the npcs put the 2 objects in a npc Family. In general though I would use a different object for each character because when you use one sprite for all game animations it loads all unused graphics and can lower performance.