Black Rabbit's Forum Posts

  • Thank you so much, that worked!

    I had done UI for Contruct like 3 years ago, so I completely forgot I had to take care of that.

  • Maybe this image will help, please forgive the convlutedness of it, but it was necessary to make the 4 directional hits thing.

    I have gone through it at the bottom and explained it on case you are not sure why certain things are the way they are.

    p_hurt = "not" //need to do this so the player only collides once

    p_invulnerable=0 //I have done this so the player cannot get hit for about 2 seconds after he lands.

    p_health > 0 //so this will only trigger when the player health is above 0

    player is overlapping Damage //damage is the name of the enemy family for now

    player x > Damage.X //this is so where on the coordinates the player is

    p_facing = left //so we know to do this only when the character faces left

    trigger once

    p_ishurt to "subtract" //this goes elsewhere to call the value of health to subtract

    p_washit to f_left" //this records which of the 4 possible ways the player gets hit, so when subtracts has removed health, it turns into "where", this is important because the animation playing could be the death of the character instead of the one being hurt, it needs to know before it plays it.

    p_ishurt = "where"//after subtracting health it now comes back here to do the next thing

    p_facing = "left" //even if redundant I had to place it here because it was causing some bugs otherwise

    p_health >o = // this needs to know you are not dead yet so it plays this animation.

    p_washit = "f_left" //this is to confirm the hit location

    p_ishurt to "f_left" //this is used to confirm and trigger the right animation and event

    p_ishurt = "f_left" //this event starts now because of what is aboove

    trigger once

    vector y // makes it move from damage

    vector x // same as above

    p_crouch to not" //this makes sure than any other animation is cancelled if you are hit

    p_punch to not //same as above

    p_kick to not //same as above

    protagonist //sets the hurt animation for this specific orientation and location

    The following is the same as before, but we are checking to see if the character is dead instead.

    So first of all, how to I fix the direction hit issue so that the x is of the instance of the enemy, not of the first one being called for.

  • Sorry resolve which problem, the damage coordinates or the list to call who gets hit?

  • Well the first problem is pretty simple to explain:

    I do a player x value check and if it is greater than the x value of the enemy (in this case of the whole family), so if the character is hit from the left, he flies to the right, if he is hit to the right, he flies to the left (this also depend on which direction he is facing).

    This works, but when there are multiple instances from the same family, construct only takes reference of the x value of the enemy I first put down in the layout (rather than the closest one), so if enemy 2 is like 500 pixels +X (right) of enemy 1, the collision still thinks you get hit from the right, no matter where enemy 2 is, even if he is to the left of the player (-x).

    The second problem is that I literally have no clue how can I call with events a variable based on which enemy from that family has hit you without having to write a massive list:

    getdamage=

    if enemy_1 collides with player, get variable enemydamage_1

    if enemy_2 collides with player, get variable enemydamage_2

    if enemy_3 collides with player, get variable enemydamage_3

    if enemy_4 collides with player, get variable enemydamage_4

    if enemy_5 collides with player, get variable enemydamage_5

    because they might all have different values.

  • Not sure if I understand it 100% but I will try it, thanks.

    Also another problem I have with the family is that, when I check to see if the player x is greater or less than the x of "enemies" to see from which direction he is getting hit, no matter how many enemies there are, it always consider the x of the first enemy I have placed in the layout, not sure how to fix t his one.

  • It helps but the problem remains.

    1. I will have to create a family for each damage value, so if a mosnter does 10 damage, he cannot be in the family where they do 20 damage (as far as I can the family does not allow me to assign a variable for each sprite, unless I assign it to each sprite within the family and they inherit it anyways).

    2. I still do not know how to call specific damages as I quoted from my example above I will do so again, perhaps I as not clear.

    What I have so far are 4 states:

    If you are facing right and are hit in the front, or back.

    If you are facing left and are hit in the front or back.

    Everytime there is a collision with... "family" (and checking the x coordinateds to see if they are coming from the back or the front), go get the damage (varaible "getdamage").

    getdamage subtract ....????? from health.

    ?????= What do I put here? How do I tell it "from the family you have just collided with" or "check the family you have collided with, then go get this global/local variable"?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Would you be so kind as to elaborate on that, I Am not sure I follow :)

  • I have spent quite a bit of time looking into doing this one but could not find the most efficient solution of doing it.

    I am trying to have a list of variables each with with the enemy name and damage type associated, so this I can easily do.

    Example:

    e_grunt1

    value 10

    e_grunt2

    value 15

    e_grunt3

    value 20

    What I struggle with however is probably the simplest part of all; How do I call each value when I need it?

    So the way I have it set up right now is that when a collision with a single generic sprite for damage collides with the player, I use a variable called "getdamage" to ask the damage value.

    So it goes something like this:

    getdamage:

    if player overlaps with collision sprite1 subtract e_grunt1 to player health

    The problem with this is that it means that I Will have to do a unique collision sprite for each individual enemy (so creating a sprite1, sprite2 and sprite3, just for collisions), surely there must be a more efficient way?

  • So, another little issue with this if anyone is still reading!

    When you anchor objects to a layer like the UI but the camera has lerp all of those UI elements tremble like crazy, anyone else encountered this?

  • I do not know if there is an error, I am just guessing based on the very peculiar behaviour.

    the capx is rather big, it would take on forever to go on through all events and explain them, there is like 120+ plus about 50 varaibles (and that's jsut the beginning!).

  • Is there a known issues which makes player behaviour on solid different than when standing on jump-through platforms?

    I get several issues in my character behaviour and animations depending whether they stand on a solid or not. The most obvious issue is that my character does a turn animation before is flipped, and this works fine, however my character can kick in the air, and when they land while kicking on a jump-thru it all works fine but when landing on a solid they will always do a turn animation first. This makes no sense I have applied no difference in behaviour from solids to jump-thrus, I simply call the on landed functions.

    I do not understand, I thought "on floor" and "on landed" applied to both solids and jump-thru equally, I guess not?

    I have also switched around behaviour to make sure there was nothing else at fault with the sprites and collisions and as far as I can tell all works the same, it is definetly a matter of solid vs jump-thru behaviours.

    Is there perhaps a larger margin of errors with solid collisions like the 0.0001 error or something?

  • Thanks, originally I had done that and did not work, then I realised while trying to fix it that I had made a mistake in the set position of the camera as well, so it should have been self.x and self.y (instead of scollx and scrolly which I copied from somewhere else) for some reason when I fixed that the camera on start also got fixed :)

  • So I have currently a camera set on every tick to lerp(scrollx, player.X, 0.05) lerp(scrolly, player.Y, 0.05) that way it follows the player smoothly, however when I change a layout and I place the coordinates of the player elsewhere for the new lavel, the camera follows smoothly from outside the edge of the screen to the character new location.

    How can I make the camera quickly snap to the player current position if on every tick tells it to always use lerp?

  • You do not have permission to view this post

  • Thanks! I have tried your instructions but could not make it work, perhaps I did not do something right, however your suggestion of removing loop is what was causing the issue, originally, without loop my first idea now works :D