Greaver's Forum Posts

  • Hehe hey there! ^_^

    So we know that all objects must be placed out already for C2 to load them (On create).

    But is this once upon a save or is it for every time the player launches the game?

    (Ie, should all objects be placed out on the main title screen for every launch, or every loading screen, or is it enough once like the first starting area? Since rest of the game isnt affected by it?

    Thanks for the help! ^_^

    - All the best!

  • Hey there!! I have C2 and would like to try C3. Do i have any discount??

    Thanks!

  • Greetings there people!! ^_^

    So i have C2 and was thinking of buying C3!

    No company as of yet, no income, however i was planning to release apps on the store. Open buisness later.

    Is this OK for individual license? Or do i have to get buisness license???

    Thanks for the help!

  • > Hehe hey there! ^_^

    > So basically i have made a config ingame to edit buttons. However i noticed that 'Keyboard' and 'Gamepad' are seperated.

    > Is it not possible to make a same keycode for both? Ie, instead of making it;

    >

    > UP Arrow pressed

    > OR

    > Gamepad Up arrow pressed

    >

    > To make it into = When Keycode is pressed. (No matter if gamepad or keyboard) ?

    >

    This isn't possible. Controllers don't use keycodes like keyboards do, they use button IDs.

    Thanks for clarifying this - so basically i need to make a key config, 1 for keyboard and 1 for gamepad.

    Then the entire controller unit must be 'when keycode (keyboard pressed) OR keycode (gamepad pressed)

  • Hehe hey there! ^_^

    So basically i have made a config ingame to edit buttons. However i noticed that 'Keyboard' and 'Gamepad' are seperated.

    Is it not possible to make a same keycode for both? Ie, instead of making it;

    UP Arrow pressed

    OR

    Gamepad Up arrow pressed

    To make it into = When Keycode is pressed. (No matter if gamepad or keyboard) ?

  • Aww it doesnt have 'play at object', darn it! ^_^

    Oh well, was fun trying this atleast. Just not quite usable ^_^

  • Bump?

  • Hello there!

    Basically when u force move the 'Character' Left or right, it has a bug. Aslong as its going right it stops at obstacles, but whenever its going left, it starts climbing up the obstacles.

    Its not only on set position, but the same thing happens on bullet effect.

    CAPX sample http://www.filedropper.com/testd

    Press D untill u go left (mirrored) and see how it goes UP the obstacle with small jumps. Also happens with bullet effect.

    Here is bullet CAPX - http://www.filedropper.com/testleftandright

    Use left or right arrow. NOTICE how using left arrow makes it climb up the wall obstacles. Why is this?

  • Hi,

    Ok, sorry, so I checked and played around with your Capx and this is my feedback:

    1) Your Sprite has Platform behavior and when using Arrow keys it behaves correctly (no jumping).

    2) If using the D key as per your event the "jumping effect" occurs. I checked all collision lines and tried variations with other solid objects and in all cases the "jumping effect" happened.

    My conclusion / advice to you:

    I believe this effect happens because you are using the Move Forward action which "teleports" your Sprite 4 pixels into the solid object but since it cannot be inside a solid object there seems to be a push back effect which we see visually as "jumping effect".

    To move your sprite you should not use such "teleportation" of X pixels, but you should simply say, if you do not wish to use Arrow Keys, on D key down SIMULATE CONTROL (under Platform) and choose Left if you want it to go left or right if you want it to go right, etc.

    Good luck

    Hello again - bullet has the same effect. Aslong as the character is going left, it will climb over obstacles.

  • Hi,

    Ok, sorry, so I checked and played around with your Capx and this is my feedback:

    1) Your Sprite has Platform behavior and when using Arrow keys it behaves correctly (no jumping).

    2) If using the D key as per your event the "jumping effect" occurs. I checked all collision lines and tried variations with other solid objects and in all cases the "jumping effect" happened.

    My conclusion / advice to you:

    I believe this effect happens because you are using the Move Forward action which "teleports" your Sprite 4 pixels into the solid object but since it cannot be inside a solid object there seems to be a push back effect which we see visually as "jumping effect".

    To move your sprite you should not use such "teleportation" of X pixels, but you should simply say, if you do not wish to use Arrow Keys, on D key down SIMULATE CONTROL (under Platform) and choose Left if you want it to go left or right if you want it to go right, etc.

    Good luck

    Im using this D for a dash effect. There is no simulate left or right when it comes as an additional option dude.

  • Capx has been added.

  • Hi,

    1) Based on your description, you have a lot of errors in your design.

    In order for anyone to give correction feedback you would need to share your design or at least more details related to movement.

    2) In your movement description there is absolutely nothing about climbing as you can see. If you would open a brand new project and put only that event then it will do as described.

    No, it will climb. That is the problem. Try it. Keep D down untill u hit a wall.

  • Hello there! So basically, either there is a huge bugg in C2 or something is wrong here.

    ''When D button is down''

    -If Sprite is mirrored -> Sprite move forward 4 pixels

    -If Sprite is NOT mirrored -> Sprite move forward -4 pixels

    So. When the sprite moves forward 4 pixels its perfect and it stops at obstacles. However;

    when the SPRITE is moving -4 pixels (backwards) It starts climbing up obstacles, what gives?? Bug or? Same thing happens with 'Set position to Sprite.X-2'' - it starts climbing up obstacles like walls....

    Anyone?

    EDIT Capx for u to try; http://www.filedropper.com/testd

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I've made a complicated input system before.

    The basic idea, at least behind how I did it, is that you record inputs (e.g. in a queue) and every X seconds, read those inputs and have an action occur because of it.

    The input window should probably be around .10-.15, if it's too small then what happens is, let's say you need to press A and B at the same time, or Down on a control stick and the X button at the same time, if they aren't on the EXACT same frame and you just do a check, it won't work.

    If you do stuff like wait commands, it can get a bit messy when people press multiple buttons at once, among other scenarios... maybe it can work but I don't think I even tried, I couldn't really imagine how it would.

    For reading inputs, you probably need to differentiate between directions and buttons. So you don't just want to say "what was the last button pressed", but more like, "what were the last 3/4 directional inputs, and the last 2/3 button inputs, and in what order".

    That way you can see, okay, they did down, down-right, and right, in that order, this is a quarter-circle forward, and then they pressed B and A, well A was the last input so we take that one. Or maybe you want them to press two buttons at once, so you can read that, or maybe you only take their first input. There are lots of different possibilities.

    Rather than a wait command, I would start a Timer whenever an input is received (again, for maybe .10 seconds, it means there is a small delay on the inputs but it's almost unnoticeable and even professional games can have small delays like these), and then once the timer is done, you read the inputs.

    Another thing is that, instead of doing:

    "on press A, do this"

    "on press left and A, do this"

    "on press right and A, do this"

    "on press B, do this"

    "on press left and B, do this"

    "on press right and B, do this"

    you now have

    "on press A, record A"

    "on press B, record B"

    "on press left, record left"

    "on press right, record right"

    Read/execute input one time.

    You see how I reduced 6 checks (redundant left/right input checks) to just 4? And the more you have the more the reductions add up. Then you only need to check for each button input once, and you just have an I/O-like system to do things based on the inputs.

    Coding it can be a bit difficult but it's part of game development/programming in general (C2 might not be script-based but programming knowledge is still extremely useful, if not basically required IMO, at least for more complicated things), action/fighting games can be especially hard in this sense, so yeah. Good luck if you choose to try it.

    So this will be harder than what we had thought xD

  • Haha, I learned how to fix the timing.

    RyuCommand > 0 -> Wait 1.5 seconds -> set RyuCommand to 0

    I just learned about the System's Wait action, very handy.

    Again, I'm not experienced so this may be a bad way to do it. And of course you wouldn't be able to make a big roster of fighters using events like this when you're limited to 100 events. But hopefully you can work with this.

    EDIT: Just noticed that Hadouken still spawns a slow bullet too, because the condition for bullet is "On P pressed". So I also added the condition "RyuCommand smaller or equal to 1".

    I see, thanks for the response ^_^