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

Pages: 1 2 3 ... 13
Ask a Question / Re: Is this a bug in Stencyl? [Windows]
« on: June 06, 2020, 05:35:44 pm »
So I removed the "Do After" wrapper, and all turrets fired correctly similar to the "For each" loop method. Strangely enough, if I split the 4 turrets and have them fire in groups of 2, they still function as intended. It's only when I have them fire one at a time with "Do After" blocks does this inexplicable behavior occur.  You said that attributes can change their values before the code executes, but I'm actively drawing each attribute involved directly on the screen. None of their values are visibly changing. As far as the code tells me, each actor attribute is correctly set to their corresponding turret, and placed into the C-section list.  What shocked me was that even [X of actor] reported the value for a different actor. . . WITHIN the actor it was executed in.

This is the entire code of the C section . Ignore the code related to the Power Unit and Central core, as they have nothing to do with the issue nor do they affect the turrets in anyway. There is an update event for the turrets that sets the position of the laser actor, but this was removed for debugging, so the only thing that's left is the Custom Event "Fire".

Why would the "Do After" wrapper cause values to change?

Ask a Question / Re: Is this a bug in Stencyl? [Windows]
« on: June 06, 2020, 07:21:02 am »
Thanks for the suggestion. I tried it and unsurprisingly the issue still persist. For test runs where triggering Fire on turret C1 would trigger on C4 instead, I tried a new means of troubleshooting where I had each turret create the laser actor at their exact X position, and added the following to the event Fire.
Print: self
Print: X of self
Print: X of the laser actor
I then had each turret fire in this order: C4 -> C3 -> C2 -> C1

So apparently, when triggering the event does do something, Turret C1 seems to assume the properties of Turret C4. I don't know what to do or think at that point, because that completely defies logic with no explanation. No matter what information I get, no matter what blocks I put in, it doesn't change the fact that C1 miraculously thinks its C4, or sometimes thinks it doesn't exist at all.

Ask a Question / Is this a bug in Stencyl? [Windows]
« on: June 05, 2020, 07:36:31 pm »
I have four actors (turrets) in an initialized list that all have a custom event with the same name that makes them  fire at the player.  For some bizarre reason, the 1st actor at the start of the list refuses to execute it. There is no error during runtime, nor can I print from the dysfunctional actor because the event is never called. The literal code line"actor.shout" is completely ignored on the 1st execution or is called on the wrong actor (which behavior that occurs has been random throughout identical test runs). It's only when I try triggering this event from a "For" loop that each actor fires correctly at the same time, and then suddenly they will correctly fire in order from C1 -> C2 -> C3 -> C4  from the original timed-event code only once, before returning to C4 -> C2 -> C3 -> C4 forever until the for loop is executed again.

I've actively displayed the data contained within C Section, C1, C2, C3 C4 during runtime, and none of the data is ever changed/corrupted at any point to cause this strange behavior. In fact, there are other sets of sections that follow the exact same structure (e.g. list named B Section with 4 actors named B1, B2, B3, B4) and they never exhibit this kind of behavior.

Ask a Question / How do I attach two actors with joints? [SOLVED]
« on: May 15, 2020, 09:27:03 pm »
Problem solved.

I'll just use actors instead. Thank you for the suggestion on dealing with actors for  my minimap!

No, that was my first idea, but part of my game's code draws an accurate replica of the current scene's terrain (minimap) by using tile placement. Using actors in their place would cause the code to think "There's nothing here" and leave a blank space in the image. Before I end up rewriting and optimizing that code, I wanted to see if there was an alternative so I could continue using tiles. Are actors the only option?

Question is in the title. As far as I'm aware, you cannot have separate animations for a tile, and if you want to use two different animations for a tile,  you would have to import both animations as separate tiles, and then switch them out for each other by completely deleting the first tile and creating the second tile in its place.

 I'm trying to dodge this process as it causes spikes in garbage collection and frame-rate drop. Is there a workaround for this, or is there already a way to have separate animations for one tile, and I just missed it?

Ask a Question / What do these entities mean?
« on: March 26, 2020, 11:27:37 am »
I've recently begun using HxScout to begin optimizing my game, and have used it to pinpoint and optimize behaviors / code that were clearly causing the game to hang or slow down. However, my game still suffers from small, arbitrary lag spikes, and I didn't know where that could be coming from, so I setup a blank, black scene with only two actors in it, and ran HxScout. From my current understanding, these lag spikes are caused by the game spending time on lime._internal.backend.native.NativeWindow.contextflip and openfl Context3d rendering, but I don't know what either of those pieces of information are telling me to do in terms of optimization. From my understanding, neither of them are directly pointing a finger towards any particular event, behavior, or function related to either actor,  but there are no lag spikes if I just remove the actors entirely, so I know there's a problem somewhere with them, but I don't know what HxScout is directing me to.

The screenshots below are from sessions of just a blank, 1440x1440 scene with only the two actors inside.

Ask a Question / Why does sin(180) not return 0? [SOLVED]
« on: March 19, 2020, 04:02:08 pm »
When using trigonometry to move actors around a circle, I've noticed that their X,Y coordinates are always slightly off from the expected result (mainly because they're attached to other actors with contrasting colors). Let's take two actors (Actor A, Actor B) for example, and say that the math in the code dictates that:

Actor A's  Y coordinate should be [ 735 + Sin(0) ],
Actor B's Y coordinate should be [ 735 + Sin(180) ].

Both should be at 735 since Sin(180) and Sin(0) are 0, but the actual result is that Actor B's Y coordinate is 734 and Actor A's Y coordinate is 735. When you throw cosine into the mix for determining the X coordinate, the same thing happens for the angles 90 and 270. This creates a scenario where actors can slightly shift out of place and look somewhat floaty while moving around the circle.  When I printed the value of Sin(180), the value wasn't 0, but it was "-9.293710953857782e-14". That's so close, but still off to distort the actor's coordinates. Why does this happen?

Edit: Nevermind. I understand now.

Ask a Question / Re: Is there a better way to draw a laser? [SOVLED]
« on: March 18, 2020, 05:40:35 pm »
Just tested this a few minutes ago. The same dummy scenario I showed on my first post had 0 lag on Flash and Windows. The significant FPS drop only occurs with HTML5.

Ask a Question / Re: Is there a better way to draw a laser? [SOLVED]
« on: March 18, 2020, 11:29:43 am »
Thanks for sharing your solution! I thought using stencyl's drawing function would be less resource intensive than using actors and was confused, thinking it was the math instead. Turns out it was the total opposite!

Ask a Question / Is there a better way to draw a laser? [SOVLED]
« on: March 17, 2020, 11:34:22 am »
I recently thought of making an enemy that fires an extending laser in front of it. I wanted the laser to start as a line from the center of the enemy, and extend forward from that center at any given angle until it reaches the wall. Immediately, Sine and Cosine seemed like the perfect functions to use for this given situation, and I decided to try using trigonometry to accurately push the  endpoint of the line based on the facing angle of the enemy.

I tried applying this by creating a dummy example as shown below.

This works, but then caused my game's frame rate to drop into the abyss as several lines began to travel fairly far. Stencylpedia said to avoid trigonometry because it's "expensive", so is there any other way to do this? Trigonometry is the first thing that occurs to me when sketching out any problem that involves angles.

Edit: One of the things I want to be able to do with this is allow each enemy to slowly turn their individual lasers as shown below with the dummy actors

Ask a Question / How do you set individual fill colors for shapes? [SOLVED]
« on: February 07, 2020, 07:33:34 pm »
Problem solved.

Ask a Question / How do you fix the source of these warnings?
« on: January 25, 2020, 11:06:25 pm »
I've copy/pasted extremely long and complicated events from an actor (Actor X) from an original game to an actor (Actor Y) of a new game using the block editor / Design Mode as a means to speed things up rather than having to redo every single event block by block, line by line. In this way, I would only have to re-create the game attributes, fill in the missing pieces, and clean up the local ones. Once I did that, I received this recursive warning whenever I open up Actor Y in the new game.

Apparently, Stencyl is searching for attributes that are present in the original game within Actor X, but they obviously would not exist for Actor Y in the new game. How do I fix this? I know it's just a warning, but I get the feeling that Stencyl will eventually break if it keeps looking for non-existent variables.

Ask a Question / Re: How to link new files in Stencyl
« on: December 11, 2019, 06:48:03 pm »
Well, that was. . . simple. Thanks! I thought the corrupted files had to be replaced. I never thought you could just delete them and that would fix everything.

Pages: 1 2 3 ... 13