Monday, March 28, 2011

Some more thoughts on my 3D Cone

Alright, so in case you can't tell, I've figured something very important out. The sphere of range around my turret isn't really a sphere. It's more of a cone.

The XY range plane is a sphere because it stretches out to 254.929 in all directions around the turret. Next, as I shrink that XY component of my vector, the heights I can hit will increase. I mentioned this near the end of my last post. I did some thinking, and I've come to believe that there is a directly... or inverse relationship between the two. if I target an object at the end of my XY plane, then the Z height of that object when I hit it will be 0. But If I move back a bit then I can hit a target a little farther up, a little inductive reasoning later and I see the max height of my projectile show up. When can I hit the object directly overhead of my turret? When it's XY plane coordinate is (0,0). So, by this logic, I get a cone. Because of this I'm unsure if my method of comparing magnitudes of the vectors will work this time. Rather, I think I should compare the components of the vector instead. Such that, if a XY component (I'm lumping the two together, so technically I'll still be using that magnitude) and a Z component make up a ratio that is greater than... can that be expressed as a ratio? The two are inversely proportional...

If the two components added together are more than 254 than I think it's out of range. Because say some object is 100 units out on the XY plane. Obviously in range XY wise. But if the height is 200 on this particular object? Then by my proportion It's out of range because 100+200 > 254.  Also, I've worked out this example with the wonderful physics formula arctan(v^2+(or -) the square root of (v^4-g(gx^2+2yv^2))) all over gx where x and y are the distance times the cos and sin of the angle of elevation of the object. So I think I can use my proportion to test check to see if things will be out of range or not.

You might be thinking, why doesn't he just use the dang formula from wikipedia to figure it out? My answer? I need to compute these distances and calculations on estimated positions in t amounts of seconds and all that arctan square root lalala is expensive. And if a simple proportion can tell me if somethings out of range or not before I start doing calculations, I'll be quite happy. And thus, I am.

Oh, it was also my birthday yesterday

Saturday, March 26, 2011

Maximum Height

Well, I started working out how to figure when to stop calculations because the target is out of range. And it seems complicated, to say the least.

First off, imagine a semi-sphere with a radius 254.929 units. This is basically the max distance for my turret, but the thing is, when I 'fire' a projectile straight up, if I increment my update function with a value of 1 second, it tells me that the projectile will reach maximum height around 6 or 7 seconds with a height of a little more than 270. This, is wrong. As I lower my increment function to say, .5, it shrinks to 265 or so, then to .25 it lowers to 260ish. Always around 6 or 7 seconds. but the thing is. The calculations performed should still give the same amount of height given the same amount of time. I don't understand why it's not. I noticed that as I lower the increment for time to update, the height approaches 254.929, but still. I can't use an approximation, or a bound for my max distance check if it changes by the time increment. It throws things off, as I'm sure you an understand.

So, what is wrong with this code?


//if you add in terminal velocity to the recalculation here first
pos = pos + vel * t;
pos.z = -.5*g*t*t + vel.z * t + pos.z;
if(pos.z <= 0 ){pos.z = 0; vel = Vector3D(0,0,0);} // no negative z's
     vel.z = -g*t + vel.z;
     //no exceeding maximum distance traveled
     if(pos.x > maxD){pos.x = maxD;}
     if(pos.y > maxD){pos.y = maxD;}
     


I don't know. The position is calculated by it's velocity and position vectors. The z position is recalculated using the height function I've found with physics. If the proj hits the ground it's velocity stops. the velocity of the z is affected by gravity by the equations of gravity. And then if the positions of x and y are greater than the maxD 254.929 then they are reset, because they should not be.

Anyway, the issue is in checking to see if the turret should even bother with trying to target an object. If the object is out of range than no attempt should be made. Basically I need to check to see if the object is within my sphere. But that's hard to do. I feel like I should be using arc trig functions to find a lenght of an arc that is whatever my arc length would be? I'm not sure.

In case you're wondering where some of the numbers come from. The 254.929 is the projectile fired at an angle of 45 degrees. Of course this only gives the max distance I can fire off into the XY plane. Making the base of my semiSphere. The maxHeight, is, I believe something along the lines of 254 as well. It would make sense... But then drawing that arc from that imaginary pole to the maxDistance line is... well, I don't know how to do it I suppose? Although...

The radius of my semiSphere is 254. So... 254 * sin theta will give me all the possible heights I can hit? I believe? Which would range from 0-254 if I'm not mistaken. I suppose, I could resolve the vector of the target into it's component vectors and then check those to make sure they're less than 254? But then what if an object is floating around at 254,254,2? Answer? I can't hit it! So it must have to do with the sum of those numbers I suppose? I've been trying to do it with magnitude but I'm not sure if that's correct because of this:

The magnitude of a vector(254,254,254) is 441.55 and without gravity, the distance a projectile can travel is 360.5 (velocity of the projectile (50 units /s) * the maxDistanceTime (7.21))  And if I compare these two, then there will be many cases where the function says: no can do. And I do agree with it in this example because 254,254,254 would be hovering waaay above. So, I suppose... I can hit something at (254,254,0) can I hit something at (0,254,254)? That would mean it's aligned with me on the x axis, but is lying out at the end of my range in the y... floating at 254z. That would be a no. It's mainly the Z that's the kicker, there must be some relationship between the XY components and the Z components. (254,254,0). I mean, 254-254 is 0, so is a bunch of other random stuff though. Halfway out, 128,128,128 I'm pretty sure I could hit. It's well within the XY range. If I do the math out: if it's about 221.7 out from the turret. which even though within the supposed maxD. I'm just still confused.

I think where I'm getting confused is that I keep thinking of the angle as being 45, and my range as being a sphere. When I think it might be more of a cone. Because I can move my Z angle up and down I can hit anywhere from 0-254 in height, but as the height gets higher, the target has to be closer. I just need to figure out that relationship first...

Grar math!

Friday, March 25, 2011

Gravity: Thou art a _ _ _ _ _

I've made progress in my 3D Turret program. I've (unfortunately for my poor brain) decided to include gravity in my calculations. Mainly because I'd prefer for my calculations to not shoot off into the sky without ever coming down again. Gravity's good for that sort of thing. Unfortunately, it's also good at making you do a bunch of calculations for determining maximum distance, terminal velocity, and a few other things. I did have a model that was close to what it should be, but the calculations it was making wasn't quite right. (Specifically it was 2 seconds later in hitting the ground than it should have been)

So I decided to peruse Wikipedia a little, specifically the free fall, projectile motion, and trajectory pages. They're plenty of nice equations ready to use. And although I was slightly saddened that I had admitted defeat in a way and just looked up the answer. The equation's were very similar to the ones I had devised. I had a big comment written at the top of my code that GRAVITY IS M/S^2, but for some reason I didn't square the time in my calculation for figuring the new z position of the projectile. But besides that, my equation was correct.  My velocity updating line of code was correct though, so I was quite happy. From this figuring out the maximum distance was a matter of either running trials of different time increments or solving an equation. Or the third option not allowed by any homework ever done by a person. Look up a calculator on the internet that displays all the information when you enter the right numbers. I opted for the third approach and then tested it against my code by running the simulation to that time and making sure the z went to 0.

The only thing I'm still unsure of, is terminal velocity. Which is, unfortunately, rather annoying to figure out when you have no idea what the dimensions of your hypothetical projectile is. So I had to determine what I was actually firing (a small bullet with a mass of .04 kg is what I believe I decided on, with a cross section of 50mm^2, traveling through  standard sea level air density (1.5 kg/m^3) with a drag coefficient of (.1) (a small ball by the examples I found, although it had a bullet (.3)) it gave a ridiculous terminal velocity (small that is not large) so I decided to go with my turret firing perfectly round projectiles.

So, after all that and 1 and a half cramped notebook pages later, I have an update position function I feel like I can rely on for my calculations.

Tommorow, after doing some trivial work (required course work for a required class which pertains to my major in no way), I'll start working on the estimation process and how it leads it's target through 3 dimensions. But for now, more reading Gödel, Escher, Bach by Douglas Hoftstadter (I'm a little more than halfway through the book )

3Dimensional Turret Beginning

So I've just finished coding my 3d vector class. And now am trying to think of how I'm going to do this. I want to introduce gravity into the simulation, but this restricts the range of the turret, which is realistic, does make an infinite loop of checking for targets that are in range a strong probability. Also, I'm trying to think of how exactly to orientate and move the turret.

Heres some solutions I've come up with so far:
I could do all the calculations out like before,  OR, since I made my previous 2D turret able to accept console output I could feed the coordinates into that, but that would only orientate the XY plane correctly, and even then, how would I grab the output from the execution? So, while it sparked my brain as a good idea at first, I think I'll ignore it a bit.

I think the hardest thing will be checking for gravity and other things of that nature. I know that in some science fictions, long range projectile weapons have to account for the curvature of the earth, but I don't think that will be my problem. So, to start off, I think the angle the turret's Z will be at is 45, aka the optimal distance angle, this could change a when aiming obviously. And now, before I was just using an arbituary 2 units / s for my projectile, but with the inclusion of gravity I think I've going to have to bump it up a bit to make the projectile move fast enough to stay airborne. I mean, let's face it, waiting 10 seconds for a projectile to hit a target is unrealistic. So I'll probably beef it up to say, 50 units / s or so and then just put the target out 150 or so units.

Since I've figured out the calculations to aim and lead in a 2d plane so I have reasonable confidence in extending it to the next plane up. It's just gravity and maximum distance I'm concerned about right now. Hmm.

I'll keep you updated

Wednesday, March 23, 2011

2D Vector Turret Program Complete (For the Most Part)

Phew!
I've been working since I last posted about the problem I ran into, and I have solved it. Using the good 'ol Tactics of visual representations, notebook, and my brain. It's kinda what I resort to for things like this. Anyway, I started by rewriting all my code to simplify it. The previous version I was working on had quite a phew things that could be simplified and made more efficient.

So heres a quick picture that describes what me, myself, and I (visual,notebook, and brain) came up with:

The thought process for the targeting function

Once you reduce the vectors down to their magnitude and just work with the simplest of all physics equations (v=d/t) its actually quite simple. And I'm surprised I didn't think of it earlier. If only someone followed this blog, or posted comments, they could suggest things to me. Anyway, Heres the output of my program after running it:

______________________________________________________________________
Turret Theta: 2.26553 Turret Delay: 0.268347
Turret Vectr: 0.768221,-0.640184
Turret Armed: 0 Locked: 1 Fired: 1
Turret Estimation of UFO: 10.6101,-8.61008

UFO: Pos: 10.6101,-8.61008 Vel: 1,-1 (1.41421 units / s)
Fired Projectile: Pos: 9.74371,-8.11976 Vel: 1.53644,-1.28037 (2 units / s)
______________________________________________________________________
Turret Theta: 2.26553 Turret Delay: 0.268347
Turret Vectr: 0.768221,-0.640184
Turret Armed: 0 Locked: 1 Fired: 1
Turret Estimation of UFO: 11.8784,-9.87843

UFO: Pos: 11.8784,-9.87843 Vel: 1,-1 (1.41421 units / s)
Fired Projectile: Pos: 11.6925,-9.74371 Vel: 1.53644,-1.28037 (2 units / s)
______________________________________________________________________
Turret Theta: 2.26553 Turret Delay: 0.268347
Turret Vectr: 0.768221,-0.640184
Turret Armed: 0 Locked: 1 Fired: 1
Turret Estimation of UFO: 13.1468,-11.1468

UFO: Pos: 13.1468,-11.1468 Vel: 1,-1 (1.41421 units / s)
Fired Projectile: Pos: 13.6412,-11.3677 Vel: 1.53644,-1.28037 (2 units / s)
______________________________________________________________________

As you can see, the Fired projectile and the UFO (comeon, if something is unidentified, flying at you, and an object you want to shoot, what else do you call it? ) slowly get closer together as the seconds go by. In both the last and second to last stages of the output you can see it get extremely close and 'pass' the target. But because this 'pass' is so close, it means the UFO got nailed, because I doubt the thing we're trying to shoot is only .5 of a unit in radius.

So now, I think I may contemplate moving this into 3 Dimensions. First I'll have to rework my vector2d class into a 3d vector class. Or maybe I'll just look for source code online. Wish me luck!

Problem with the Y component of Vector

Heres a sample block of output from my program:


______________________________________________________________________
 Projectile Position: 0 0
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107


Object: Position- 8.99512,0.00488001 Velocity- 0.707107,-0.707107


Pings: 1:6 2:5
______________________________________________________________________
 Projectile Position: 1.99539 -0.135725
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107


Object: Position- 9.70223,-0.702227 Velocity- 0.707107,-0.707107


Pings: 1:7 2:6
______________________________________________________________________
 Projectile Position: 3.99078 -0.271451
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107


Object: Position- 10.4093,-1.40933 Velocity- 0.707107,-0.707107


Pings: 1:8 2:7
______________________________________________________________________
 Projectile Position: 5.98617 -0.407176
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107


Object: Position- 11.1164,-2.11644 Velocity- 0.707107,-0.707107


Pings: 1:9 2:8
______________________________________________________________________
 Projectile Position: 7.98156 -0.542901
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107


Object: Position- 11.8235,-2.82355 Velocity- 0.707107,-0.707107


Pings: 1:10 2:9
______________________________________________________________________
 Projectile Position: 9.97695 -0.678627
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107


Object: Position- 12.5307,-3.53065 Velocity- 0.707107,-0.707107


Pings: 1:11 2:10
______________________________________________________________________
 Projectile Position: 11.9723 -0.814352
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107


Object: Position- 13.2378,-4.23776 Velocity- 0.707107,-0.707107


Pings: 1:12 2:11
______________________________________________________________________
 Projectile Position: 13.9677 -0.950077
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107


Object: Position- 13.9449,-4.94487 Velocity- 0.707107,-0.707107


Pings: 1:13 2:12
______________________________________________________________________


Now that you've scrolled through it here, heres the problem.

Projectile Position: 13.9677 -0.950077
 Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107

Object: Position- 13.9449,-4.94487 Velocity- 0.707107,-0.707107

Pings: 1:13 2:12
______________________________________________________________________

Do you see it? the boldfaced text? For some reason, the y velocity and such of my projectile isn't quite right. The X component is working perfectly, off by a hundreth of a unit? That's great considering rounding errors and such. But the y component is really not acceptable and I'm a bit of a loss as to why this is happening. Hopefully I can figure it out.

Not Sure about my previous solutions for the vector problems

Hm, It missed.

Monday, March 21, 2011

XY Velocity for a projectile? Solved for

Alright, So last I left off I had coded how to deal with projectiles moving in a strictly horizontal or vertical way. And was waiting on making the code for dealing with both velocities. At first I thought I would have to deal with some type of equation of two variables and solve form both of them using some complex business, but it turns out the method I use is at least 3x simpler than that.
So, first off I use the same method I've been using to get the time interval I should be using in my estimates. since I've described that in previous blogs I won't bother redefining it here. From that I get my hBound variable which is the top of said time interval. From here, I can compute how far the projectile will travel in the time given that it travels at a constant speed of 2.0 units. I then figure out the heading of my turret to aim at so it points at the targets estimated position after hBound time. From here all I need is the vector to give to the projectile as its x movement and y movement. So, using the cos of the gun's theta times the distance of the projectile as the x component and the sin of the guns theta times the distance of the projectile as the y component, I make up my vector. From this I have a triangle that may or may not overshoot the position if fired at the wrong time. So how do I figure my delay time out?

Simple, I take the magnitude of that vector I just made and divide by hBound to get how many units of time it will take to traverse this hypotenuse I've created. If that number is equal to the time it takes for the projectile to get to the estimated position then hoorah fire right away, weapons free, danger close. If its less than that then set up delay which is as simple as Time of the target - Time of the projectile. And the other situation, where T(proj) > T(target) never occurs because that would violate the work above with the whole hBound thing, theres a reason it's called the hBound you know. From here things get pretty simple.

since I have my heading, my delay time (if there is one) all that is left to do is to fire. Which is done by created  anew object that has the position of the turret, the velocity vector is the heading vector of the turret(which has been normalized) multiplied by the velocitiy I know the projectile will travel (2.0 units), ahem. Tah-dah.

Now of course is where I fork myself, should I proceed to trying to create a 3d version of this? Or should I build up a simple library in DirectX to actually see whats going on instead of just numbers? Hmmm.

Sunday, March 13, 2011

Horizontal Target Tracking

Woo!

Just finished coding the turret of my current project to lead a target thats moving only horizontally. It took me a while to wrap my head around alot of the numbers, and also I was accidentally using degrees to start off my turrets heading and not radians. Wups!

Anyway, so this is how I accomplish leading a target horizontally:


 first using vector arithmatic and dot products and arcCos, we get the heading we'll be firing on.
 then we account for possible time delays in order to account for differences in distance.

 Heres the code: there is some stuff missing that is declared a bit above, such as getting the hBound which is the time where the distance the projectile will travel becomes greater (or equal to) than the distance the target will travel in the same amount of time. This is used so that we can lead the target. But because we lead it, we need to make sure to fire at the correct time in order to score a direct hit. So thats why we do some subtraction between the amount of distance and time and all that. Anyway: Heres the code:



if(target.velocity.y == 0 && target.velocity.x != 0){ //target only moves horizontally
                //get the heading to fire on.
                estMagPos = estMagPos + estMagVel*hBound;
                Vector2D gt =  (estMagPos - gun.position ).Normalize();
                gun.theta -= acos(Dot(gt,gun.heading));
                gun.heading = gt;
                //now, account for leading and time delay
                //hBound * vel = how much distance the proj will travel. 
                //Use the gun.theta and this to resolve the vector into it's components
                //then the distance between the (hBound * vel) - x of target
                double projd = hBound * vel;
                projd = (cos(gun.theta ))*projd; // x distance of vector
                double deltax = projd - estMagPos.x;
                double waitT = deltax/vel;
                gun.countdown = -waitT; //negation to make positive. no neg times
                gun.locked = true;
                std::cout << "Target Locked. Countdown Til Firing: " << gun.countdown << std::endl;
                system("hal target lockd");


So, the calls to system and hal are just a speech program to say the string aloud. 

Saturday, March 12, 2011

Getting a bit farther with my vectors

 So I've gotten a bit father with things, these two images show some of the thought process on what I'm working on right now.
Which is, targeting and leading when the object is moving horizontally only. I've already worked out the case for the stationary target, which is the easiest, so now I'm working on the next easiest (I think) which is just horizontal movement.
this image right here shows how I was trying to think about zones and ranges of the turret.


normally, I would go into detail on more stuff. But I'm pressed for time right now, but once I get back to the world of internets, then I will gladly post and describe all the difficulties I've been having and how I've been solving them.

coming close of vacation.

So, my vacation is starting to come to a close. And I'm looking at what I expected from this vacation, and what I actually got.

I expected that I would, maybe not get laid, but find someone here who might be a friend who I could share attraction with. And maybe have a brief fling. I did kiss one of my friends, but it's normal for her and I to kiss. We're close, and the kissing really doesn't mean much. I kiss a few of my female friends on the cheeks when I see or leave them, this one I kiss on either the cheek or the lips. It's not a romantic kiss though, it's kind of like an italian kiss I suppose because it's more friendly than anything else. Anyway, getting off topic here aren't I? I expected to maybe cuddle with a specific friend and to admit some feelings for her. That didn't happen, because even though I saw her twice... maybe three times, it was always with a group. And since she invited people to events that we had planned on doing. I'm taking her hint that she just wants to be friends who tell each other they love each other and act like boyfriend girlfirend without the actual physical affection and only the virtual. It's just fake. I'm not a fake person, most of the time, and I don't especially enjoy fake. I do put on my smile for a good amount of the day, and I tend to shrug off my insecurities and sweep all my problems under an apathetic bed. I don't want a fake relationship, and I don't want a fake love, because after pretending for so long, it starts to feel like it might actually be something. I'm tired of that illusion. ... cough. I expected to see lots of friends and catch up on old times. That kind of happened, with one of my friends. The weird thing is, it was a friend who I am close with, but she was the only one who actually gave a damn to ask about me. Most of my conversations go something like this:
Hi, hi, how are you, and then they go on for a while, when they stop, they don't ask about me, so I further the conversation by asking them how their lives are going. And then the topic is them, them, them. I wish that for once or twice, maybe I could be the topic.

I think I'm mainly annoyed at the level of drama that occured while I was home. As noted by my previous rather depressing blogpost, my friend screwed up his relationship with his girl, and happened to do it with the girl who I was falling for. It's the reason I took a walk yesterday. Loaded the playlist I talked about onto my mp3 player and went for a walk in the crappy overcast weather. It was good, I got a good amount of thinking done. I was trying to figure out if I actually really like the girl enough to go for it, or if I'm more attracted to her as a friend. I didn't really figure too much out. But, I do think I'm attracted to her based on our common fuck ups. A'la she has baggage. Much in the same way I do. She still thinks about her big ex, and mentions him a lot. He was a big part of her life, so its no wonder a lot of things still remind her of him. And I think I like that about her, because I feel the same way about my ex from a long time ago. Everything still reminds me of her. Maybe that's why coming back home is kind of painful sometimes.

I expected more from my vacation, maybe some sunshine. I know I can't control the weather, but I've seen the sun once this entire week. It's frustrating when you want to go out and do fun things with friends, but they dont want to because the weather is shitty. It's rather annoyying and difficult.

I guess, when it comes down to it, I am looking forward to go back to VT, when I've talked to people over SMS, I've had to erase a part of a text that said: I only have x days before I go back home, multiple times, I guess I consider VT more home than this place to some extent. Maybe it's just nice to have a freshstart and not have all the people who already know you and stuff. Start new, find someone new, who hopefully wont fuck up my mind like my ex did.

Wednesday, March 9, 2011

Turret Estimation

Workin on my program some more:

So I've come up with a bit more code, and a few more interesting problems. I think I've figured out how to use my vectors correctly. I can use velocity vectors and position vectors to estimate the locations of objects. It's great.

The problem I've come up with is how to figure out where to rotate my turret to in order to fire. Because I have a few variables I need to keep track of, and keep in mind.

1. The projectiles statistics: the bullet or shell to be fired by the turret has a velocity vector and position vector. Once I move into a 3d space I may include a mass in here. But besides that, velocity is a straight float, why? Because I don't know which x y components to give the vector because I don't know the theta. so, a straight number like 2.5 m/s or something, allows me to estimate where to shoot the bullet. This will make sense once I describe my idea for this.
2. The target objects estimated path using the pings. This gives me a velocity vector and a position vector for the target.
3. The current heading, or theta of the turret.

So, my method, is briefly describe in the picture below.

I ran atrial of it last night, and it appeared to be working, but I do need to iron out some kinks in the simulation

Thursday, March 3, 2011

Radar Tracking Turret!

I came up with a new idea to code! It will probably take up a good chunk of my nights during spring break

I simple turret that tracks and fires at objects in its pinging field, in 2d space. Once I get that working, I'll think about working in 3d space.

Here are a couple of my sketches for ideas:










ok, so the first image is how the ping system will work. The second is how the pings data will be used to determine the vector of the object being targeted. and the last is how the turret will estimate where to fire.

So this is how I plan to do it. No code yet!
Have the turret object which will hold its own cordinates in its plane, its angle of firing and a pointer to its projectile loaded.
The projectile object will have a velocity and x,y cordinates. (once I move to 3d space it will have mass and other things)
The target will have an x,y and a velocity and theta for movement.
Then there is the collections object that will store all these things. this will be used by the pings sent out by the turret to let the turret know the location of the target object.

A few of the details still need to be worked out. But I've got enough that I can start a basic console prototype

Wednesday, March 2, 2011

OCaml Pattern Matching and etc.

I've a midterm tomorrow, in 3 classes. Anyway, calculus isn't hard. German will be alright. But programming languages, not that it will be hard, but just.... Ok so, we're allowed to use our notes we've taken in class as well as the daily summaries that he has given us in the past. Unfortunately, I've been taking all my notes in LaTeX on my computer. Which means I need to print them. Which means I need a printer, which means I needed to get my roommate to print it out. Which means I went and did something fun and asked him to do it. I came back a while later, and bam. Thirty Five Pages. THIRTY FIVE BLOODY PAGES of notes. Granted that's for the entire first half of this semester. But... It's computer paper! Formatted! To what looks like 10 size font. That's a lot of characters. Plenty of bits.

Anyway, besides that, I've just completed programming a reverse polish notation calculator in OCaml. The powers of pattern matching are spectacular. For anyone who has never programmed in Objective OCaml, I'd recommend attempting to. The type system is very nice, even if trying to figure out your error messages is a pain in the ass. I normally love my C++ but I do enjoy OCaml's elegance factor.

This semester seems like it's been quite a jump in what I've learned as far as CS goes. Before this semester I had no idea how to use php, javascript, server side includes, ocaml, unix file commands, batch file commands, and some directX code. Its a trend I would like to keep, this upward mobility of my learning. I like.