Rhindon's Forum Posts

  • Aaaaah! Well, if that's the case, I can work around that. Thanks for your help!

  • Yeah, that's the problem - the Enemy_Text object contained with each Heli verifies that none of the UIDs assigned to each Heli are correct.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • .c3p file: dropbox.com/s/o0wuhllutq7uxsr/The%20Getaway%20v3.c3p

    I have a 3-object enemy (by way of a container) which is meant to patrol a designated area, marked by another object, the "District_Area".

    Using the Bullet behavior, I make the Enemy_Heli_Move object (contained with the Enemy_Heli_Blade and Enemy_Heli objects and pinned together) patrol the designated District_Area. At the start of the layout, I assign the District_Area UID # to an instance variable in Enemy_Heli_Move object.

    I then pick the District_Area according to the value of the Heli's instance variable and check if the Heli is overlapping that select District_Area or not.

    If not, I tell it to rotate its angle (with Bullet behavior "Set Angle (of Motion)" checked in the properties window) back to the District_Area it's assigned to.

    The problem I'm having is that the UID of the District_Area is not being properly assigned from the beginning and I cannot understand why. I've done things like this before and it worked fine.

    Here is what I have for the setup and the workflow for the Heli.

    Thanks for your help!

    START OF LAYOUT:

    ENEMY PATROL CHECK:

  • Ah. I'm using Chrome (forgot to mention that in my post... Now updated). So maybe this is worth posting to the bug site for Ashley to look into.

    Thanks for the info!

  • That...is so ridiculously simple and awesome.

    Leave it to me to find the more difficult ways of doing things. THANK YOU, so much. LOL

    To answer your question, I was aiming for the Tween feature because of its easing into its end value. Whereas lerp is more all-or-nothing. But what you have here actually works perfectly!

    ALSO, thank you for reminding me about the reinitializing of the Tween behavior. I forgot about that. When I was doing my testing, I did notice that the value for the Tween seemed to "flicker" but I didn't catch on what was really happening. I'll try to remember that next time I think Tween is the way to go.

  • In my top-down racer game, if the Car overlaps a piece of road (the Onramp), there are several layers (for now, just "Road" or "Overpass") which are meant to zoom in or out based on the lerp value of the Car on the Onramp.

    Overview:

    1. Car overlaps Onramp (single object with four different animations for its up, down, left, or right-facing position).

    2. C3 calculates either the X or Y unlerp value depending on the position of the Car and whether the Onramp is facing up/down or left/right.

    3. Using an off-screen "Zoom Meter" object with the Tween behavior, I Tween the Zoom Meter to the unlerp value as determined by the position of the Car on the Onramp.

    4. The Tween is meant to arrive at the corresponding unlerp value shortly after the Car gets to its at-that-moment position.

    5. Using the Value of the Tween, I update the scale Road and Overpass layers.

    Just in case that didn't make much sense, this is what it's supposed to look like...sort of.

    Not properly illustrated, as I stated above, is that the actual zooming/scaling will be "lagged" behind the actual position of the Car relative to its position of the Onramp. It should act like this (which is where the Tween comes in):

    C = Car

    Z = Zoom/Scale of layer

    <--C-------->

    <Z---------->

    ...then...

    <-------C--->

    <----Z------>

    ...

    <-----------> C

    <----------Z>

    Basically, the Zoom is always playing catch up to the unlerp value of the Car's position on the Onramp. If the player slows down on the Onramp or even stops, then the Tweening of the Zoom value should eventually (like, within a few seconds or LESS) match up.

    Problem is I'm having trouble properly making this work. I had it set up before where it would update the Zoom based on the at-that-moment unlerp value, but not with a delayed value.

    Here's a screen-shot of my current event/action set up:

    I hope that all made sense...

    Can someone help me see where I made my error? Thanks.

  • OH! So basically it's a FRACTION of what the CURRENT scale is.

    Similar to how lerp works out a value between [start] and [end] values given the percentage between them.

    I understand now. Thank you very much!

  • I am unsure if this is truly a bug or if it's just because of the demands of my project...

    Simply...

    When I load my game via debug, selecting any - literally ANY - object instance takes a long time to bring up any info about it. It's like I never clicked it at all if not for the fact that eventually the info will populate.

    Worse, the bounding box - the red dotted line that highlights the object in the game window - also lags. When the debug info populates, the bounding box will, as well, but if the actual object is moving the box will not update in real time. There is anywhere from a minute to several minutes before anything happens.

    The game I'm working on has numerous roads and other road-based objects in the layout, as well as several layers. But I've seen games with lots more going on and it doesn't seem to matter. When I play the game normally - as far as I have it - it doesn't have any noticeable issues, other than the occasional "stagger" or drop in framerate at random times. I think that may be due more to my laptop than anything else (even though it's still very new).

    I've been working on setting groups active or inactive depending on the need in order to reduce the amount of events the game has to process at any one time. I'm also working on reducing the number of objects consistantly in the layout to reduce how much it has to redraw every tick. Still, the debug persists in its laggy-ness.

    I'm using the most recent version of Chrome.

    Here is my current WIP .c3p : dropbox.com/s/my7t3c42aao38g0/The%20Getaway%20v2%20resize.c3p

    The controls are:

    UP arrow: accellerate

    DOWN arrow: brake/reverse

    LEFT/RIGHT arrows: turn

  • I'm working on adjusting layers at certain times and then shifting them back.

    However, what I don't fully understand is how the "Set Scale Rate" works. Setting the scale immediately makes sense, if it's X at one point, setting the value to Y takes immediate effect.

    With Set Scale Rate, my assumption has been that it works something like a built-in lerp or the new Tween behavior. Meaning, if the initial scale value is X, it will gradually move to Y once it is told to set the scale to Y...it won't be an instant update.

    My confusion comes in during an initial test...

    I set the scale rate value for a few layers at the start of the layout then triggered some events to adjust the scale. As before, it updated the scale of those layers immediately...there was no indication of "rate" or "gradual" as I supposed.

    Clearly, I'm misunderstanding things but cannot figure out what, exactly, I'm missing.

    For specifics of what I'm trying to do, here's the .c3p

    dropbox.com/s/my7t3c42aao38g0/The%20Getaway%20v2%20resize.c3p

    Event line 1 (look for the actions towards the bottom of the first even line; ignore the sub-events) and the group event starting at line 96.

    Could someone clarify this for me, please? THANKS!

  • 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!!

  • 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?