After a longshot whim, I changed the LOS cone to 2* instead of 1. PROBLEM SOLVED!

Thank you to anyone who took the time to read my (clearly) long post and who was willing to try to offer help! But I think I got it now.

If you see any suggestions, though, to help improve what I have here, PLEASE, I could use all the help I can get!

C3 game file

In my game, enemies move around, advancing 24 pixels up, down, left, or right (all movement and character and level design is regulated to this "grid"). During each move segment, it will move a certain number of 24x24 blocks (Pathfinding is not used). Contained with each enemy are four sprites - I call them "MoveChecks" - that represent one of those four directions. MoveChecks also hold the Line Of Sight behavior with a 1* cone which faces one of the four directions.

I'm using the MoveTo addon behavior, but even when the enemy moves exactly side-by-side to a solid wall object (no overlap), it causes the enemy to stop even though there's no direct collision. So the MoveCheck objects check if they are overlapping a wall and prevent further movement in that direction.

When a MoveCheck catches sight of the main character, Buster, it is supposed to charge ahead in that direction (later I will restrict LOS to only the direction the enemy is facing).

If Buster is more than a single block away and the enemy moves into the same row or column (establishing LOS), then the enemy moves quickly in the direction of Buster.

However, if Buster is exactly one square away to an enemy's corner (ie: top-left) - so, 24-pixels up and 24-pixels left - and the enemy moves up or to the left so to be in direct linear alignment with Buster, the state of the enemy will change to its proper "Attack" state, but won't actually charge in the proper direction until it is one cell father in the direction it was moving when it first caught LOS of Buster.

So if the enemy is moving to the left and is DIRECTLY below Buster, establishing LOS, it will continue to move one more cell to the left THEN dash upwards towards (rather, PAST) Buster.

I have tried adjusting the Pin position of my MoveCheck objects relative to the enemy they're contained with. I've resized them. But this is the one issue I cannot overcome. It works EXCEPT for close proximity. I have a feeling that it has to do with how LOS behavior checks for actual LOS of an object but I'm not sure.

Can someone please examine my event lines and help me identify (or even solve) the problem area?

Thank you so much. (And sorry for the lengthy explanation. I was trying to make the case understandable.)

Asmodean - AH! Thank you for the confirmation. Greatly appreciated.

Have a great day!

Just a simple question to make sure I understand the "Is Within Angle" condition for objects...

I checked the manual, but it wasn't quite as clear as I needed.

Let's say that I want to check if an object's angle is at all close to 90*... I set the range to 5*.

Does this mean that the game will check if the object's angle is between the range of 85* to 95* (a total range of 10*)?

Or does it mean that the range totals 5* - 2.5* below and 2.5* above the target angle?

Construct 3 file: Tanks

Below is my current set of instructions for scaling an "elevator" platform in a top-down perspective between layers, or "floors", amongst buildings of various heights. Each floor is scaled a factor of 0.1 larger than the floor below it, so that objects on each layer appear closer and larger, just as you might expect when looking at things up close or far away. No parallax is used.

As seen below, each grayscale block, from black (and the brown roads) to light-gray, seen here represents a floor (on its own layer in the layout). Each layer used for the buildings is scaled from 1 (layer: GroundLevel) to 1.9 (layer: TenthLevel). The Elevator object is currently on the layer dubbed ThirdLevel (not necessarily the third layer, as the Tank and turrets get their own layer between layers GroundLevel and SecondLevel).

The Set Up

I have a 2D Array, ListOfFloors, which lists floors 1-10, starting at index 1 (for simplicity I simply do not use or store any value in index 0).

There are two X axes. For each Y axis, Y(0) is the floor/layer value (tracked by the Elevator object instance variable Floor) and Y(1) sets the corresponding scale value for that layer. All of these values for the array are set at the start of the layout.

So, for instance, if the Elevator.Floor value is 2, then the Array.At(X(2)Y(0)) value has the name of the layer, "SecondLevel". And the X(2)Y(1) value is 1.2 which sets the scale value for that layer (again, set at the start of the layout).

The Flow

This is how the I intend for it to work...

• When the Elevator variable WaitTimeAtEachFloor reaches 0, whether moving up or down a floor, the Elevator object is automatically moved to the next floor/layer.

• If the Elevator object moves up a floor, at the same time, its scale value is set to 0.1 less than that floor/layer's scale value. So if the floor has a scale value of 1.2, then the Elevator object is set to 1.1. This is because the Elevator is technically already moving up and above any object below it. Even if it is not yet to its target "elevation" of 1.2 on the second floor, it is still above the floor below. This is also so that any objects meant to be below it do not appear above it while the Elevator is in the process of "scaling up". The reverse is true while moving down. Once this is done, the TriggerFloorChange boolean of the Elevator object is set to false so to prevent continual floor changes during scaling.

• While scaling, the Elevator object's scale value is tracked by its instance variable CurrentScale. Once it reaches its target scale value (as defined through the Array), the WaitTimeAtEachFloor is reset.

The Problem

The issue I'm having is that during the scaling and floor changing process, the Elevator object 1) occasionally seems to shift in its X/Y position (which I don't see with any of the other objects that represent the floors of the "buildings") and 2) the Elevator simply jumps from one scale size to the next instead of the gradual change as if it were steadily moving up and down in a smooth motion.

The Elevator does appear to jump between floors/layers properly, simply without the gradual/fluid scaling I intended.

Can anyone help me, please? Thank you very much!

By pure accident, I discovered the issue has to do with whether the project setting for Fullscreen Mode setting (low quality vs high quality). Little about it do I understand, but from the setting description, it has to do with when the image is rendered. That would seem to explain why I initially don't see an image. After changing it to high quality, the image shows up immediately and the quality of the image, obviously, is better.

So, not a bug. Just user ignorance.

Bumping from second page...

Ashley, any idea what may be the issue here? Any suggestions?

I'm not sure if this is a bug in C3, so I'm first posting here just in case it's a local issue or an easy fix I'm missing.

I'm using Chrome (always updated to the latest version) and when I go to preview my game - either in tab view or in pop-up view - it shows just a blank, black screen. This issue is remedied by resizing the window. Evidence suggests that the game is running, just not viewable at first. The problem does not occur during debug mode, probably because the debug window loads alongside the game window causing some "resizing" within the browser.

Any idea what is causing this? Is there a fix? Or should I report this as a bug?

Okay, I see what's going on now. Because I had it enabled from the beginning, the whole fade process was started the INSTANT it was created, despite that I had the Wait Time immediately updated in the exact next action in the same event. So the wait time, as defined in the editor parameters, was counting down as I had it at default.

And, like you said, the Wait Time was getting updated, but it wasn't taking that info into account.

So I told it not to have the Fadeout behavior active at first - only after I updated the Wait Time did I enable to Fadeout behavior. Now it's working as I wanted it.

Thanks for helping me to work it out!

I do understand all that you said. Perhaps I was getting my words mixed up again...

In any case, what I DO want us the Wait Time - before the fade out even behind - to last as long as there is fuel in the ship. Then fade out. Problem is that right after the Wall is created, it only takes the original value in the editor into consideration and begins to fade out almost immediately - NOT the minimum 5 seconds. Basically, there is no wait time being updated.

Should I set the Fade out behavior to disabled first then enable after I update the Wait Time?

WHOOPS! That was a mistake. My image SHOULD have had the red arrow pointing at the WAIT time, not fade-out.

I'm trying to set the Wait time to the ship's fuel value. But the Wait time is not getting updated upon creation of the Wall object.

C3 capx: https://www.dropbox.com/s/fv1jjt4a1sqg6hc/Space%20Shooter%20RPG.c3p?dl=1

As the topic line states, I'm not sure if this is a bug or an aspect of the Fade behavior that I'm not aware of.

In my game, the Wall objects will be randomly generated and their wait period will be determined by how much fuel is left in the spaceship at the start of that round. Once the fuel runs out, the Wall objects will fade out, destroy, and then will reset when the player starts the next round.

However, when I create the objects and set their Wait Time parameter, then run the program, it creates the Wall objects as desired but it immediately begins to fade out after the original wait time (as designated in the editor but not as specified in the event line).

Is this a bug that needs reporting or is it just an "unlisted" factor in how the Fade behavior works?