johnsmith's Forum Posts

  • I've made it

    for thoses wo might be interrested here is how I've done it:

    Seems to be working so far so i'm happy

    Thanks for trying to help caiorosisca

  • Well well, looks like I have some troubles to achieve what I want with the dictionary...

    As it's hard to explain for me, here is a little screenshot of my event_sheet:

    I'm not used to use "pick all", so it might come from that...Or the fact that I use both 2 objects's instance variables (the key, and the door) to call the dictionary's key "door_1" ?

    (the door has a boolean "open" true/false wich is not in this event_sheet....but which is working correctly (or at least it was so I'm pretty sure it's my dictionary's event that has a problem)

    Do you see what I'm doing wrong ?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That sounds very good, thanks for the explanation caiorosisca

    I'll definately give this a try.

  • Edit: You don't have to create new event sheet each layout. Create 1 event sheet. And include it into each layout.

    Yeah but then my problem would be the same.....I dont know how to manage multiple layout/doors linked to global variables.

    Here's my separated event_sheet (for the level_1) if you want to take a look:

    This is how I managed to apply this mechanism to multiples doors/layout...but as I said, not the best solution I guess.

    I think I know what caiorosisca means, but what I'm asking, is how to store the doors state in beetween layouts...

    I'm gonna take a look at the dictionary, hopefully I will get something better from it

  • It's hard to explain,

    Basically I have 1 object (the door) and 1 global variable to store the lock/unlock state through all layouts.

    But I dont know how to link the object (door) to the global variable without having to create multiple objects/doors instead of using instances.

    I have found a solution...which is to create an additional event_sheet for each layout that has a key/door mechanism in it...that's certainly not the best solution...but it works so far...so...

    But Still if anyone got a better solution (and is able to understand my poor explanation

  • Thanks Dutoit, that tutorial is nice but it uses arrays for storing the doors states...and I dont use arrays :/

    Im still trying to figure out how to store the doors differents states using global variables...like you said.

    Lets say the Level_1 Door is locked.

    There is 1 key in this Level.

    Once the key has been picked up, the door is unlocked

    Level_2 is now available (and you can go back to level_1 (now unlocked) from there.

    The lock mechanics I'm using is as follow:

    Door boolean = "locked" (=solid)

    Player pickup key -> Door: Set boolean to "unlocked" "(=not solid)

    But how do I store this in a global variable ? that's where my brain is stuck...

    I believe I need a global variable for each doors ?

    So something like

    Door_1= 0 (locked)

    Door_1= 1 (unlocked)

    And so on for door_2, 3, etc

    But how do I link theses global to the appropriate door/layout ? (using a single event sheet and a single door object...which is/will be instanced)

  • Hello,

    Might be a beginner question..

    I use several Layouts.

    They are sometimes connected with doors (1 layout can have from 1 to 4 doors - leading to 1-4 differents layouts).

    The player can also go back to any previous layouts if he wants to.

    If a door is unlocked/open from the start, no problem as it will always be open.

    But if it's locked and the player has to unlock it then I got a problem.

    Because if the player unlocks it, proceed to the next layout, and suddenly decide to go back to the previous layout, that door is locked again.

    How do I keep that door open/unlocked when reloading its layout ?

    I'm sure it's with the help of Global variable....but I cant find a proper solution..

    Any help would be appreciated, thanks !

    Edit: also all the layouts share 1 single event sheet, so I would like to keep it like that if possible.

  • Yes they will share both the same mouse position but that's not much of a problem (at least for me) and it still allows you to check if your Touch (1) events are working correctly without having to test on mobile (or modifying events on right click or on default touch (0) ).

    This is a minor suggestion, and it will not be perfect as you pointed out but still might be usefull. Maybe it could be an optional propertie in the "Touch / use mouse input" if it's not too much troubles to implement?

    In my game I use touch (0) for player's movements, and Touch (1) for actions, which make it a little difficult to test on PC.

  • Hello,

    Just a simple suggestion for the Touch behavior.

    At the moment (correct me if I'm wrong or if there is an easier turnaround than the one described below) the 3 mouse buttons only simulate the default touch ID (0).

    I think it would be pretty cool to have at least the right click to simulate the 2 fingers touch ID(1) so it would make life easier for testing on PC rather than having to duplicate all touch's events with "on right click" instead.

    Also maybe the middle mouse button could simulate the ID(2) (3 fingers ?), i'm not using it but it might still be usefull for certain projects ?

    That was my simple suggestion, thanks for reading and thanks even more for creating this awesome tool ! :)

  • I can't open your capx, don't know why, probably something with my computer, but couldn't you just add a condition that compares the y-position of the player with the y position of the collider?

    if collider.y < player.y - set player angle to 180 (or collider.angle + 180)

    That's actually a not bad idea, but the problem is that the player can move along the collider (while being "stuck"(hanging) on it) and the collider's angle can be set at any angle, so the X,Y coordinates comparison will be kinda tricky I'm afraid..but might be worth a try !

    Maybe you should create two collider objects. One for 0, other for 180 degrees. It's not an elegant solution but it should work.

    That's actually what I'm doing now...but yeah like you said, it's not the best and it's more time consuming so I was hoping for a better solution :)

    Thank you both for your help !

  • Sorry to bump..but anyone ?

  • Hello,

    I'm making a game where the player can stick to floors,walls,ceilings,etc..

    When the player sprite is overlapping collider

    -->rotate 4degrees toward collider's angle.

    That's working not too bad.

    Now my problem is, when the player goes on the other side of the collider..

    for example, the collider angle = 0�

    If the player is on top of it, then it's perfect.

    But if he's stick to the bottom of it, his angle should then be 180�(flipped) instead of 0�, so there's a little problem here...

    Here is a very basic capx, without the sticking ability but you still can see the problem:

    https://www.dropbox.com/s/hhzzf7kw84gru3k/alignement_problem.capx

    I think I can resolve this with the "overlapping at offset", but I'm having real troubles to figure it out...so I thought maybe I could ask some help on the forum...

    Thanks a lot if you can help !

  • Well thanks for your help mindfaQ

    But unfortunately that doesnt work for what I want to do as I keep modifying the bullet angle of motion, that's why I was going for a "set X,Y" event instead..this way the bullet behaviour is not altered and can continue doing his stuff..

    Also there is a problem in your example as the enemy still goes through walls from time to time..

    I think the detectors I'm using was a bad idea, and maybe I can trigger the "set X,Y" with something else (like the overlapping at offset ?) but as I said, Im kinda lost with how to change the cosinus formula..

    If anyone got an idea, I'd be glad to hear it ! :)

  • Yes they are straight walls, with atm only 90�angles (for floor, side wall & ceiling), but ideally I would also like to have some more fancy angles later..

    I've found a formula on this forum about Cosinus & sinus (which I dont really understand..but it's working so far). Im applying it with the help of 2 detectors for X & Y pinned to my ennemy and the event looks like this:

    Detector X overlapping wall

    --> Enemy set X to self.x-cos(self.Bullet.AngleOfMotion)*self.Bullet.Speed*dt

    Detector Y overlapping wall

    --> Enemy set Y to self.Y-sin(self.Bullet.AngleOfMotion)*self.Bullet.Speed*dt

    That works...but there is still a problem when this happens:

    (orange rectangle is Y detector, blue is X)

    <img src="http://i.imgur.com/Qh79369.jpg" border="0" />

    There, the enemy will just get stuck (if not worst)...as the wrong detector got triggered first.. :/

    And if I make both detectors the same size to cover the 4 corners "holes" then it doesnt work at all as they are both triggered at the same time...

    I dont know what to do here, I've tried many things but unsuccesfully so far..and as I dont really understand that cosinus formula It's hard for me to "tweak" it, so if anyone could help me on this that would be great, thanks.

  • Hello,

    I have an enemy with the bullet behaviour.

    When he sights the player, his angle goes toward the player.

    But if the distance between the player & enemy < 200, his angle changes to angle(playerXY,EnemyXY)+90 or -90, this way he starts to randomly turn around the player.

    My problem is when he collides with a wall...I'm preventing collision by using the "bounce off solid" but this gives a pretty bad result as the eneymy keep colliding itself against the wall (until randomly changing his angle again).

    So I was wondering, can I make it so the enemy slide against the wall (in the appropriate direction regarding his current angle of motion) instead of colliding with it ? How would I do that ?

    Or if you have any other solution to make it so the enemy avoids walls, I'm interrested.

    Thanks by advance for your help ! :)