Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - HillsofSilence

Pages: 1 2 3
Ask a Question / Re: Why is it when I Change my Sprite Animations...
« on: March 15, 2017, 09:22:06 am »
Sorry, I wanted to make a quick update on this, and make a little clearer the situation, here.

I forgot to add a while back that the character only slides down the slope when he's motionless, and when switching BACK to the previous standing animation upon contact. Otherwise, the conditions I coded for accelerated movement prevent this and the character only does the light skid of before I intended before stopping, which is coming from the movement acceleration/deceleration code.

Meaning, when the character is moving whilst jumping, and the movement keys are let off, I don't stop the actor in mid air, like in certain games like Super Mario World. Thus, when he hits the ground, he finally comes to a halt from the code pertaining to movement on the ground, just like in SMW.

So, in other words, the actor only goes all weird and becomes like Ice when jumping whilst standing still, and ONLY when switching to another animation. I checked everything, the groups and all, and I know everything is set up the exact same way. So, the question stands: is there a glitch in the way animation switching works, or what? Shouldn't only my code effect what conditions my actor takes on? If so, then why does merely switching to a similar sprite alter everything.

I must add that my character is set on 0 default friction and bounciness, and that this causes no problems on slopes when not switching back to the previous animation, but instead, keeping it the falling animation. Why does this happen? Please respond, as I feel this is a weird issue, and considering what games can be produced in the wild by Stencyl, I need to find the way to go about switching animations properly, or to ask someone to look into what I'm referring to.

Ask a Question / Re: Why is it when I Change my Sprite Animations...
« on: February 23, 2017, 02:41:08 pm »
EDIT: And, yes, they are set up all the same.

I don't think it has anything to do with the collision shapes, as my actor would probably fall through the floor if that were the case. Plus, its an added collision box for the falling animation, not a replacement one, which means the original collision for the normal tiles are still there, using the same group settings and conditions. And besides that, this was a happening even before I started doing the jump-through stuff.

So, is this a mess up on Stencyl's part, in terms of how it deals with animations and swapping them?

Ask a Question / Why is it when I Change my Sprite Animations...
« on: February 23, 2017, 12:52:42 pm »
So, its been a bit, and now i'm working on one way slope platforms, but something has been nagging me about changing the sprites.

For some reason, when I merely alter a sprite animation, to something like, say, falling, and switch back to the default standing animation, the friction turns off, and my character slides down the slopes. If I stop changing the sprite animation, this problem stops. But, here's the thing! Changing the animations shouldn't effect physics or friction whatsoever!

How can this happen, and how can I fix it?

Ok, so, I think I fixed this. I used a polygon and beveled the bottom and made sure the very top never touches, leaving a pixel or two wide gap. I also made edges so that, when falling off, the actors wont hit it like a normal wall. I accomplished this via making each edge actor and the player's new collision polygon a pixel tall triangle instead, so that, when moving forward, nothing collides due to the angle. And if something does collide, the slope mechanics of the 2DBox physics would automatically trigger, so the actors continue all the same, at the same pace like with any slope going with gravity.

...I run into a problem where, when using multiple 16 pixel wide actors, to replicate something like ground tiles (think Mario World's large jump through cliffs), the player actor will sometimes, though not always, stop at the edge of the next one, at the start of its bounding box and the end the last one. And I can tell because I put blue around the ends of each block, and the player actor always stops just short of the new actor's box.

Did any of you run into this problem, and if so, what did you do to correct it? Am I supposed to use a bunch of different actors and different widths, or can I actually use a bunch of 16 pixel wide actors to create larger ones? I'm going make these actors invisible eventually, and then use other means to create the graphics, like using boarder-less tiles.

So, to do jump through's, all I'm doing is an actor collision group trick, where, when falling, it switches over to an animation that has a group the jump through detects, and when landing on one, it just switches over to "jumpthough = true", which triggers the alternate versions of the remaining animations which have a new group that detects the jump-through. It works rather well, actually. That said, I'm pretty sure there is a way to merely create a new bounding box with said group, and then destroy it, depending the scenario, which does all this without the need of new animations. What's important is that, I'm not using any specific code, and this happens even if I switch the default animations over to the alternative one(s), and remove the animation switching code temporarily for testing. The platform is, as if, just like the tiles, solid and all, and there is no real coding, which means it hasn't anything to do with any jump through code itself. So, does any of you have a clue as to what's going on, or what I should do to fix this, save for just making longer platforms?

Thank you for your time!

Ask a Question / Problem with Moving Platform
« on: January 11, 2017, 03:52:13 am »
So, I was making a moving platform, and, I'm testing using multiple player actors, duplicated from the first one, so that I can quickly see what will happen when two or more of the same type of enemies colides, and, I starts noticing that, while one works perfectly, adding another begins to glitch one of them into sliding off the platform, as if double the speed has been given when the current hspeed + plat hspeed code is used. Then, more stuff happens, like one not moving when three are used. So the question is, how do any of you make moving platforms that work for when two or more of the same type of enemy is atop? I'm basically using a form of this guy's code in the last screenshot s here, at:,36138.msg204679.html#msg204679, only, I'm using the "for every actor type" loop, as I need it to work for more than just one actor using an actor attribute.

As for the other pic, the problem in using that is that not all of what his core code does is shown, so I don't know how to reconfigure it into code I can use right yet.

Ask a Question / Can Certain Actor Collision Boxes Detect Certain Tiles?
« on: December 12, 2016, 05:54:51 pm »
Yeah, like the title suggests, while you can have a character detect certain tiles using the metadata, can only certain collision boxes of an actor detect certain tile metadata? Like, one box will only detect the default block but another something like water or a slope?  Just wanted to know. A simple yes and no answer would suffice. Thanks!

Sort of, but not fully. Because my game is one where you decelerate by having the character simply slow in x-speed, then go to 0 when it hits zero (though it makes sure to check if it went beyond 0 too), i'm still trying to find ways to get it to work without stopping my character dead in his tracks. I'm using friction and x-speed changes based on event and x-speed stops, and it's actually working to a degree, I just need to figure out one or two kinks with it.

EDIT: Right now, my main problem is with hitting left and right together, which stops the character in his tracks all the same as just stop, correctly based upon the direction, and with attacking, as I already have that set up with a test sprite. I have no animation for the attack, so right now I have it set up where I hold down the button for as long as I like, switching to the recolored sprite for as long as I like, which allows me to test what would happen more thoroughly over longer animations. On flat ground, both events occur the same as when I stop, the character slowing to a complete stop. However, on the slope, I notice they still still very gradually begin to shift back down the slope per pixel until I just let off everything, as the remainder of everything seems to be fine.

EDIT: BTW, i'm also using values such as "slowingleft" and "slowingright" to signify when i'm in the slowing process. I'm trying to figure out what to do with this and, I think I may have now an idea. Again, if you have your own ideas, i'd love to hear them too.

Doing this via detection of the sprite seems like a good idea to get this done in a very simple manner, but, unfortunately, I having begun too extensively on graphics at the moment because I'm first trying to get a working engine up. I might just duplicate the current sprite and alter the color a little then so I can tell which is which, but otherwise, any ideas of how to do this without having to check for the current idle sprite animation?

Problem. Whenever I use the sensor, the "on ground"/"not on ground" text shows that i'm going in and out of the yes or no boolean here and there for some reason (though not normally on a slope, just oddly some times on even a single ground block tile or at its edge), no matter how big or tall the sensor collision is. This never happens when I just use the original collision box for the actor itself. What do you think the problem is?

EDIT: BTW, so far, I'm moving down and up slopes fine, it's just I'm still sliding down them whenever I let off the keys. I'll try to sort that out my own way, but if you or anyone has a solution, feel free to help out.

The secondary sensor doesn't really fix much. It's really a problem with how i'm trying to do the slope. That is, i'm turning on and off gravity once hitting the ground or a slope, which causes the actor to hop just a pixel too far, setting everything to no for a very brief second. It's very slight but annoying, and using the secondary actor actually makes this much worse, as it being below the actor or wider than the actor causes the actor to float up farther into the air before dropping as I move up it and remain in air a little before dropping as I move down it.

When I just deactivate all of that code and turn the actor's universal gravity back on, this never happens, no matter how large the secondary collision box is. It continues to say "on ground". However, now I slide down the slope gently and cannot walk up it for so long without being stopped dead in my tracks.

What should I actually do when the Boolean is set to yes, indicating i'm on a slope? I know I need to somehow turn off gravity or do something to prevent sliding, yet, at the same time, I need to allow the actor to smoothly walk up the slope as well.

I just went ahead and duplicated your last code, realizing from your post that, yeah, I guess I could do slopes that way. Of course, I didn't yet do the whole sensor collision and tile group thing yet, but the results are amazing so far. I don't slide down slopes anymore when jumping on them or moving up or down them!

Of course, my main issue now is that it flickers in and out of these conditions (I can see this because I have text drawn to the side of the actor if its hitting the ground or slopes), which gets in the way of jumping whilst on the slope. Some times he just wont jump because its no on "on ground" mode. Any fix for this? Will using the sensor and collision group change anything, or will I need to use your metadata matrix map method?

Thanks, but could you maybe elaborate on the bottom image's code? I couldn't find any of the blue blocks such as set Row/Column and the set Row/Column Adjuster. Are they a custom attribute? If so, could you elaborate on which attribute types everything is and also how you made them? I would like to copy what you have done perfectly, without any ill effects keeping going me at it forever in a loop. Thanks in advance!

Ask a Question / Re: View Port and Screen Changed with Update
« on: June 26, 2016, 12:00:35 pm »
Other users have reported this important bug.
We are waiting for a fix:
(see the yoplalala suggestion)

Ok, thanks for that. Hopefully it can be fixed soon. I'm wondering if there's a workaround for the moment, but, no matter, I guess i'll wait until the scale goes back to normal.

You can extend the logical function of collisions outside the actual collision event by making an attribute called [Collided] and setting it to True in the collision event. Then, set it back to false at the bottom of that actor's Always event.  Collisions occur first, so it works like this:

- Collisions Event  (set Collided = True if the actor collided with a tile)
- Always Event  (at the *end* of this event, set Collided = False, so that it defaults to false for the next logical frame, unless a collision occurs at the beginning of the next logical frame)
- Drawing Event (irrelevant to this example)

You can now use the Collided attribute you made to test for if a collision had occurred in the Collisions event *for the duration of the entire logical frame, referable from any actor or scene in the game*. Additionally, you now have a way to test for if "no collision occurred" (which can be very useful) since Collided will always reset to False at the end of the Always event. You could make different attributes to keep track of all the different things you want to test for in other events (was the collision with a tile? was it on the bottom? what was its collision shape ID?), just make sure you reset all of them to False (or -1 in the case of the collision shape ID) at the end of the actor's Always event.

For slopes in my game, I have created a "matrix" of tile metadata (stored as a map with keys such as 0-0, 0-1, 0-2, 1-0, 1-1, 1-2 etc ...) that keeps track of the tile metadata all around my main character at all times. It's very useful for smoothing out the character's entry/exit of slopes by being able to predict the next tile the player will collide with when approaching a slope or exiting a slope, among other uses.

Thanks for the input guys! So, if I want to do something outside of the collision event, I determine if something is colliding, then set it all to false at the end of the "when updating" event? Does that mean that, in order to determine if I'm hitting a tile or anything else, I use the general collision blocks in the collision tab, only now simply to change a Boolean from false to true?

As for determining whether or not I hit a tile or an actor, does that mean I make a Boolean like "tilecollide", which will activate if I determine it has hit a tile the normal way in the collision event, then switch "tilecollide" to false at the end of the "when updating" event with the rest of the other attributes at the bottom?

As for the  collision shape ID bit, I would like to know how that works in more detail. I want to know what Hectate was talking about in full about being able to achieve something like Castlevania staircases. And lastly, what do you mean by making a "matrix". What did you do to accomplish this? Thanks in advance.

Ask a Question / View Port and Screen Changed with Update
« on: June 25, 2016, 01:20:02 pm »
When Stencyl updated a bit back, I noticed I kept seeing that the game window or port going completely screwy. It only acts correctly when using 1x, but anything else, including full-screen mode, leads to strange results.

For example, in full screen mode, rather than enlarging the graphics alone, I can see a bigger portion of the map, like the camera has been zoomed a bit out. If I use 2x, then it gets really big and my graphics and everything is cut off from view, as if the camera zoomed in. If I double the port's resolution in the settings, my graphics don't get bigger, and I merely see 4x as much of the area.

I don't want this result, and it wasn't happening before I updated. What do I do to fix this?

Pages: 1 2 3