johnsmith's Recent Forum Activity

  • 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 !

johnsmith's avatar

johnsmith

Member since 21 Jun, 2013

Twitter
johnsmith has 2 followers

Trophy Case

  • 11-Year Club
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

14/44
How to earn trophies