Hello everyone, and happy belated Tau day! So things have been a bit busier with me lately. My departure to the university I’m enrolled to outside the country is scheduled on 29th of July – Around a month is left to get done with work-related projects before I leave. But of course, there are some updates I’d like to share with you regarding the A-Engine. Two new features mainly: a new frame component, and a new id component.
The New Frame Component – timeout:
As we know from before, it’s possible to nest frame components inside each other to affect their activation time; like how placing a call_object component inside a hit_box will only make the call_object activate when the hit_box hits a target. We also know about the existence of the component segment which does nothing by itself, but serves in grouping other frame components together allowing one to deal with all of them as one.
segment[ enable = @hp > @max_hp/2 # enabled only when hp is more than half hit_box[...] # all of these components will only activate if the above condition is met call_object[...] display_graphic[...] ]
Now, timeout is a new frame component of that kind. It does nothing by itself, but its effect goes over the frame components you nest inside it. What a timeout does is that it runs all frame components inside itself, independent from the object’s frames flow, for a fixed period of time. Here’s the signature of the component, ignoring the standard tags all frame components have like enable, set_variable …etc:
timeout[ countdown = lifetime = repeat = condition = # any number of frame components to run ]
countdown is the amount of time (in frame timesteps) before the timeout begins running.
lifetime is the amount of time the timeout will last for before it dies.
repeat is the number of times the timeout can run again after it dies (lifetime gets reset).
condition takes a condition (hmm), which when false, will kill the timeout immediately.
Below is a frame with the timeout component in action:
[F=13 NAME= 'land'] #Crouch image=60 delay=5 xy_origin=39,0 goto='idle' hurt_box[ xy_origin = 39, 30 w = 30 h = 60 ] timeout[ lifetime=120 display_graphic[image=0 xy_origin=39,0 x_translate=100->0 xy_scale=5->1, 5->1] ] [/F]
Frame 13 is the frame my character enters when he lands from a jump. I launch a timeout with a lifetime of 120 (2 seconds, given the engine is running at 60 Frames Per Second) containing a display_graphic component. This means that the timeout will display “image = 0” for 2 seconds, but that’s not all there is to it. There are also two noteworthy tags which seem to do some extra transformations there; x_translate and xy_scale with expressions 100->0 and 5->1, 5->1 respectively. As we know, “->” in the A-Engine is the linear interpolation operator used to make transitions between 2 values in the frame’s duration. However, since a timeout runs independently from frames and has it’s own time scope (its lifetime), it means that the value transitions from the right hand value to the left hand value in a period of 2 seconds.
So the timeout will display an image of id 0 (idle sprite), for 2 seconds. When it starts, the image will be scaled by a factor of 5 and located 100 units away from the object. At the end of the timeout’s lifetime, the image will have relocated itself back to 0 (origin) and scaled itself down to a value of 1. Here’s a gif of it all happening in action:
The New Id Component – Detour [D=][/D]:
We’ve talked about id components before. A frame id-component is a component which contains frame data. A sequence id component is a component which contains a sequence of frames data. And today, I’m here with a new id component for objects – Detours.
[F=10] # frame 10 # tags [/F] [S=10->15] # expands to frames 10, 11, 12, 13, 14, 15 # tags [/S] [D = 10] # a new "kind" of frame - a detour # tags [/D]
Simply put, detours look like frames in almost every way, except they miss a single tag. delay=. A frame with delay = 0 will execute in one timestep. A frame with delay = 1 will execute in 2 timesteps. Detours take no timesteps to execute at all; once the control hits a detour, it will execute all of its tags and frame components, and then immediately goto the next frame. If the next frame is a detour too, it’ll continue until it reaches a frame or a sequence – all in a single timestep. This makes it useful to have a detour like the following:
[D=100 NAME = "heal detour"] #heal add_hp = 100 goto = "idle" call_object[id="heal effect"] [/D] [F=0 NAME ="idle"] #tags [/F]
goto = “idle” will take you to the idle frame next timestep. goto = “heal detour” will also take you to “idle” next timestep, but with the additional tags healing your character and spawning the effect.
Now, I’ve had the idea of implementing detours for a while and have actually considered scrapping the idea when somebody said that you can just let the detour be a frame that’s identical to the idle frame but with the additional healing tags. And that’s correct. However lately, I’ve came to realize that detours can be useful in other ways, too. For example, the goto tag in the detour can be made to read from a variable. This way, one can control what frame will follow the detour to “inject” any tags he like to any frame without directly touching it. Second, when the control executes a frame, it will not run tags in order you write them in. image is always read before x_velocity. With detours, you can force the control to read x_velocity first by placing it alone in a detour that comes before the frame. These might be very rare cases, but what do I know about what you guys are going to create and what you’ll need! At least, there’s a solution when the execution order of tags in a frame is sensitive now.
And that’s it for today’s update. If you have any inquiries or comments, you can post them below, and I’ll try to respond to each and every one of them as soon as I get the chance. Thanks for reading, and see you next time!