Burst fire rate, cannon audio and bullet update in place. Debug output shows I'm hitting objects but as yet no visuals. Tomorrow I'll add the muzzle flash and some bullet object visual. It's easy to impart the force of the round to an object, so I look forward to adding lots of oil drums into the test area tomorrow.
We might actually pull off this challenge. Still missing fire and an entity damage system.
Little happy dance.
*end of additional*
Arming systems are done. The TrackIR head-motion sensor updates the cannon and pilot night vision orientation. We took time out to fix up the oil dampener rods and ammo belt feed that go from the rotating turret into the elevating gun barrel assembly. The rods and ammo belt extend with gun depression.
Looking left and down - near full depression
push rods extended
Looking right and down
It's possible to stick the gun into the dirt when landing. Remember to de-action the gun, or turn off the ARM switch. When sat on the ground the squat switch imposes movement limits to prevent damage.
Operation Longshot/Commence Fire/GreenHorn
A lot of fun making up stupid names for the new training scenario. We do however have a new training camp to fly missions out of. As of yet unnamed.
Could use some ageing and maybe an alternative pad that just has some parking spaces marked. All a wip of course.
Currently working on a gravity only model for ballistics.
A production quality "Firing Range" is in progress. One day of work and it's shaping up quite nicely. It's a fictional location built for hosting US Army rocket and cannon drills. Incorporating lanes for running fire/diving and hover attacks.
I think you can see some of the exploding crater objects in the first shot. Other major features include a small lake and a dry riverbed.
Dave used Terragen rather than DEM files, this results in a much better quality of landscape, smoother, no terracing artefacts. The training area, will incorporate a small FARP facility, clearings for landing and take-off exercises. Ranges are approx 500m across, will be populated with assorted wrecks, containers.
And since Apaches don't normally carry tracers but for sake of observation and programming the ballistics (in the next day or two) we will be showing these.
Go team (working Sundays, must be mad, who's paying for this?)
*update*
Head tracker position now updates the gun turret as well as the PNVS. Switching to external view and moving your head shows both systems responding quite well. I need to introduce a lag curve to smooth positioning and add a limiter to turret movement. Some model issues to resolve, the gun mesh origin is a little off axis and the barrel axis is at the wrong end.
Cannon and PNVS slaved to TrackIR
Pilot view angle (mouselook, keyboard or TrackIR) updates the PHS vector (pilot helmet sight) of the playerHelo object through a call to <vehicle object>.UpdateHeadPosition(crewIndex, vector). For AI, the update is the same. Multiplayer update should come via TStateMini, not yet implemented.
Position updates are deferred since either system may be going through a STOW operation.
Next: WEP page fix and control inputs for weapon selection/cycling/fire.
Dave completed preliminaries for the tracer fire objects. Some questions about best use of materials. In 'FLIR' mode, or heat-vision, we'll want them to glow pretty hot. We have 4 tracer colours made up.
editor shot - red tracer mk 1
The art department set to work on researching firing ranges. The goal is to build a reasonably accurate area for purposes of live fire exercises and use it as a pre-release mini-game to help fund continued development or just give it a bit of focus. This is a good opportunity to create what I wanted to include in the game originally, a UK or US location to complete some flight training before being sent on your campaign tour.
In almost no time at all satellite images and photos from the web were being examined for inspiration. What should it look like? Where will be based?
what does a shooting range look like?
Aldershot small arms shooting ranges
Just to get a feel for terrain, colour, size, scale. When you're starting on something new, collect data.
We'll probably have a geographically neutral location with a fairly generic set of firing ranges, green, lots of trees and clearings. Observations towers, targets. Enough to allow pilots to get familiar with cannon and rocket systems.
new arm switch
We also updated the cockpit too, with dual operation master arm switch (in yellow) with the ground override. The squat switch now triggers a vehicle event, this is sent to the avionics class (on landing it disengages master arm if the ground override switch is off). A veritable spiderweb of things going on here, you have potentially two players operating buttons which are also flagged by the vehicle landing/taking off. Sorry I call it a vehicle as the helicopter is derived from the vehicle base class (class hierarchy is: ApacheHelicopter > Helicopter > Vehicle).
Being a very visual person the right side of my brain is dominant, I can see enormous complexity visually but totally suck at trying to use words to describe them (left side of the brain) so I apologise if I'm not doing a good job. This is also why I do really badly in phone/skype interviews, the wrong side of my brain is engaged leading to total confusion. I digress.
Next we'll slave the gun to the pilot head position adding a limiter on -elevation if the squat switch is on (see why we needed that thing now?) Then to activate the gun reticle in the IHADDS code which I haven't seen in over a year. What are the odds it still works?
The book, "C++ Coding Standards" by Herb Sutter and Andrei Alexandrescu made me chuckle, it carries my favourite quote, "The great thing about standards is that there are so many to choose from." It's a very sensible book for C++ programmers interested in best practice.
Some nice things happening at the business end which I can't discuss but it's put me in a happy mood. I need to keep this update short as there's lot to do today.
Last night I had to go back and address some potential problems with the "weight on wheels" function, sometimes called the "squat switch". This is a mechanism that tells the aircraft electronics that it's weight is on its wheels. This was a detail which was not added until a few days ago and every helicopter derived from the TVehicle class has it. It's implemented as a measure of lift-force and a raycast below the left and right wheels. Helicopters have a variable array of wheels that is filled out when each helicopter class is initialised. For the Apache we just have two main wheels, objects defined in the model as "landing_gear_left_wheel" and "landing_gear_right_wheel". That's another example of how the artist uses an object naming convention to describe the hierarchy in the vehicle, in a similar manner to the cockpit. I know there's a tail wheel on the Apache but we treat this as a special case due to how it operates.
* edit * Switch only on the right 'strut', remove left wheel check.
Wheel size is a function of the mesh AABB size dived by 2. (AABB is a structure that describes a bounding volume of something, in this case the wheel object)
this.childWheelRadius = aabb.Z0 / 2.0;
I'm beginning to waffle again. There are currently two LOD models used for the Apache (interior and exterior) which have subtle differences, so that needed to be taken into account. Suffice to say it works correctly now and should be fine when we add gear compression later. Or the Chinook for that matter.
The A/C switch on the MPDs call up different pages depending on that status of the squat switch (thus SHATTERING, I said SHATTERING!!!) one of the golden rules of user interface design, consistency. Well this isn't an iPhone you're operating, the battery lasts longer for one thing. On the ground it sets the "M" master mode to [ENG] and in the air it's [FLT].
MORE IMPORTANTLY it stops you from arming weapons and shooting things off whilst on the ground.
Arming or going "weapons hot" requires pressing the "A/S" (arm/safe) button pictured above. This won't activate if the aircraft is on the ground. Safety first. If you need to run weapon tests on the ground you must first press the GROUND OVERRIDE (GND ORID) switch. When this is on you will be able to activate the A/S arming switch. It should light up yellow (I think) but we only have one colour for switches atm.
I remember we had so much trouble trying to get clear photos of these labels from web images, I think we kept changing the letters as we went from one blurry mass to another. So I apologise if it's not 100% accurate, I'd rather not have to re-edit the textures.
Reference to other sims
The "ARM?" query seen in the Longbow 2 HUD is a gameplay fiction, one I copied but since removed. This has been replaced by "WEAPON?" when you pull the trigger and can't fire. An Apache helicopter will tell you when it can't shoot stuff, rather than when it can. It's kind of trigger-happy like that.
To make it easy to arm and shoot in Combat-Helo without access to the virtual cockpit interface we'll keep with CTRL M (for Master Arm) and SHIFT CTRL M (for Master Arm with Override as needed).
Work for today
Today I'll be reviewing some of the message pathways in the code to make sure the arm buttons are all working correctly, making any changes as required. Fixing up the WEP page (awol since I changed the co-ordinate system of the MFDs) and creating a new virtual class for various weapon effects.
Half a day into our team challenge we have a field of exploding craters. No pyro effects just yet but Dave built 3 crater sizes for various sizes of explosion and the following model LUA script that generates lighting flashes, plays a 3D audio effect and some rising impact dust. Additional random debris will be added later.
Simply spawn the blast crater model where you want it and this script does the rest.
Effect_explosion_small.lua script
require("scripts/class")
local class=CreateClass(...)
class.bang_loud = LoadSound("abstract::bang_soft.ogg")
--------------------- CREATE AND PLACE MODELS ---------------------
function class:CreateObject(model)
local object=self.super:CreateObject(model)
object.rand = math.random(15,25)/1000
object.timeout = 250
object.launchtime = AppTime()
object.crater1 = LoadMesh("abstract::crater_large.gmf")
object.crater1:SetPosition(object.model:GetPosition(1),1)
object.crater1:SetScale(Vec3(object.rand,object.rand,object.rand))
--------------------- CORONAS ---------------------
local flash1=CreateCorona()
flash1:Paint(LoadMaterial("abstract::flare1.mat"),1)
SetCoronaRadius(flash1,10,1)
flash1:SetPosition(object.model:GetPosition(1),1)
flash1:Movef(0,2,0)
flash1:SetColor(Vec4(0.8,0.58,0.5,1))
object.explosion_source = object.model:EmitSound(class.bang_loud,250,1,0)
--------------------- LIGHTS ---------------------
local light1 = CreatePointLight(20)
light1:SetPosition(object.model:GetPosition(1),1)
light1:SetColor(Vec4(1.0,1.0,1.0,1))
light1:Movef(0,2,0)
--------------------- EMITTERS ---------------------
smoke=LoadMaterial("abstract::smoke.mat")
SetWorld(fw.transparency.world)
local smoke1 = CreateEmitter(10,2000,Vec3(0,2,0),1)
smoke1:SetPosition(object.model:GetPosition(1),1)
smoke1:Paint(smoke)
smoke1:SetColor(Vec4(1,0.85,0.6,1))
smoke1:SetRadius(1,10*(object.rand*10))
smoke1:SetWaver(2)
smoke1:SetArea(Vec3(5,2,5))
smoke1:SetRotationSpeed(0.1)
local smoke2 = CreateEmitter(10,1500,Vec3(0,3,0),1)
smoke2:SetPosition(object.model:GetPosition(1),1)
smoke2:Paint(smoke)
smoke2:SetColor(Vec4(0.9,0.7,0.5,1))
smoke2:SetRadius(1,5*(object.rand*10))
smoke2:SetWaver(2)
smoke2:SetArea(Vec3(5,2,5))
smoke2:SetRotationSpeed(0.01)
SetWorld(fw.main.world)
--------------------- UPDATE ---------------------
function object:Update()
if (AppTime() > object.launchtime + object.timeout) then
FreeEntity(flash1)
FreeEntity(light1)
end
if (AppTime() > object.launchtime + (object.timeout * 10)) then
FreeEntity(smoke1)
FreeEntity(smoke2)
end
end
--------------------- FREE ---------------------
function object.Free()
FreeEntity(flash1)
FreeEntity(light1)
FreeEntity(smoke1)
FreeEntity(smoke2)
FreeEntity(object.crater1)
end
end
I wouldn't recommend saving out a scene with craters then reloading. You can guess what happens. The script would need a flag to say it's 'live' to deal with that.
Muzzle Flash
A universal object that can be attached to any vehicle with a "barrel" child object. Flash duration set to 5ms, but I need to review health and safety guidelines concerning epilepsy and shape it the best I can.
Dave is working on tracers and debris objects now. Ballistics in a network environment can be tricky to handle in multiplayer environments. To make the physics deterministic (ensure that results of calculations are the same across clients) we're sending source/destination vector, time of launch plus time in flight. The synced game clock should have enough information to create the round across clients in the same position.
Some objects have special cases, such as those having having dual barrels (e.g. ZSUs).
Ballistics will follow a curved path of course using data obtained from the A model Apache Dash 10 Operators Manual. A deterministic scatter pattern will need to be generated across clients for which I think I have a solution. But I'll leave this for a blog entry later in the week.
Visual style and it's origins (no pun intended)
If anyone is interested in origin of the visual style here is the video that sparked it off. It was created by Chris "BeachAV8R" Frishmuth and posted July 2009. Janes F15 III, the last of the great fun combat simulations of that era (IMHO of course).
While we evaluate the project and re-prioritise, Dave thinks we should start getting offensive so our new challenge for the week is: Implementing a working Bushmaster cannon, symbology and blowing up effects.
Well we don't have much else to do. Dave likes guns and I want to demonstrate head-tracking, together we find common ground in the Apache's awesome Bushmaster cannon.
Gun cam (early HUD)
For the next 7 days we'll be adding lighting, flashes, gun tracking, adding code to place-holder avionics functions to tie it together. Oh and some explosions too. Woah. In a week? Well it IS a challenge.
In the space on an hour (while formulating this blog entry) we have sound effects and a totally oversized effect spewing from our Apache.
Our first pass specification is as follows:
Flash object and 'glow' material
Bushmaster cannon sound effect (done)
Easy arming mode and gun select
WEP page already has burst select mode (arm symbology)
Pilot/copilot acquisition of gun control
Slave movement to head tracker
Ballistic calculation
Ground target pivot (invisible) used to minimize parallax errors from dual seat lag.
Explosion and fire effect (heh, easy to do badly, hard to do right).
OK, time to put on some coffee and do some research. LEEEEEEROOOOOOOOOY JENKINS!!!!!
Good suggestions and comments there. We'd always planned a flexible a feature list that could be trimmed from the tail backwards to meet the projects 18 month expected overrun. Shaving off extensive features like the Hellfire launch system would work in our favour for releasing a demo/trial. The Hellfire system isn't (often) deployed in the theatre, sometimes yes. The pioneers of near full game demos, Interplay's Descent, ID's DOOM is still a good model for us. They followed the most important rule of showbiz (and applies to gaming), "leave them wanting more".
I've been reading all the suggestions and will be reviewing plans with the whole team at the end of the week.
With MTADS you can't see the join, no wait.
An alternative tack is to release a 'mini-game' using the current technology, such as an MTADS trainer which I can take a stab at guessing how that works. It's not hard to extrapolate a reasonable level of functionality from laughably Photoshoped press-images of the system (above).
Thank you
It's also been quite humbling to read the messages of support. The whole team have worked hard given such scarce resources. Imagine what might have happened with even a tenth of the money spent your typical AAA game wrap party (SONY blows huge amounts on those in London).
