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

Pages: 1 2 3 ... 62
Just wanted to say keep up the fantastic work! I'm really looking forward to seeing the progression of this game and I think it is exactly what Stencyl needs to prove to the world what capabilities it has and what can come out of it if you really focus your time and energy on making a game. I also wanted to let you know that I voted for it on Steam Greenlight. It's actually the only game I ever voted for so I really wish you luck!

Chit-Chat / 2/3 of mobile free to play gamers quit within 24 hours
« on: April 10, 2014, 05:55:00 am »
I'm on break at work so I can't respond to this fully, but I thought it was worth sharing as a discussion for creating more engaging games and increasing the percentage of those who spend money on games. I find the numbers interesting but not very surprising. What are everyone else's thoughts?

P.s I'm on my iphone so it is a mobile link

Ask a Question / Re: Unreliable Score Counter
« on: April 09, 2014, 07:53:33 pm »
It's likely registering the collision twice. If it is it might be better to have a Boolean that if not set to true will allow the code to run. So it could be like this:

When this collides
If collected is not true
Then set collected true and kill self and add to score

Ask a Question / Re: Draw a curve from a list of points
« on: April 09, 2014, 05:14:56 pm »
there is no "draw curved line" block, aside from using code and figuring out how to do it on that level, the alternative would be to use the "draw line" block under when drawing event. Given enough points on the line, it should appear to be a curve without actually being a curve.

Ask a Question / Re: Actor-tile side collision
« on: April 09, 2014, 04:48:27 pm »
collision blocks also can't be used in the "always" wrapper. They have to be used under the "when colliding". You can go with photons method, or if you don't want to, you can have the coins register the collision and be "collected". You could also have the player actor do the same. If you want to filter out what collisions are okay and what ones will cause the player to fall in a pit and die, use collision groups. Every time a collision registers, check to see what group the colliding object is. If its something that is okay to collect then don't respond, but if not, then set the actor's y speed to what you want.

Ask a Question / Re: Actor-tile side collision
« on: April 09, 2014, 02:24:13 pm »
it would be helpful to know where that behavior above is being attached. If its to the actor that is moving to the *right* then why would you be checking if it was hit on the *Left*? Shouldn't you check to see if it was hit on the right? And the otherwise if block really isn't necessary if you've already set the actor speed elsewhere.

Also that collision check should be done using a collision event not the always event.

Ask a Question / Re: Frame Refresh vs Logic
« on: April 08, 2014, 06:09:27 pm »
It is also very possible that the first actor that kills itself executes code in the background which actually removes itself prior to the other actor executing its commands. As a result of this, if it runs that code and removes every known instance of itself from the tree, then it no longer exists in the collision list for the other actor.

Think of it in terms of this:

Bullet hits enemy.
Enemy registers collision and executes kill self command.
Engine then proceeds with the killing and removes that actor from the tree including the collision list.
Bullet now runs it's code.
Whoops bullet appears to not be colliding because the command to kill self for the enemy was executed and the killing occurred in the same frame thus removing it from the list.

I'm not 100% if that is how the engine operates, however, ideally it would work the opposite where the actual killing of itself occurred the following frame, allowing for any other references to the instance to continue executing their commands should there be any.

It's possible, that if the engine works using the former method, that it is done that way due to the limitation of a specific platform or two. I know in flash GC is done on the following frame, so it allows references like this to continue completing their tasks on the current frame.

The question is rather vague. In the literal sense it is easy to do. Set one actor to have an x speed in the negative direction(left) and the other a positive x speed(right), or you could push with force in xDir -1 (left) or xDir 1 (right). I assume however that is not really your question so I will ask, under what circumstances should this situation occur?  I.e. Is it when a certain event happens, or a button is pressed, or do they always move back and forth in opposite directions?

Explaining in more detail what you want to accomplish will get you the answers you are really looking for.

Resolved Questions / Re: Add a choose actor for block
« on: April 08, 2014, 02:36:03 am »
The reason it is only available where it currently is, is because choose actor is referring to an *instance* of an actor which is only available when the actor is physically placed in a scene. Hence, scene behaviors/events being the only place for them. If it was available on an actor behavior it would mess things up when it's used on an actors that isn't in a particular scene or isn't created until some action occurs in the scene.

That is why attributes are required and why it's necessary to use a for each actor of type block on occasion.

Resolved Questions / Re: cannot generate swf files!
« on: April 06, 2014, 12:31:14 pm »
I can't take too much time to troubleshoot this, have to leave for work shortly. But a quick google search of this: wrong ELF class: ELFCLASS64 led me to information showing its a linux issue. Are you running linux? If so do you know if it is 64bit or 32 bit? and if you do know did you download the appropriate version of stencyl?

I got that info from in the logs here:

Code: [Select]
[LOG] Uncaught exception - load.c(232) : Failed to load library : /home/chris/Desktop/STENCYL/Stencyl-full/plaf/neko-linux/std.ndll (/home/chris/Desktop/STENCYL/Stencyl-full/plaf/neko-linux/std.ndll: wrong ELF class: ELFCLASS64)
[LOG] Uncaught exception - load.c(232) : Failed to load library : /home/chris/Desktop/STENCYL/Stencyl-full/plaf/neko-linux/std.ndll (/home/chris/Desktop/STENCYL/Stencyl-full/plaf/neko-linux/std.ndll: wrong ELF class: ELFCLASS64)
[LOG] Finished building for Flash (or errored out): 1
[LOG] Running SWF: /home/chris/Desktop/STENCYL/stencylworks/games-generated/ONE EMPTY SCENE/Export/flash/bin/ONE EMPTY SCENE.swf inside /home/chris/Desktop/STENCYL/Stencyl-full/ext-tools/players/flash-10-linux
[LOG] Error: Invalid SWF file name
[LOG] Action: Generate Logs

It'll be a few days before I can access a computer. I'm on my iphone now and I work 12.5 hr shifts an hour away from home so I won't be on the computer till Tuesday.  Some pseudo code would work like this though:

[when created]
LastX = x of self
If x of self  > LastX then
Increment "distance right" by x of self - LastX
Otherwise if x of self < LastX then
Increment "distance left" by LastX - x of self

For time tracking if using a basic counter and not tracking step size it would look like this:
[when created]
Counter = 0
Seconds = 0
Minutes = 0

Increment counter by 1
If counter = 60 then
{Increment seconds by 1
Counter = 0}
If seconds = 60 then
{Increment minutes by 1
Seconds = 0}

If using tile API then every time the tile moves in left/right direction equal to the tile width you would add the tile width to that directions counter.

If using the step size you would add the step size every frame and then if the counter equals 1000 or greater increment seconds by one and reset counter to the difference of itself and 1000.

Keep in mind the first timer assumes u are always running at 60 fps.  Otherwise if u run at less, then the always won't run that often causing a difference in ingame time and real time.

You need the tile API if you plan on using tiles on a never ending scene. You then need to constantly update the tile positions so it appears as though you are moving in a certain direction while leaving the player standing still.

As far as the counter goes. If the player actually moves, you would keep track of the x position of the player. Any time it increases that would add to the right counter.  If it decreases that would add to the left counter.  If the player does not mover and you update tile positions then you would add to the counter every time the player advances a tile same with subtracting.

As far as time goes you would use a counter to keep track of time always updating the counter. There's a caveat though, if the frame rate drops it would affect the counter and not be accurate. Therefore, the best method of tracking time is using a code block to access the step size value of box 2d as this will vary frame to frame. Adding this value to a counter would be the most accurate method of tracking time.

Suggestion Archives / Re: Tiles being sensors
« on: April 05, 2014, 07:44:22 pm »
If you're looking for a responsive effect that deals x damage or what have you, creating those tiles with no collision bounds and then putting a region over top would be the best option. If you're looking for some sort of buoyancy then sensors would not be the best option at all.

well from what I can see in the above code, it all looks good, as you said though C++ might shift things a few lines when converted. I recommend what rob said and disable parts of the behavior to isolate where it is being thrown. Seems like its relating to the sections with the "Get XP Cost" custom block. So I would start there.

Empty out each "when this hears" except one, verify if error thrown. If so remove that one and check again if so, then it's elsewhere, if not, then slowly put back each piece until the error is thrown, that's where the problem is.

Edit: you might also want to verify if the Custom block utilizes any code mode blocks, etc. It might actually be that the behavior with the custom block is the root cause.

Edit: Erp. No that custom block is contained in the same behavior lol. Still recommend doing the above though.

if you preview the code, granted it would be in haxe, not C++, and look for line 76, what is on that line? Perhaps, we would find the part of the code that when converted to C++ isn't being converted properly. Given the fact that you're compiling to android, a platform obviously not compiled to a regularly as say flash or maybe even iOS, that specific block causing the problem would very likely be something engine side that needs to be fixed.

Pages: 1 2 3 ... 62