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 - Kajitii

Pages: 1 2 3 ... 13
Resolved Questions / Re: Character gets stuck halfway into floor
« on: March 22, 2015, 02:39:35 pm »
Found the problem.  Apparently the left idle animation has the point of origin at the top left.  Every other animation has the origin point at the center.  For some reason the idle left animation does not have the option to set it at the center.  Possibly a bug?  It is worth noting that not setting the origin point at the center will cause glitchy simple physics to occur.

I have deleted and recreated the left idle animation, thus re-enabling the ability to set the point of origin at the center.

Resolved Questions / Re: Character gets stuck halfway into floor
« on: March 22, 2015, 02:33:00 pm »
Enabling/disabling continuous collision detection has no effect, and probably so, since we're using simple physics.

Resolved Questions / Re: Character gets stuck halfway into floor
« on: March 22, 2015, 01:21:41 pm »

Resolved Questions / Re: Character gets stuck halfway into floor
« on: March 22, 2015, 12:41:19 pm »
There is only 1 layer in the scene.  Just for fun, I decided to put the player character on a different layer, and nothing different happened.

The player character was in the actors group (oops), which collides with tiles.  I changed it so that it is in the player collision group, which also collides with tiles.  But there's no difference in result.

Resolved Questions / [SOLVED] Character gets stuck halfway into floor
« on: March 22, 2015, 12:06:58 pm »
I am attempting to use simple physics for my scene and player character, and I am using one of the default behaviors (2 way horizontal movement).  But for some reason, when I move left, my character gets stuck halfway into the floor, which is 1 tile in thickness.  Both the player character and the tiles are 32x32, and modifying my player character's collision hitboxes don't seem to make the problem go away.

What could be the solution?

Resolved Questions / Re: Warning with tileset?
« on: July 13, 2012, 01:08:36 pm »
Oh okay does that go with all my images?

If they're vector images, then yes.  It sucks, but you can blame it on teknowojy.

Resolved Questions / Re: Warning with tileset?
« on: July 13, 2012, 11:46:01 am »
Try saving them as a bitmap before importing them?  The Flixel engine doesn't use vector graphics anyways.

Paid Work / Re: Beta tester available!
« on: July 12, 2012, 11:12:26 pm »
I didn't find any bugs.  But there really wasn't much to test in the first place.

A couple of suggestions:
-- Don't spawn enemies in places where they can damage the player uncontested.
-- Allow the player to drag and drop items wherever they want to.  It's a lot more intuitive.
-- Sometimes the floating text can interfere with each other.  It's not a problem this time because all there was to show was damage and level ups.  Simple enough.  But if you're going to add things like status effects or damage types, things can build up really fast.
-- Depending on how many different types of equipment there are, you might want to consider expanding the inventory.  I obviously didn't mind this time because there's only 4 unique pieces of equipment.  But it can quickly become a serious PITA if you're inundated with tons of different pieces of equipment.

As for your ideas, I prefer not to comment on them unless there's something that sounds really good.  It is one thing to have them on paper.  It is another to actually play the game and find out how it all plays out.

I also can't make accurate calls and thoughts on stat progression.  As it currently is, my thought was upgrading magic might be the best way to go early on, assuming it works just like LoL does.  But since I don't know how ridiculous the end-game stuff can get, I can't really say if it is ever worth pumping points into strength.  You'd have to invest a lot of points into strength to get any meaningful damage out of the rusty sword.  On the other hand, it has ludicrous returns on stuff like the Sword of Badabing.  But if the end-game stuff only has a base damage of 500, I might think twice about putting points into strength.

Ask a Question / Re: Set Something's Speed
« on: July 10, 2012, 03:01:01 pm »
If I'm understanding your problem, disable gravity.

Alright, first thing's first, if you have 20 or more actors on the scene, it'll start to lag pretty hard.  I suggest looking at Abigayl's virtually lagless actors tutorial to overcome this problem.  It basically comes down to using one actor's frames and drawing it all over the place to simulate hundreds of actors.

You definitely can randomly remove actors.  Or at least give the appearance of it doing so.  Use a list that defines the actor's opacity, and another list that holds booleans.  What we want to have happen is that the opacity tick down from 100 to 0 if the boolean is set to true.

We only need a one-dimensional list to represent a rectangle, although you'll have to know what the dimensions of the rectangle is.  Though it can be done with two-dimensional lists as well.  While the latter looks a lot cleaner and easier in code mode, it is a gigantic cluster of confusion in design mode.  Ugh x_X  Anyways, with the former, each spot on the list represents (y*width + x), where y = 0 represents the top most part of the rectangle, x = 0 represents the left most part of the rectangle.

To handle ticking down opacity, we just use an always event.  It will loop through all the items in the boolean list.  If the item is "true", then it will subtract 1 from the same index of the opacity list if it isn't 0.  You can control the speed that the actors are fading away by tinkering with the amount the always event subtracts from the opacity.  Always code will typically run at 100 events per second.  So using my example, your actors will disappear within 1 second.

To handle getting the actors to randomly disappear in the first place... well, this is the challenging part.  I've made a stab at the problem.  But it seems to me that the actors are disappearing in groups.  But if you don't care about having a highly random disappearing act, then it is passable.

Ask a Question / Re: Help with memory game
« on: July 10, 2012, 10:23:36 am »
Loops are something that execute the logic within them multiple times.  How many times exactly?  That depends on the conditions.  These things can be found under Flow --> Looping/Time.

For the standard loop, it repeats the logic for however many times you tell it to.  This can be a static number like 10, or it can be the number of items currently in a list (which may change while the loop is running).  In addition, this loop has an index, or a number that says how many times the loop logic has executed.  In designer mode, this is the green thing called "current loop count".  So if the logic has run successfully 5 times, the index will be 5.  Caution: indexes start at 0, and for the purposes of loop logic, will never equal the number of times you tell it to execute.  The index number will go up by 1 when it reaches the end, regardless of what happens in the loop logic.

The other two loops, the while loop, and the repeat until loop, are trickier.  They keep executing the logic in the loop until the specified condition becomes false, or you tell the computer with logic when to stop with the stop block.  And unlike the standard loop, there's no index number associated with these loops.  If you need an index number, you'll have to define your own attribute.  Warning: when the computer reaches a while or repeat until loop, it will only run through the loop and nothing else until the loop is resolved.  If it never resolves within the loop, you effectively froze your game.

I've attached an example while loop from my game below.  Basically, generate a random number between -5 and 5 inclusive, but if you randomly generate 0, try again.

Another loop type available in Stencyl is the time loop.  It is similar to the while loop, except it executes its logic every X seconds, and it doesn't hang up the computer while it is running (unless you put in a while loop that doesn't resolve).  To get it to stop running, you can either switch scenes, or use the cancel block.

This is as of Stencyl 2.1.  The amount of glitches I'm hearing about 2.2 scare me into not updating, since I already have enough to deal with.

Anyways, I programmed the ability to swap your controls in the options screen.  To do that, I have control attributes that are set to control set 1 if a boolean is true, and set to control set 2 if the same boolean is false.

Since my game is still a WIP, I still had additional functionality that I wanted to include.  If I add X amount of controls, all the control attribute setters screw up and point to something X amount further up the list than the originally assigned control.

For example, I have controls up, down, left, right, Z, X, and C.  Control attribute cJump is assigned to Z.  If I add esc as a possible control, cJump is now assigned to right instead of Z.  If I add yet another possible control, cJump is now assigned to left.

Ask a Question / Re: Tracking an actor from one scene to the next
« on: July 09, 2012, 09:56:08 am »
Actually that would work perfectly for your purposes, just as long as you can rely on behaviors and the actor's events alone and don't need attributes saved from the previous scene.

However I have never used it, so I don't know what "curses" it might bring, if any.

Resolved Questions / Re: object AlchemyExit issue
« on: July 09, 2012, 09:42:13 am »
Oh for crying out loud...

There was a time when Stencyl started acting strange and "forgot" a few things.  I originally chalked it up to complex software being complex and just moved on (being cautious and backing things up of course).  That included the behavior screen for buttons showing up completely white, except the left pane.  Evidently this glitch spree got more than just my buttons.

Thanks for the help, level runs beautifully.  Mystery solved!

Ask a Question / Re: Lives Counter
« on: July 08, 2012, 09:23:21 pm »
I'm not seeing any strange issues with those behaviors.  Checklist time!

-- Make sure that the actor is within the screen when it is anchored.  To run a simple test to absolutely get this to happen, on creation, set your actor's x and y to (camera's x + 15) and (camera's y + 15) and immediately anchor to the screen.
-- Make sure that lives is not set to 0.
-- Make sure that the actor's sprite is set to show itself.
-- Make sure that the scene's events or some other code from a different behavior isn't causing the lives counter to disappear.  This one is vague, but that's the nature of programming =/

Pages: 1 2 3 ... 13