David posted up some more CH47 pics around SimHQ and Facebook and possibly elsewhere. Lot of detail work has gone into the engines, rotor head and trying to get the smoothing correct at the rear of the aircraft.

Looking forward to getting those blades turning, the sound thumping and the dust is flying.

I've been doing a lot of logic work in the Apache in the past day or so. Also full of a head cold which tends to make me cranky.

Sat in the cockpit, the APU sounds like a vacuum cleaner in the next room. Adding moving cockpit parts such as power levers, flashing lamp indicators and other one shot elements that require animation in a periodic update function suggests that maybe it would be better to place all of these things in something more general purpose.

Rather than having a spider-web of update calls, updateCockpit, updateUnitWaypoints, updateEventTrigger etc. popping a function onto a stack when it's needed seems like the thing to do.

I'm proposing to add a simple event system that can take an entity and perform a chain of moves, rotations, material or colour changes, and remove from the stack when the sequence is completed or removed. Then augment this to perform function calls for mission events, to be fired as offsets from mission start time or absolute world time.

Initial thoughts suggest something like the following would cover most needed cases:

• eventID = EntityID, action, blend, userdata (e.g material, colour, vector) as csv
• eventSequence = ID, eventID[], deltatime_ms, cycle_ms, repeat_count, start-time_ms (absolute world time or zero for mission start time)

Where a sequence to cycle a material between two states would need two eventID entries, one for each material and the entity to apply this to. And the eventSequence would contain the reference to both eventIDs. It's then up to the eventProcessor to handle the action. Which could also be SetKey() or SendMessage() but it should be generic enough to handle a lot of common situations.

Event is performed [repeat_count] times, a value of zero implies loop. [cycle_ms] is time between each repeat cycle in milliseconds.

Some checks may be required before injecting an even into the eventSequence. To prevent duplication, for example, hitting reload to trigger a reload animation repeatedly would have the effect of triggering the animation to play before the previous playback has ended. Therefore a parameter to test the uniqueness of the eventSequenceID before pushing it onto the stack should suffice.

**edit: some of this doesn't make sense, seems it got screwed up in posting. Text has been mistaken for tags.**

Source