diff --git a/Models/HammerHead/References/HammerHead.png b/Models/HammerHead/References/HammerHead.png
new file mode 100644
index 0000000..bec8d70
Binary files /dev/null and b/Models/HammerHead/References/HammerHead.png differ
diff --git a/Other/000_Notes/AI Patrol Paths.txt b/Other/000_Notes/AI Patrol Paths.txt
new file mode 100644
index 0000000..4032bf4
--- /dev/null
+++ b/Other/000_Notes/AI Patrol Paths.txt
@@ -0,0 +1,18 @@
+AI Patrol Paths
+
+Patrol Paths are used as either straight lines or splines so in the editor you should set the
+"Spline Type" under the path menu to "Linear" or "C-R".
+
+
+
+Path Properties (set in the editor for each path):
+
+"type" = "PatrolPath" : need this part, its what tells the game its a patrol path
+
+
+
+Node Properties (set in the editor for specific nodes on a path):
+
+"WaitMin" = "1.0" : When the unit gets to this node, they will wait for a time between
+"WaitMax" = "2.5" : waitmin and waitmax before going on.
+
diff --git a/Other/000_Notes/AI notes.txt b/Other/000_Notes/AI notes.txt
new file mode 100644
index 0000000..acfd1fa
--- /dev/null
+++ b/Other/000_Notes/AI notes.txt
@@ -0,0 +1,116 @@
+You can now set how far AI units will go to get into a vehicle. The default is 50 meters.
+
+
+Flyers will now only land at "land hints" that are ready to be placed in the editor. This will allow us to guarantee that flyers land safely. You should place the hints in fairly open areas, to allow the flyers some room for error. The direction of the hint is important - it tells the flyer which direction to land in. So, for example, if the hint direction points to the right then the flyer will approach the landing spot from the left. Bear in mind that the flyers need a safe landing approach distance of say 50-100 meters. I’m relying on you to make sure this approach path is safe ;-)
+Also, the landing hints take an optional command post parameter. If you don’t set this in the editor, then the hint is associated with the nearest command post, so you should rarely need to set it manually. The AI uses this data in the following way: if a flyer spots a non-owned command post that has a landing hint associated with it, the flyer will land, the AI soldier will jump out of the vehicle and try to acquire the command post. Transports also use the landing hints. They will land at friendly command posts to pick up soldiers, then fly and land at enemy command posts to deploy the soldiers. You can place multiple land hints around the same command post to give the AI several places to land.
+By the way, like I mentioned above, flyers now need these landing hints in order to land at command posts, so until you have added these to your maps flyers will not be landing L
+You can still use regular MoveTension, and that sets all directions to the same value.
+
+
+Here’s a brief description on how to make the AI defenders stay in defensive positions.
+· Place snipe hints at the defensive positions. Make sure the direction of the hint faces the forward-facing direction for the defender. Set the mode of the hint to "Defend". Don’t use the MetaNode property.
+· In the lua script, add the following: SetDefenderSnipeRange(170)
+
+
+I’ve added functionality to the AI so that when a command post is taken, any nearby units (within 60m) from the original owning team will try to immediately reacquire it. Previously, an enemy soldier could take a CP and any nearby original team’s soldiers would just keep running away towards other CPs.
+
+
+
+
+
+I've added a new parameter to the ODFs called AISizeType. This is basically the size category that the soldier/vehicle will use when referencing the connectivity graph and new barrier system. Example:
+
+In rep_inf_assault.odf:
+
+AISizeType = "SOLDIER"
+
+Your choices for this are SOLDIER, HOVER, SMALL, MEDIUM, and HUGE, which are the same flags that are set in the editor when creating the barriers or the path planning graph.
+
+If there isn't a tag in the ODF file (none have them right now), it defaults to SOLDIER.
+
+
+
+
+
+
+
+
+I put some timers in the AI code to help optimize the connectivity graph. Each time a path is requested in the game, I time it, and then I show those on the screen by connectivity graph connection. This way you can see which legs are slow and should be optimized. The end result of this should be that the AI guys aren't standing around any more.
+
+By optimizing I mean mostly adding more nodes so the connections in that area are shorter, but this could also mean messing with the barriers (tighten them around objects, etc...)
+
+There are three different commands for this in the game (type in the console, no quotes):
+
+"pathcost tot"
+"pathcost ave"
+"pathcost max"
+(also "pathcost sum", explained below)
+(also just "pathcost", which will turn it off)
+
+
+They all (first 3) show the same information, just sorted on the different columns (I'd suggest "pathcost tot"). Type one, and you get a whole bunch of numbers on the screen. The top section deals with the individual connections, which is where you look to figure out which connections to optimize. The columns are:
+
+Cnt - how many times this connection has been requested.
+Ave - the average time taken to calculate this connection once.
+Tot - the percent of all pathfinding time spent on this connection.
+Max - the max time taken for one calc.
+Conn - the connection name in the editor (C16 = Connection16)
+
+So the useful information you can get out of this: the total ("tot") column shows where most of the effort of the pathfinding is going. Ideally these should be pretty consistent (and below 10). If one connection is at 35% and all the rest are below 7%, either that one leg is really slow, or a lot of people are requesting it (or both). But either way it's a good one to optimize. Look at the ave column, if that's higher than the rest (say its 0.025, the rest are 0.008) than you know that the leg is just too slow, so try to shorten it (break it into two). If the ave column is fine (<0.010), but the count column is big, then then leg is fast but its getting a lot of use, so it may be worth optimizing anyway.
+
+Also there is a special connection in the list called "none", which is where it times paths that aren't on the graph. If the ave time for this is bad, than there are probably parts of the world not covered by nodes. I'm working on a way to make this clearer.
+
+
+There are two more sections at the bottom of the screen. The first is the path queue time. This is essentially the delay from when a path is requested to when it is processed (this is less important than the section below). The first column is the number of paths requested, the second is the average queue time, and the third is the max. There are two rows, the first is the total for the entire game, and the second is only for the last 10 seconds. In an ideal world the second number (ave time) of both rows should be under 5 seconds.
+
+The third section is the idle time of the AI players. This is the actual time that AI guys are standing around doing nothing waiting for a path. This is different than the section above since AI guys will calculate their next path while running, so they only stand around waiting (idle) if its not done yet when they stop. This section is obviously the key number that you're trying to reduce. When its 0, nobody is ever standing around. This is good. The columns for this are the same as the section above, being: count, ave, and max, and split between total game time and last 10 seconds.
+
+You can get only the second two sections to display by typing "pathcost sum", which is better if you're trying to see the game too.
+
+
+You will notice that some of the lines turn red. For the connection list, this means that you should look at this leg to consider optimizing it. For the bottom sections, this means the wait times are too much. If you can get the bottom lines to be green all the time then you've probably optimized enough.
+
+Even if some of the top lines are red, you really only need to work on optimizing a connectivity graph if the idle time (last two lines) is red, otherwise everything is ok.
+
+
+Ok example time.
+
+Load Naboo2 and type "pathcost tot" in the console. Watch it for a minute or so until the game gets started and the numbers even out. There will be two red lines in the connection list. The first is probably "none" with around 30% in the tot column. Look at the ave column for this its 0.001, which is fine. The reason that its getting so much total time is because there are 1500+ hits in the cnt column. So ignore this one.
+
+The other red line is C44, which is getting a bunch of hits (200+), and has an ave time of 0.006 sec. Both of these are ok numbers, but together they're using 18% (tot column) of all pathing time. If you load up naboo2 in the editor you'll see that Connection44 goes through some buildings and has a whole lot of barriers in the way. So this would be the first connection to look at if you were trying to optimize it.
+
+But fortunately if you look at the bottom two sections, you'll see that the queue time is probably around 2 seconds, and the idle time is around 1 second. Both of these are very good numbers, and mean that an AI guy will usually wait around for only a second. So you really don't need to optimize anything on this level.
+
+Example two. Yavin.
+
+The AI guys used to stand around a lot on yavin, mostly because they were waiting for paths. It was really slow because of all the trees and stairs that they had to path through.
+
+I went through yavin and optimized it, to see if this process would really work. It does. I got the idle time down from 30+ seconds to about 5 on the ps2. This is probably as good as its gonna get without clearing some of the trees out.
+
+If you want to see the numbers when they're slow, go into sourcesafe and get the yavin1.BAR and yavin1.PLN from before this morning. The slow legs are shown very clearly. In the new graph I shortened some of the problem legs, then where it was still slow I made the barriers tighter around the trees and objects (to give more room for the paths). There is probably some more work that could be done, but the AI guys move around a lot better even now.
+
+
+A few new AI console commands that may come in handy when building levels:
+
+As always you have to turn on AI mode first by typing "aimode 1" or setting it on the command line with "/ai".
+
+
+"ai.showobstacles 1"
+This shows the barriers in the world as before (green boxes), but it also shows them expanded by the player's radius (blue boxes), so you know exactly where a player will fit. If two blue boxes are overlapping, the player will not path between them. It expands by the radius of whatever vehicle you're in as well, so if you get in an ATST, the blue boxes will expand to the size that an ATST can path through.
+
+"ai.notext 1"
+This turns off all the white text that follows around the guys when AI mode is on, so you can see other things.
+You can also set this on the command line with "/ainotext".
+
+"ai.showallpaths 1"
+This will show the paths of every AI player in the world (red lines), so you can get an idea of where everybody is going. (if the lines go through solid objects, it's probably a good sign you're missing some barriers)
+
+"ai.showconnectivitygraph 1"
+Shows the connectivity graph in the world as yellow cylinders/lines.
+
+
+Using the SetMaxFlyHeight(30) in the lua, you can now set the max height for jet- and dark-troopers.
+
+
+
+Try "showflyerheights" to view the height in the game. Change it with "ai.aimaxflyheight".
diff --git a/Other/000_Notes/AI_Visibility/AI Visibility.html b/Other/000_Notes/AI_Visibility/AI Visibility.html
new file mode 100644
index 0000000..305c1b2
--- /dev/null
+++ b/Other/000_Notes/AI_Visibility/AI Visibility.html
@@ -0,0 +1,75 @@
+
+
+ AI Visibility
+You have three ways to play with the AI view distances. They all work at
+ the same time, so a character's vis value is: Lua * Foliage * Region
+
+
+Lua Vis Factor
+You can set the overall view distance in the level lua:
+ SetAIViewMultiplier(0.45)
+
+
+That means that over the entire level, AI can see 45% as far as normal.
+
+
+
+
+
+
Foliage Vis Factors
+You can set visibility modifiers on foliage, which, for example, allows you
+ to hide inside bushes on endor. Do this by adding a line into the .prp
+ (foliage prop file) for the level. As an example, here is layer from the endor
+ prop file ("worlds/end/world1/end.prp"):
+Layer(1)
+{
+ SpreadFactor(0.5);
+ Mesh()
+ {
+ File("end_prop_fern5.msh", 30);
+ Frequency(20);
+ Scale(1);
+ Stiffness(0.0);
+ CollisionSound("foliage_collision");
+ AIVisibilityFactor(0.7,1.0);
+}
+
+ Mesh()
+ {
+ File("end_prop_treeclump_1.msh", 50);
+ Frequency(50);
+ Scale(1);
+ Stiffness(0.0);
+ CollisionSound("foliage_collision");
+ AIVisibilityFactor(0.35,0.6);
+ }
+}
+
+The two red lines should be added. You can adjust the visibility per model, with
+ a value for crouching and standing.
+The first means that for the foliage model "end_prop_fern5", you will
+ be 70% visible from AI if you're crouched inside it, but 100% visible if
+ standing inside it.
+
+The second model ("end_prop_treeclump_1") will give you 35% visibility when
+ crouched, and 60% when standing.
+
+
+
+
+AI Vis Regions
+
AI
+ Visibility Regions allow you to set regions in the world editor that affect the
+ AI's visibility of anything inside that region. Vis Regions work on both
+ players and AI, but not so well on vehicles.
+
+To make them in the editor, create a new region and hit the "Change Type" button
+ to select the type "AIVis".
+
+Then set the vis multipliers for crouch and stand. These are a multiplier
+ on normal visibility, so 0.5 means that you're 50% covered, while 2.0 would
+ mean that you're visible twice as far away as normal.
+You can only be inside one vis region at a time, so if the regions overlap, it
+ will randomly pick one of them and use that value. This is fine as long
+ as the overlapping regions all have the same values.
+
\ No newline at end of file
diff --git a/Other/000_Notes/AI_Visibility/AI Visibility_files/aivisregion.jpg b/Other/000_Notes/AI_Visibility/AI Visibility_files/aivisregion.jpg
new file mode 100644
index 0000000..bf94f65
Binary files /dev/null and b/Other/000_Notes/AI_Visibility/AI Visibility_files/aivisregion.jpg differ
diff --git a/Other/000_Notes/Difficulty.html b/Other/000_Notes/Difficulty.html
new file mode 100644
index 0000000..86f7a79
--- /dev/null
+++ b/Other/000_Notes/Difficulty.html
@@ -0,0 +1,102 @@
+
+
+AI Difficulty
+Command Line Options:
+
+
+
+ /DisableAIAutoBalance
+ |
+
+
+ This will disable auto balancing for the entire game. Use this to pure balance
+ your levels.
+
+ |
+
+
+
+
+Console debugging commands:
+
+
+
+ aidiff
+ |
+
+ Dumps the difficulty to the console, and also to the debug output (TTY on ps2,
+ DrWatson for xbox):
+ Profile setting: MEDIUM
+AutoBalance: ACTIVE
+ base lua auto = total
+Player : 10 + 0 + 0 = 10
+Enemy : 12 + 0 + 0 = 12
+
+ This shows the current profile difficulty setting (EASY, MEDIUM, HARD).
+ Then it says if AutoBalance is turned on. You can control this with the
+ lua EnableAIAutoBalance() command. The modes shown are:
+ ACTIVE - AutoBalance is enabled and currently working.
+ INACTIVE - Its turned on, but not currently active. Probably because one
+ side has infinite reinforcements.
+ DISABLED - not turned on.
+ Then it shows the difficulty setting calculation. "Base" is the base value
+ that it gets from the profile setting. "Lua" is the adjustment modifier
+ that you can set in the lua with the SetAIDifficulty() command. "Auto" is
+ the modifier from the auto balancer. "Total" is the final value that it
+ uses.
+ |
+
+
+
+
+Lua Script commands:
+
+
+ | EnableAIAutoBalance() |
+
+
+ Turn on AutoBalancing. This will work for Conquest/Assault/CTF
+ games. Not campaign. Basically if the score gets too far in
+ one teams favor (+/- 40 conquest, 60 assault, 1 ctf) it will make the loosing
+ team better and the winning team worse until things get back to close again.
+
+ |
+
+
+ | DisableAIAutoBalance() |
+
+ Turn off AutoBalancing. It is on by default so you should use this for
+ your campaign mode scripts.
+
+ |
+
+
+ | SetAIDifficulty(player, enemy) |
+
+ This will set the current difficulty modifier. The two values are for the
+ player's team and for the enemy's team. These are only modifiers on the
+ current profile setting, so you don't need to set these at all if you
+ want. All maps default to (0,0).
+ SetAIDifficulty(-2, 3)
+ This will make the AI on the players team 2 settings easier, and the AI on the
+ enemy team 3 settings harder.
+ This can be called from any point within a mission. So if you want the bad
+ guys to be more difficult on just one objective, call this with say (0,2)
+ in the OnStart function, then call it again with (0,0) to reset it in the
+ OnComplete function.
+
+ |
+
+
+ | SetAIDifficulty(player, enemy, diff) |
+
+ This works just like the above, but only for a specific profile setting.
+ So if you want to leave medium alone, but make hard mode harder, you could do:
+ SetAIDifficulty(0, 3, "hard")
+ The last value can be "easy", "medium", or "hard".
+
+ |
+
+
+
+
\ No newline at end of file