Rhindon's Forum Posts

  • Awesome! Thanks for the clarification, Ashley! I can't wait to make use of this!

  • Video released by Ashley earlier today (Dec 19, 2018): youtube.com/watch

    So, with this new update about an upcoming feature, I'm beyond thrilled. I'm like a kid meeting the REAL Santa.

    The feature, as shown in the video, focuses on literal 3D zed-axis scaling/zooming/parallax (not sure which is the most accurate term there).

    I've actually worked with this kind of concept by taking layers and scaling them at different intervals to give a sense of depth when working on a top-down perspective in my games. The effect was very nice, albeit, limited due to everything being FLAT. (This IS a 2D engine, after all.)

    But Ashley has revealed that this zed-axis feature won't be limited to just layers, but will apply to individual object instances, too!

    This brings a few questions to mind, which I will TRY to articulate clearly and succinctly...

    1. Since this is zooming (I'm just gonna stick with that term) on the zed-axis, the objects are not actually getting bigger or smaller...they're literally just closer to or farther from the camera. With this understanding, it is presumed that objects that overlap "zoomed" objects will still factor collisions and such. At the same time, since this is dealing with real 3D space (per Ashley in the video), will there be conditions and actions that take into account objects that are "zoomed" versus objects on the same zed value?

    2. Although this is still explicitly 2D we're working with, the addition of zed/depth will add new quirks, no doubt. Similar to how the shadow behavior has a "height" property to determine how far a shadow will be cast, will objects (namely sprites, but hopefully most the rest, as well (like background tiles, 9patch, etc)) be given a "depth" property to take into account the zed nature being introduced? Again, this is keeping in mind we're dealing with strict 2D in all other matters, but with zed now factoring in, it might be interesting to ponder when things like solid behavior comes into play... An object that is, say, a height of 3 pixels can pass under/behind a 5-pixel object so long as those 3 pixels are not "overlapping" at the same 1-3 zed pixels. Anyway...you get the idea, I'm sure (I hope).

    3. Despite the repeated strong emphasis on this NOT being a move into 3D engine territory, how will movement behaviors take to the new zed-axis? (SHORT PARAGRAPH! Who knew I was capable of that?! HA!)

    Thank you, Ashley for this awesome new reveal and your work and the rest of the Scirra Bros team!

  • Wonders and miracles, IT WORKS! :D

    I'm always grateful for your help. Thanks again!!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Oh okay. I must have missed that detail. Curious why that makes a difference, but I will do just that. Thank you! :D

  • I have an enemy that, when within range, it'll "rocket" towards the Player Car via the Bullet behavior using the Car's last known position at the point of Line-of-Sight acquisition.

    Breakdown:

    1. Chase player via Pathfinding

    2. Acquire Car via Line-of-Sight (LOS)

    3. Rapidly "attack" Car in the direction of the last known position

    4. Bullet deceleration property is -100 pixels/second

    5. When Enemy Bullet speed is 0, enter cooldown period

    6. At end of cooldown period, resume normal pursuit of Car via Pathfinding

    The problem is that upon acquiring the Car via LOS, the Enemy does not update its Bullet angle of motion.

    For the Enemy properties, I disabled the option which sets the Enemy angle to the angle of motion. However, for some reason, the Enemies always activate by going at a 180* angle.

    (Note, I have further removed the "For each Enemy" in the first event line...still no real solution, though there seems to be mild improvement.)

    Can anyone assist me in this matter, please? Thank you!!!

  • Aaaah I see. Thank for the clarification. To further clarify, though, does the collision disabling also matter if the object off screen? I'll remove the "invisible" actions but would I benefit from leaving collision disable/enable actions?

  • This is simply a verification post seeking to ensure I'm not undoing what I'm trying to put together while ALSO trying to save on the demands on the CPU/GPU.

    The goal is that any objects not on screen should be set to invisible and their collision detection properties disabled. That way C3 isn't constantly checking them all the time - because this game is going to have A LOT OF OBJECTS in the layout. And since I have an $800 laptop that still seems to lag or "skip" I'm concerned that lower-end computers compared to mine may fair worse. At any rate, I figured it's a good practice to attempt.

    Question is, I have some enemies that use Pathfinding behavior and seek to avoid several of the objects I do have (or will later have when I added the conditions) set as obstacles..... So will disabling collisions on these objects still be avoided by the enemies with Pathfinding?

  • I had forgotten about this change! Thank you for the reminder!

  • UPDATE: I had forgotten about the change/addition using the rgba expression. Details can be found here in a similar post to my own issue here. link: https://www.construct.net/en/forum/construct-3/how-do-i-8/set-effect-parameter-setcolor-131303

    RESOLVED!!!

    I'm trying to update objects on my HUD to reflect progressive changes in the game objects they represent.

    As the game objects take damage, the respective HUD elements will go from green (to yellow) to red.

    Per the properties bar, the SetColor effect lists the RGB color values as [RRR, GGG, BBB].

    When updating the values on the event sheet(s) via actions, you have to specify which 0-based parameter you want to affect... 0 for red, 1 for green, 2 for blue - each one having its own action line.

    Initially, the values start out as follows:

    RED: 0

    GREEN: 255

    BLUE 0 (and will never be changed)

    I'm using the two following action lines:

    - SetColor: Parameter 0 (red): round((100-Car.Integrity_Body_End))/100*255

    - SetColor: Parameter 1 (green): round(Car.Integrity_Body_End)/100*255

    The instance variable Integrity_Body_End is the strength of that part of the car object, with value 100 being full strength and 0 being destroyed.

    So an undamaged car would basically be 100/100*255...or 255. The color green should yield a green object on the HUD display. Naturally, as the car takes damage, the "100" value will decrease.

    As the green value goes down, the red value should inversely increase (using the difference between the variable value and 100...the difference then divided by 100 and the yielding fraction multiplied by 255.

    Anyway...

    What results is a greyed-out or black object. The starting RGB value for the object is [000,255,000]...green. And yet any attempt to affect this effect turns...heh...well, dark.

    What am I doing wrong?

    Thank you for your help!

  • Thank you, Kyatric!

  • Bump!

  • Why is it not possible to test if a 9-patch object is overlapping or being overlapped by another object? This is creating a difficult work-around process to isolate a specific 9-patch instance based on where it's located in my map.

  • Sorry for all the trouble...but it worked after all, just like you said. I'm not sure where my issue was coming from when I tried it earlier. But it's all working now as I hoped for.

    Thank you for coming to my rescue once again. :)

  • Ashley - I know you're busy, but do you have a moment to look over this?

  • I hope this offers more clarity.

    Like I mentioned, the map moves in-sync with the movement of the player car, but it's "off center" from the actual location of the car.

    For instance, if the player car is to the bottom left of a building, the minimap shows the car is several units north of the building.