Mithrill's Recent Forum Activity

  • Hello everybody,

    I have an question to ask.

    Let’s say I have a sprite object called Sprite1. It’s collision polygon is smaller than image itself. Now I want to create another sprite object called Sprite2 on top of Sprite1.

    Next, I want to set size of Sprite2 depending of the collision polygon size of Sprite1. First I thought that setting Sprite2 size by using expression Sprite1.BBoxTop etc. values but it turn out that they refer to the image’s bounding box, not collision polygon bounding box. Which makes totally sense now I think about it :)

    So my question is: is it possible to set size of sprite object to match the collision polygon size of another object?

    -M-

  • R0J0hound, Thank you for your examples! I appreciate your effort and help.

    Actually, I already knew about that wallcrawler3 example :) I have also implemented that into my game. Sadly, there is also a problem. Those wallcrawler3's are moving 8 pixels above the ground object. I have tried to tweak them but I can't manage to make them to move on the correct hight. I think it's because of two reasons: 1) the grid size (16x16), is messing with wallcrawler3's origin point. 2) wallcrawler3's origin point is in the middle of sprite. Ground object's origin is in top-left corner. I think one of or both of those reasons are causing that 8 pixel offset. Not sure though.

    Here is an example. Blue arrow is indicating wallcrawler3's top part (head :), NOT movement direction.

    h*t*t*p*s://www.dropbox.com/s/4x059rqqa8g67l3/wallcrawler3.png?dl=0

    Both of those wallcrawler4/5 examples are so simple :) They also make me realise how I could reuse the same boolean to work with multiples conditions! So thank you for pointing out that ^^

    Those examples gave me so much new ideas that now I know what to do today :)

    -M-

  • Nice! Thank you ^^

  • Hi everybody,

    I created a wall crawler enemy for my game. Enemy can move on the ceiling, wall and floor. Nothing special here. The reason why I’m writing this post is that I have a really odd problem with the enemy collision checks. Well, I think it’s because of collision checks. Not sure though.

    First, a quick preview how everything is set up. There is a GroundChecker -sprite under the enemy. This sprite will check when enemy is on top of something and vice versa. So this sprite controls the positive corner rotations (sort of descending the wall). When enemy is not overlapping the ground, rotate it to the direction of the enemy’s movement.

    There is an another sprite called WallChecker. This sprite will check when enemy is next to a wall. When it is, rotate enemy to the correct direction. Again depending of the movement direction. This sprite controls the negative corner rotations (sort of climbing the wall).

    This is the basic logic. Problem is: when ever the enemy cross a seam of 2 sold blocks, it will get stuck. Sometimes it will break out from this state and continue to move forward but most of the time it will just twerk in place. I think, I THINK it’s because of the GroundChecker collision checks. So when GroundChecker is overlapping the ground and then move a cross of the seam of 2 solid grounds, it will think it’s not overlapping the ground. In fact it is, but because there was that seam, GroundCheker thinks it’s not overlapping the round and tries to rotate the enemy. Of course this will cause some problems to collision checks. But to me that sounds so odd because GroundChecker is STILL overlapping the ground. There was just that seam between 2 separate ground objects. Like I mentioned, I THINK this is the problem. It could also be that some events are causing this odd behaviour. I wouldn’t be surprised if that turn out to be the case :)

    I included .capx file so everybody can check out in details the events. The enemies which are causing me the problems are marked as nb: 2’s.

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/Scirra%20forums/wallcrawler/wallcrawler_gravity_based_instant_rotation_r227.capx

    Any kind of constructive help is highly appreciated. If there is something in the capx -file that you can’t figure out, let me know.

    -M-

  • Problem Description

    After exporting project to NW.JS or html5, pixelate effect is broken. In preview mode it's working correctly but after export, sprite becomes pixelated even before effect amount/value is increased.

    Attach a Capx

    h*t*t*p*s://www.dropbox.com/s/sqxfif4lwhgvs35/pixelate_effect_problem_after_export_r227.capx?dl=0

    Description of Capx

    Contains a sprite with pixelate effect attach to it. Use X key to increase amount of pixelate effect. Use Z key to decrease the same value.

    Steps to Reproduce Bug

    • export to NW.JS
    • go to folder created during previous step
    • launch nw.exe
    • press x key to increase pixelate effect value
    • press z key to decrease pixelate effect value

    Observed Result

    On start of layout in NW.JS, sprite is already pixelated even before pixelate effect value is increased. To me it looks like pixelate effect value is at least doubled on start of layout.

    first state In preview (pixelate effect value is 1):

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20first%20state%20in%20preview.jpg

    second state In preview (pixelate effect value increased a bit:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20second%20state%20in%20preview.jpg

    last state In preview (pixelate effect value is maxed out to the cap):

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20last%20state%20in%20preview.jpg

    Below are the results after exporting:

    First state (pixelate effect value is 1):

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20first%20state%20after%20export.jpg

    Last state (pixelate effect value is maxed out to the cap):

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20last%20state%20after%20export.jpg

    Expected Result

    Pixelate effect not to be applied to the sprite on start of layout.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (untested)
    • Internet Explorer: (untested)
    • NW.JS (YES)

    Operating System and Service Pack

    Windows 7 Professional SP1 32-bit running through vmware Fusion 5.0.5 (1945692) on Mac OS X 10.9.5.

    Construct 2 Version ID

    r227 32-bit

  • R0J0hound

    I made a test with the pixelate effect like you suggested. I even installed a fresh copy of C2. Again like you mentioned, to make test with a vanilla version. Then I only installed your outline effect. Results: pixelate effect is also broken after exporting to NW.JS. I also exported to html5 and effect is broken. In preview pixelate effect is working but after export, well, see yourself:

    first state In preview:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20first%20state%20in%20preview.jpg

    second state In preview:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20second%20state%20in%20preview.jpg

    last state In preview:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20last%20state%20in%20preview.jpg

    Below are the results after exporting:

    First state:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20first%20state%20after%20export.jpg

    Last state:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20last%20state%20after%20export.jpg

    Maybe I should post a bug report?

    -M-

  • R0J0hound

    Thank you for making this nice effect available :)

    Sadly, I ran into a problem. After export, outline is all messed up. I'm using NW.JS v0.15.0 and Construct2 r227.

    Outline in C2 NW.JS preview:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/outline/in%20preview.jpg

    Outline in NW.JS after exporting

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/outline/after%20exporting.jpg

    I even made a plank project to see if I could reproduce this problem. Well, same problem occurred after export. Any idea what is causing this? Or how I can fix it?

    -M-

  • What is the positive value? At the size or somewhere else ?

    Sorry I kindaa confuse what yur question is

    + Bigger - Smaller

    I checked values in debug-mode and I found out that when sprite is mirrored it's width is negative value and when it's not mirrored same value is positive. Then, when sine behaviour is activated it will set sprite's width value to positive regardless of mirroring / not mirroring. Other words, sine will set sprite to not mirrored even though it's mirrored.

    Here is my original post:

    h*t*t*p*s://www.scirra.com/forum/viewtopic.php?f=147&t=177622

    -M-

  • Problem Description

    Toggle bookmark shortcut key is disabled and can't be used to type in editor.

    Attach a Capx

    h*t*t*p*s://www.dropbox.com/s/55wtmldyt5rfji1/toggle_bookmark_key_disabled_r227.capx?dl=0

    Description of Capx

    Contains a sprite object which is called sprite (creative, eh...).

    Steps to Reproduce Bug

    • go to: customize quick access toolbar / more commands / keyboard shortcuts: customize.
    • go to: events / toggle bookmark
    • sign "h" key to toggle bookmark shortcut key.
    • click close
    • click Ok
    • go to layout 1
    • click sprite object and rename it to "hero"

    Observed Result

    "h" key is disabled. Only "ero" can be typed.

    Expected Result

    be able to type "hero"

    Affected Browsers

    • Chrome: (NO)
    • FireFox: (NO)
    • Internet Explorer: (NO)

    Operating System and Service Pack

    Windows 7 Professional SP1 32-bit running through vmware Fusion 5.0.5 (1945692) on Mac OS X 10.9.5.

    Construct 2 Version ID

    r227 32-bit

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Problem Description

    When sine behaviour is used to set the width of sprite object, it will always return to positive value after "on landed" -event.

    Attach a Capx

    This example is mine:

    h*t*t*p*s://www.dropbox.com/s/8fxwib0eri1a8pr/squash%20and%20stretch%20demo%20r227.capx?dl=0

    This is example from Kyatric :

    h*t*t*p*s://www.dropbox.com/s/f2uxrxf8hbti361/sine_width_unmirror_r229.capx?dl=0

    Description of Capx

    I want to squash and stretch player sprite after "on landed" -event. I'm doing it with 2 sine behaviours, WidthSine and HeightSine. "on landed" -event will activate both sines.

    When player is not moving and lands on ground, sprite goes from mirrored to not mirrored when sine behaviour is activated. When sprite is not mirrored everything works fine. Also, this problem only occurs when player is not moving. If player is moving, then mirroring will work.

    Steps to Reproduce Bug

    • press left (player will turn left (is mirrored))
    • jump
    • wait player to land

    Observed Result

    sprite go from mirrored to not mirrored.

    Expected Result

    sprite stay mirrored.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (YES)
    • Internet Explorer: (YES)
    • NW.JS: (YES)

    Operating System and Service Pack

    Windows 7 Professional SP1 32-bit running through vmware Fusion 5.0.5 (1945692) on Mac OS X 10.9.5.

    Construct 2 Version ID

    r227 32-bit

  • Thank you Kyatric for you quick reply. I will post a bug report right away I also found a workaround how to fix that sine behaviour. Check my first post for details.

    -M-

  • Hi,

    Currently I'm trying to make player sprite to squash a bit on landed. I'm doing it with sine behaviours. There are total of 2 sines, WidthSine and HeightSine. "on landed" -event will activate both sines.

    The problem: when player is not moving and lands on ground, sprite goes from mirrored to not mirrored when sine behaviour is activated. When player sprite is not mirrored everything works fine. Also, this problem only occurs when player is not moving.

    I checked values in debug-mode and I found out that when sprite is mirrored it's width is negative value and when it's not mirrored same value is positive. Then, when sine behaviour is activated it will set sprite's width value to positive. Other words, that will set sprite not mirrored.

    Is this a bug in sine behaviour? Kyatric, , Ashley

    If not, how I prevent sprite/sine from mirroring unintended way?

    Here is an example: h*t*t*p*s://www.dropbox.com/s/5cn6hl1fiwc29rj/squash%20and%20stretch%20demo.capx?dl=0

    -M-

    EDIT:

    I found out what is the problem. Apparently the problem is vectorX check. How I fixed it: I Made a global variable "Facing_Direction" and when VectorX is less than 0 -> set Facing_Direction to "left". If it's greater than 0 - > "right". Then I added events: Facing_Direction is "left" -> set sprite mirrored and vice versa.

    Now, on landed will trigger both sine behaviours and they work like intended

    Last thing I needed to add was to set correct size of the sprite object. I made that with function.

    If anyone is interested to see the result, here it is: h*t*t*p*s://www.dropbox.com/s/hliduujttc7j9jn/squash%20and%20stretch%20demo2.capx?dl=0

    -M-

Mithrill's avatar

Mithrill

Member since 17 Jul, 2014

None one is following Mithrill yet!

Connect with Mithrill

Trophy Case

  • 10-Year Club
  • RTFM Read the fabulous manual
  • Email Verified

Progress

12/44
How to earn trophies