Drones with a Mad Scientist

[Lyinginbedmon]

Robby should give you the answer, since certain parts of his code only run when a specific timer triggers the chip.

[Lyinginbedmon]

Lesson 3: Coding Philosophy
When writing the operating code for a drone, there are two distinct sections: Tricks and Operations.

An Operation code is a code that actually physically does something, often utilising variables and timers.

Tricks alter these variables and flip switches, causing the operations to do something else entirely or do something differently, generally based on awareness inputs.

Taking the Robby case study as an example, we see that the code was broken into Tricks and Operation sections.

The Operation section contained the the angular stabiliser and the directional force code. Whilst the stabiliser does not change, the directional force code is used to make the drone hover and follow the owner, based on the variable Cen. Both codes actually cause something to happen, because they make something outside of the E2 change in some way.

The Trick section contained the owner tracking code, the altitude adjustment code, the owner-following code, and the unlocking code.

• The owner tracking is based on the owner entity's position, which is a form of awareness.
• The altitude adjustment alters the Z value of the Cen variable that the directional force code uses, based on the distance output of the ranger.
• The owner-following code uses the tracking variables to determine if the drone is too far or too close to the owner and then alters Cen completely to compensate.
• The unlocking code works similarly, modifying the altitude adjustment code's target altitude until the drone is sitting on the floor beneath it.

With the small exception of the unlocking code toggling the border ring's no collide, these codes don't do anything by themselves, they manipulate variables that the other codes use.

This is the pattern that virtually all drones follow: Tricks and Operations.

Operations may seem quite familiar, because they are basically the physical tricks that a lot of E2 contraptions use, from something as mundane as turning a turret on or off when it finds the designated target infront it, or forming a body out of random props using applyForce. In general, if an E2 can directly make it happen, then it is most likely an Operation.

Tricks are slightly more complex, but by themselves they're little more than complex sequences of if functions. This may be as simple as Robby asking if his owner is too far away, or may be as complex as asking if there is an entity X distance away aiming at Y prop and holding Z weapon. It would then alter variables elsewhere in the E2, possibly turning on weapon targetting code or opening a door or changing the vector co-ordinates for something entirely removed from the chip itself to travel to. In general, if the E2 can decide to do something based on the owner or someone else's input, it can be coded using if functions to do it by itself.

For example, Robby again.

He uses the Operation of directional force to use applyForce to hold the central plate at a given vector position.

I could then tell him to hover at a given Z value, where it would be 50 Gmod units from the ground beneath the plate, using such things as the chat to tell him the Z value to use. Instead, I know I always want him to be 50 Gmod units from the ground, so that becomes a persistent variable for him to measure against. I then know that I discern whether he is too high or too low based on how far from the ground I see him, which could be mimicked using a ranger.

The result: Measuring the distance from a ranger against the target altitude, and compensating.

[nescalona]

You've mentioned it a couple of times before, but I still don't quite see what the difference is between tricks and operations. An operation is a general function; a trick is a specific instance of one or more operations working together with specific parameters?

[Lyinginbedmon]

An operation does something, like make Robby's central plate go somewhere, a trick tells it where based on what the ranger says and where the owner is.

To use an odd analogy, a trick is the computer, and an operation is the robot claw it uses to play chess.

[nescalona]

Gotcha. Hey, any chance you could answer my questions from this post?

[Lyinginbedmon]

EDIT: and another one. How does E2 handle it when you go out-of-bounds with string, array, matrix, etc. indices? E.g. "ABC":sub(1,5) or "ABC":sub(0,2)

one more. what happens when you run timer(S,N) and S already represents a timer? Is the timer reset? What if N is different from what it was when you first instantiated the timer?

First: The functions will accomodate when a data type of indeterminate length is used (Like a string or array), not sure about matrices though because I haven't used them.

Second: From testing it, I'm not sure. I tried an expression with[highlight=E2]timer("ABC",1500)
timer("ABC",1000)

if(clk("ABC")){O = time("sec") Out = ($O)}[/highlight]It seemed to occur based on the shortest timer, once per second.

[nescalona]

Thanks for the halp.

1. The functions will accommodate? So, the (N,N) values are automatically clamped to the actual range of the object?

2. I guess my real question is what happens when timer(S,N) is reexecuted after an interval of time has passed. Example:

runOnTick(1)
timer("A",100) # can this timer be used for anything?
# since the function is run every tick as written now.

3. What about the first question I had posted? Ties in to #2 above. Perhaps you missed it.

if you've got runOnTick(1) running, can clk(S) ever return 1? (where S is a string referring to a timer)

[Matte]

If you have runOnTick() enabled and a timer, the E2 will both execute from the timer and the server ticks. tickClk() will return true when the E2 was executed by the server tick, and clk(S) will return true if the E2 was executed by the timer.
It will execute somewhat like this:

RTRRRRRRRRTRRRRRRRRTRRRRRRRRTRRRRRRRR

where timer = 500ms and runOnTick enabled.
T = execution by timer, R = execution by tick.

[nescalona]

If you have runOnTick() enabled and a timer, the E2 will both execute from the timer and the server ticks. tickClk() will return true when the E2 was executed by the server tick, and clk(S) will return true if the E2 was executed by the timer.

Oh, awesome! I kinda hoped it worked that way.

[DarkMonkey]

That is pretty spiffy, yeah.