Trying to pinpoint 4 coordinates out of a region - iphone

I created a simple macro for Piano Tiles 2 just to see if I could automate it indefinitely.
My code here:
search = true
region = {100, 500, 500, 1}
while search do
findColorTap(0, 1, region);
findColorTap(258, 1, region);
findColorTap(16758018, 1, region);
usleep(5000)
end
Works for all three tiles.
--0 being jet black notes
--258 being hold notes which have a smaller "hitbox"
--16758018 being extra notes which have an even small "hitbox"
Currently the script will check every color on the screen in a 1pixel horizontal line from start to finish (100->500), and when it returns with the color I need, it will tap that pixel once.
I'm curious how to take just 4 points from the region and check those just the same.
I'm also curious if the above is possible, would Lua be able to compile the script faster or slower than checking the region.
My thoughts would be that once findColorTap returns the value I need. The other checks are essentially wasting valuable time. But, I also know that the more intricate the code gets, the harder my phone has to work to process these commands.
I have tried:
Example 1
check = true
while check do
note1 = getColor(80,500)
note2 = getColor(240,500)
note3 = getColor(400,500)
note4 = getColor(560,500)
end
while check do
if note1 == 0 then
tap(80,500)
elseif note1 == 258 then
tap(80,500)
elseif note1 == 16758018 then
tap(80,500)
else
end
end
This ends up either not reading any notes at all or when it does catch it falls out of sync with the game.
Example 2
function fct(startX, maxX, y, increment)
for x=startX,maxX,160 do
check=getColor(x,y)
if check == 0 then
return(x)
end
tap(x,y)
end
end
v = true
repeat
fct(80,560,500) until
v == false
This one was checking correctly and much faster, but was tapping in the wrong locations.

The other checks are essentially wasting valuable time. But, I also know that the more intricate the code gets, the harder my phone has to work to process these commands.
The "other checks" you're calling are vastly more intricate than anything in your code.
You don't need to worry about how many lines of code you have, you need to worry about computationally expensive ones being executed a lot.
would Lua be able to compile the script faster or slower than checking the region.
You mean run faster. Compiling is done once on startup, and doesn't affect run speed.
And yes, it will be faster to check 4 pixels than hundreds of pixels.
I have tried
Saying what you've tried does us no good unless you tell us why it didn't work.
while check do
note1 = getColor(80,500)
note2 = getColor(240,500)
note3 = getColor(400,500)
note4 = getColor(560,500)
end
while check do
if note1 == 0 then
tap(80,500)
elseif note1 == 258 then
tap(80,500)
elseif note1 == 16758018 then
tap(80,500)
else
end
end
end
This looks like it will never leave the first loop (unless you're setting check inside getColor).
Also, every branch in the second loop produces the exactly same tap.
It's hard to tell what you're asking, but if the goal is to check the color at specified locations, then tap at another specified location depending on the color you found, you could do something like this:
-- which points to check
points = {
{ x= 80, y=500 },
{ x=240, y=500 },
{ x=400, y=500 },
{ x=560, y=500 },
}
-- map a found color to a resulting tap point
tapPoints = {
[0] = { x=80, y=500 }, -- these
[258] = { x=80, y=500 }, -- should
[16758018] = { x=80, y=500 }, -- be different!
}
while check do
for checkPoint in ipairs(points) do
local note = getColor(checkPoint.x, checkPoint.y)
local tapPoint = tapPoints[note]
tap(tapPoint.x, tapPoint.y)
end
end

Related

Sprite Kit: Waiting to call a function until condition X is met

I'm working on a game (top-down shooter) and have run into a bit of a snag. Up to this point, I've spawned enemies with functions that just work with delays:
Wave One Function - Delay 3, spawn enemies //
Wave Two Function - Delay 6, spawn enemies
I do this because I haven't found a way to wait for all actions in a given function to complete before calling the next - as things stand, functionWaveOne calls functionWaveTwo, which calls functionWaveThree (etc).
This has worked until now. What's changed is I want two enemies to remain on-screen and until they're dead, I don't want the next wave to come. My initial solution to this was to have a running count of how many enemies died in wave four:
Detect collision -> Apply Damage -> Check if dead -> If yes, deadWaveFourEnemies++
Here's my problem: I have a primary weapon that's two parallel lasers, so they have potential to collide with an enemy at exactly the same time. This results in false positives, making the dead enemy count go higher than it should. I even tried adding an "am I alive" function to the enemy class, but to no avail.
Have any of you got a recommendation on how to either call functions in a better way or to get around these false positives? Thanks!
In case it helps:
if([enemySprite.name isEqual: #"shooter"]){
enemyShooter *enemyClass = (enemyShooter *)enemySprite;
itDied = [enemyClass doDamageWithAmount:secondaryWeaponDamage];
scoreIncrease = [enemyClass getScoreIncrease];
stillAlive = [enemyClass amIAlive];
}
[weaponSprite removeFromParent];
if(itDied){
[self increasePlayerScoreBy:scoreIncrease];
if(inWaveFour == 1 && stillAlive == 1){
waveFourKilled++;
NSLog(#"Seconday / Number killed: %i", waveFourKilled);
}
}

Access VBA to Change an Image in a Continuous Form

I am trying to create a receipt form where people will confirm if they've received the full quantity of an order. As part of this, I want the following to happen:
If they received the full quantity, a green check mark appears
If they received a partial quantity, an orange triangle appears
If they received no items, a red x appears
To accomplish this, I'm using a continuous form with 3 image files for each situation. I'm using the code below to change the image when the quantity is changed. The problem is, when the quantity is change on 1 line, the symbol changes for all lines. I'll post pictures as well.
Any thoughts on how I can fix this?
I'm open to other methods of accomplishing this idea too.
Private Sub FinalQTY_AfterUpdate()
If IsNull(Me.FinalQty) Then
MsgBox "You must enter a quantity for this item"
Me.FinalQty.SetFocus
Exit Sub
Else
LValue = Me.[FinalQty]
If IsNumeric(LValue) = 0 Then
Me.FinalQty = ""
MsgBox "Qty must be a numeric value"
Me.QTY.SetFocus
Exit Sub
End If
End If
Me.FinalTotalPrice = Me.FinalPrice * Me.FinalQty
If Me.FinalQty = 0 Then
Me.Yes.Visible = False
Me.Change.Visible = False
Me.No.Visible = True
End If
If Me.FinalQty < Me.QTY Then
Me.Yes.Visible = False
Me.Change.Visible = True
Me.No.Visible = False
End If
If Me.FinalQty = Me.QTY Then
Me.Yes.Visible = True
Me.Change.Visible = False
Me.No.Visible = False
End If
End Sub
This is before I adjust the quantity:
This is after I adjust the qty of only the second line:
Since the formatting of each record displayed by a continuous form is inherited from the form design template, any changes to the template will be automatically applied to all records displayed by the form, aside from Conditional Formatting rules in effect or the handful of properties which may changed via the OnPaint event of the Detail section.
One possible alternative might be to add a new field to your table with a data type of OLE Object and populate the value on the AfterUpdate event using the AppendChunk method, sourcing image data from a separate table containing three records corresponding to your green tick, orange triangle, and red cross images.

Fading 2 sounds in Wed Audio API

I'm trying to fade out 2 sounds at the same time in the piano app on this page:
http://www.intmath.com/trigonometric-graphs/music-note-frequencies-interactive.php
I'm using the "voices" approach and the exponential fadeout is working fine in single-note mode;
vca.gain.exponentialRampToValueAtTime(0.001, audioContext.currentTime + 1);
oscillator.stop(audioContext.currentTime + 1);
However, after choosing "Combined signal: yes" (where you hear a 220 Hz note plus the note played), the above will fade out the non-220 Hz note correctly, but the fundamental A-220 plays at full volume for the whole 1-second duration after key up. It's ugly, especially on small speakers.
I've disabled the fadeout for now in the "combined" case (both sounds just stop immediately, which is better than having one not fade at all.)
This is the function called on key up:
function doUp(thisKey, e) {
if(audioContext) {
for(i=-1; i<18; i++) {
if( typeof(active_voices['key'+i]) != "undefined") {
active_voices['key'+i].stop();
delete active_voices['key'+i];
}
}
}
audioOn = false;
}
I have tried changing the first line of the middle "if" to the following, but it didn't improve things:
active_voices['key'+i].stop(audioContext.currentTime + 1);
How to fade out 2 voices at the same time?
TIA.

Verifying Value is Not Equal Before Assigning Value

Is there any point checking to see if a value has already been assigned to a variable or is it better to just simply assign the value? For example, if X is going to equal 1, is there any point checking to see if X already equals 1? Example code below:
if X != 1 {
X = 1
}
I ask this question become I'm looping through a bunch of children sprites and changing the alpha values to 0, which most are already set at 0. So I'm seeing if there is any benefit in checking the children's alpha value first (I can't see the benefit).
parent.enumerateChildNodes(withName: "*", using: {
node, stop in
// if node.alpha != 0 {
node.alpha = 0
// }
})
Just set the value normally.
What even is the point of checking whether the value is already 0 before setting it? What difference does it make? After the line of code:
node.alpha = 0
No matter what value alpha has before, it will always be 0 after the above line!
If you are worried about performance, don't, until you encounter one.
Setting alpha is just like setting any other variable. It doesn't do much apart from setting the value. It won't immediately change the alpha of the sprite on the screen. It will only do it in the next frame.
Say you do this a bunch of times:
for _ in 0...10000 {
node.alpha = 0
node.alpha = 1
}
The node's alpha on the screen won't be flashing like crazy. Eventually it will be 1 so the node will be drawn with alpha = 1 in the next frame.

Creating An "Autopilot" For Lander in Perl

I'm using Perl to create a simple Lunar Lander game. All of the elements work (i.e. graphical interface, user implemented controls, etc), but I cannot seem to get the "AutoPilot" function to work. This function should fly the lander to a spot that it can land (or a spot designated as a target for landing), and then safely land there. The restrictions placed on landing are the slope of the place the lander lands and the velocity that the lander has when landing. The only file I can change is AutoPilot.pm. I will post the code I am allowed to work with:
package AutoPilot;
use strict;
use warnings;
# use diagnostics;
=head1 Lunar Lander Autopilot
The autopilot is called on every step of the lunar lander simulation.
It is passed state information as an argument and returns a set of course
correction commands.
The lander world takes the surface of the moon (a circle!)
and maps it onto a rectangular region.
On the x-axis, the lander will wrap around when it hits either the
left or right edge of the region. If the lander goes above the maximum
height of the world, it escapes into the space and thus fails.
Similarly, if the lander's position goes below 0 without ever landing
on some solid surface, it "sinks" and thus fails again.
The simulation is simple in the respect that if the langer goes at a high speed
it may pass through the terrain boundary.
The y-axis has normal gravitational physics.
The goal of the autopilot is to land the craft at (or near) the landing
zone without crashing it (or failing by leaving the world).
=head2 Interface in a nutshell
When the simulation is initialized, AutoPilot::Initialize() is called.
Every clock tick, AutoPilot::ComputeLanding() is called by the simulator.
For more explanation, see below.
=cut
# if you want to keep data between invocations of ComputeLanding, put
# the data in this part of the code. Use Initialize() to handle simulation
# resets.
my $call_count = 0;
my $gravity;
my ($x_min, $y_min, $x_max, $y_max);
my ($lander_width, $lander_height, $center_x, $center_y);
my $target_x;
my ($thrust, $left_right_thrust);
my ($max_rotation, $max_left_right_thrusters, $max_main_thruster);
my $ascend_height = 980;
=head1 AutoPilot::Initialize()
This method is called when a new simulation is started.
The following parameters are passed to initialize:
$gravity, a number, describing the gravity in the world
$space_boundaries, a reference to an array with 4 numerical
elements, ($x_min, $y_min, $x_max, $y_max), describing
the world boundaries
$target_x, a number representing the target landing position
$lander_capabilities, a reference to an array with
5 elements,
($thrust, $left_right_thrust, $max_rotation, $max_left_right_thrusters, $max_main_thruster),
describing the capabilities of the lander.
$lander_dimensions, a reference to an array with
4 elements,
($lander_width, $lander_height, $center_x, $center_y),
describing the dimensions of the lander.
=head2 Details
=head3 Dimensions
The dimensions are given in 'units' (you can think of 'units' as meters).
The actual numbers can take any real value, not only integers.
=head4 World dimensions
The lander world is a square region with a lower left corner at
($x_min,$y_min) and an upper right corner at ($x_max, $y_max).
The measurement units of these dimensions will just be called units
(think about units as meters). By definition, $x_max>$x_min and
$y_max>$y_min.
The default values for the lower left and upper right corners
are (-800,0), and (800,1600), respectively.
=head4 Lander dimensions
The lander is $lander_width units wide and $lander_height high.
The coordinates of the lander are always specified with respect to its center.
The center of the lander relative to the lower left corner of the lander bounding box
is given by $center_x, $center_y. Thus, if ($x,$y) are the coordinates of the lander,
($x-$center_x,$y-$center_y) and ($x-$center_x+$lander_width,$y-$center_y+$lander_height)
specify the corners of the bounding box of the lander. (Think of the lander as completely
filling this box.) The significance of the bounding box of the lander is that a collision
occurs if the bounding box intersects with the terrain or the upper/lower edges of the world.
If a collision occurs, as described earlier, the lander might have just landed,
crashed or 'escaped' (and thus the lander failed).
The constraints on these values are: $lander_width>0, $lander_height>0,
$center_x>0, $center_y>0.
The default value for the width is 60 units, for the height it is 50,
for $center_x it is 30, for $center_y it is 25.
=head4 Forces
The gravitational force is:
$g
The thrust exerted by the engine when fired is:
$thrust
The thrust exerted by the left/right thrusters when fired is:
$left_right_thrust
=head4 Limits to the controls
Within a single timestep there are limits to how many degrees the
lander may rotate in a timestep, and how many times the side thrusters,
and main thruster, can fire. These are stored in:
$max_rotation, $max_left_right_thrusters, $max_main_thruster
=head4 Target
The target landing zone that the lander is supposed to land at:
$target_x
which returns
the string "any" if any safe landing site will do, or
a number giving the x-coordinate of the desired landing site.
Note: there is no guarantee that this is actually a safe spot to land!
For more details about how the lander is controlled, see AutoPilot::ComputeLanding.
=cut
sub Initialize {
my ($space_boundaries, $lander_capabilities,$lander_dimensions);
($gravity, $space_boundaries, $target_x, $lander_capabilities, $lander_dimensions) = #_;
($x_min, $y_min, $x_max, $y_max) = #{$space_boundaries};
( $thrust, $left_right_thrust, $max_rotation,
$max_left_right_thrusters, $max_main_thruster) = #{$lander_capabilities};
($lander_width, $lander_height, $center_x, $center_y) = #{$lander_dimensions};
$call_count = 0;
}
=head1 AutoPilot::ComputeLanding()
This method is called for every clock tick of the simulation.
It is passed the necessary information about the current state
and it must return an array with elements, describing the
actions that the lander should execute in the current tick.
The parameters passed to the method describe the actual state
of the lander, the current terrain below the lander and some
extra information. In particular, the parameters are:
$fuel, a nonnegative integer describing the remaining amount of fuel.
When the fuel runs out, the lander becomes uncontrolled.
$terrain_info, an array describing the terrain below the lander (see below).
$lander_state, an array which contains information about the lander's state.
For more information, see below.
$debug, an integer encoding whether the autopilot should output any debug information.
Effectively, the value supplied on the command line after "-D",
or if this value is not supplied, the value of the variable $autopilot_debug
in the main program.
$time, the time elapsed from the beginning of the simulation.
If the simulation is reset, time is also reset to 0.
=head2 Details of the parameters
=head3 The terrain information
The array referred to by $terrain_info is either empty, or
it describes the terrain element which is just (vertically) below the lander.
It is empty, when there is no terrain element below the lander.
When it is non-empty, it has the following elements:
($x0, $y0, $x1, $y1, $slope, $crashSpeed, $crashSlope)
where
($x0, $y0) is the left coordinate of the terrain segment,
($x1, $y1) is the right coordinate of the terrain segment,
$slope is the left to right slope of the segment (rise/run),
$crashSpeed is the maximum landing speed to avoid a crash,
$crashSlope is the maximum ground slope to avoid a crash.
=head3 The state of the lander
The array referred to by $lander_state contains
the current position, attitude, and velocity of the lander:
($px, $py, $attitude, $vx, $vy, $speed)
where
$px is its x position in the world, in the range [-800, 800],
$py is its y position in the world, in the range [0, 1600],
$attitude is its current attitude angle in unit degrees,
from y axis, where
0 is vertical,
> 0 is to the left (counter clockwise),
< 0 is to the right (clockwise),
$vx is the x velocity in m/s (< 0 is to left, > 0 is to right),
$vy is the y velocity in m/s (< 0 is down, > 0 is up),
$speed is the speed in m/s, where $speed == sqrt($vx*$vx + $vy*$vy)
=head2 The array to be returned
To control the lander you must return an array with 3 values:
($rotation, $left_right_thruster, $main_thruster)
$rotation instructs the lander to rotate the given number of degrees.
A value of 5 will cause the lander to rotate 5 degrees counter clockwise,
-5 will rotate 5 degrees clockwise.
$left_right_thruster instructs the lander to fire either the left or
right thruster. Negative value fire the right thruster, pushing the
lander to the left, positive fire the left thruster, pushing to the right.
The absolute value of the value given is the number of pushes,
so a value of -5 will fire the right thruster 5 times.
$main_thruster instructs the lander to fire the main engine,
a value of 5 will fire the main engine 5 times.
Each firing of either the main engine or a side engine consumes
one unit of fuel.
When the fuel runs out, the lander becomes uncontrolled.
Note that your instructions will only be executed up until the
limits denoted in $max_rotation, $max_side_thrusters, and $max_main_thruster.
If you return a value larger than one of these maximums than the
lander will only execute the value of the maximum.
=cut
sub ComputeLanding {
my ($fuel, $terrain_info, $lander_state, $debug, $time) = #_;
my $rotation = 0;
my $left_right_thruster = 0;
my $main_thruster = 0;
# fetch and update historical information
$call_count++;
if ( ! $terrain_info ) {
# hmm, we are not above any terrain! So do nothing.
return;
}
my ($x0, $y0, $x1, $y1, $slope, $crashSpeed, $crashSlope) =
#{$terrain_info};
my ($px, $py, $attitude, $vx, $vy, $speed) =
#{$lander_state};
if ( $debug ) {
printf "%5d ", $call_count;
printf "%5s ", $target_x;
printf "%4d, (%6.1f, %6.1f), %4d, ",
$fuel, $px, $py, $attitude;
printf "(%5.2f, %5.2f), %5.2f, ",
$vx, $vy, $speed;
printf "(%d %d %d %d, %5.2f), %5.2f, %5.2f\n",
$x0, $y0, $x1, $y1, $slope, $crashSpeed, $crashSlope;
}
# reduce horizontal velocity
if ( $vx < -1 && $attitude > -90 ) {
# going to the left, rotate clockwise, but not past -90!
$rotation = -1;
}
elsif ( 1 < $vx && $attitude < 90 ) {
# going to the right, rotate counterclockwise, but not past 90
$rotation = +1;
}
else {
# we're stable horizontally so make sure we are vertical
$rotation = -$attitude;
}
# reduce vertical velocity
if ($target_x eq "any"){
if (abs($slope) < $crashSlope){
if ($vy < -$crashSpeed + 6){
$main_thruster = 1;
if (int($vx) < 1 && int ($vx) > -1){
$left_right_thruster = 0;
}
if (int($vx) < -1){
$left_right_thruster = 1;
}
if (int($vx) > 1){
$left_right_thruster = -1;
}
}
}
else{
if ( $py < $ascend_height) {
if ($vy < 5){
$main_thruster=2;
}
}
if ($py > $ascend_height){
$left_right_thruster = 1;
if ($vx > 18){
$left_right_thruster = 0;
}
}
}
}
if ($target_x ne "any"){
if ($target_x < $px + 5 && $target_x > $px - 5){
print "I made it here";
if (abs($slope) < $crashSlope){
if ($vy < -$crashSpeed + 1){
$main_thruster = 1;
if (int($vx) < 1 && int ($vx) > -1){
$left_right_thruster = 0;
}
if (int($vx) < -1){
$left_right_thruster = 1;
}
if (int($vx) > 1){
$left_right_thruster = -1;
}
}
}
}
if ($target_x != $px){
if ( $py < $ascend_height) {
if ($vy < 5){
$main_thruster=2;
}
}
if ($py > $ascend_height){
$left_right_thruster = 1;
if ($vx > 10){
$left_right_thruster = 0;
}
}
}
}
return ($rotation, $left_right_thruster, $main_thruster);
}
1; # package ends
Sorry about the length of the code...
So, there are a few things I want this autopilot program to do. In order they are:
Stabilize the lander (reduce attitude and horizontal drift to zero if they are nonzero). Once stabilized:
If above a target and the target's segment is safe to land on then descend on it.
Otherwise ascend to the safe height, which is above 1200 units. You can safely assume that there are no objects at this height or higher and also that during straight ascends from its initial position, the lander will not hit anything.
Once at the safe height, the lander can start going horizontally towards to its target, if a target is given, otherwise it should target the first safe landing spot that is can sense by scanning the terrain in one direction. It is important that the lander maintains its altitude while it moves horizontally, because it cannot sense objects next to it and there could be objects anywhere below this height.
Once the target x coordinate is reached and is found to be safe to land on, start a descend.
If the target x coordinate is is reached, but the terrain is unsafe, if a good spot has been seen while moving towards the target, go back to it, otherwise continue searching for a good spot.
Once a good spot is seen, just land on it nice and safe.
Ok, so, I've updated the code. My code is now able to land the lander in all tests (except one, got fed up, the code works close enough) where there is no target. However, I am having huge troubles figuring out how to get the lander to land at a target. Any ideas with my code so far? (actual used code is found in the ComputeLanding subroutine)
Here's a hint: try approaching the problem from the other end.
Landing is almost equivalent to takeoff with time reversed. The only thing that doesn't get reversed is fuel consumption. (Whether that matters depends on whether the simulation counts fuel as part of the lander's mass. In a realistic sim, it should, but at a glance, it looks like yours might not.)
The optimal way (in terms of fuel efficiency) to take off in a rocket is to fire the engines at maximum power until you're going fast enough, then turn them off. The slower you climb, the more fuel you waste hovering.
Thus, the optimal way to land a rocket is to freefall (after a possible initial burn to correct heading) until the last possible instant, and then fire the engines at full power so that you come to a stop just above the landing pad (or hit the pad at whatever velocity you consider acceptable, if that's greater than zero).
Can you calculate what the right moment to turn on the engines would be? (Even if you can't do it directly, you could always approximate it by binary search. Just pick a point and simulate what happens: if you crash, start the burn earlier; if you stop before hitting the surface, start it later.)
(Ps. This seems like a rather silly exercise for a Perl programming course. Yes, you can certainly solve this in Perl, but there's nothing about Perl that would be particularly well suited for this exercise. Indeed, this isn't even fundamentally a programming problem, but a mathematical one — the only programming aspect to it is translating the mathematical solution, once found, into a working program.)
You could use a genetic algorithm for the lander implementation check out this book AI Techniques for game programming. It has exactly what you need with code examples. However, those examples are in c++.