-- Fixed in spawn.lua
-- InitRandomizeTemplate is now correctly positioning the spawned units
according the initial position as modeled in the mission editor.
-- When combining InitRandomizeTemplate with InitRandomizeZone, the
spawned units are still positioned at their initial position according
the position modeled in the mission editor.
-- Added test missions SPA-019 and SPA-020.
The problems were in the EVENTDISPATCHER.
-- Reworked the Event Dispatcher code...
-- Added fields IniCategory and TgtCategory that indicate which Object
Category is involved in the Event.
-- Added fields IniPlayerName and TgtPlayerName that indicate which
Player Name is the initiator or Target (only when the Object Category is
a UNIT).
-- In the Event.lua, I poperly documented every field in EVENTDATA and
typed it correctly.
-- Reworked te Scoring code..
-- Incorporated the Event.* added fields into the Scoring Code.
-- Added a SCO-100 test mission
-- A shooting range with STATIC objects, so that a player can TEST the
scoring for STATIC objects in a mission.
Hope this helps.
FC
-- Added separate detection loop during engagement
-- Detection during patrolling is off.
-- Engage now has several parameters that specify how to engage within
the zone.
-- Created several additional test missions, more to come.
-- Fixed AI_CAP_ZONE: Groups not engaging when an engage was "aborted",
but was actually erroneously set to "Accomplished". Is fixed now. An
engage that cannot be accomplished (due to no unit in the Engage Zone,
will be Aborted). Groups are engaging now when an Engage Zone is set.
-- Fixed FSM: There was a big issue with delayed function scheduling.
When creating "loops", meaning an Event handler calles again itself
delayed, would start propagating multiple times when the event was
scheduled, and another schedule of the event would be planned.... Thus 2
to x events handled and would end in chaos. Implemented delayed event
scheduling accepting a *negative* parameter in seconds, which would
check if an event would be already scheduled. If so, no new event would
be scheduled until the event handler would have been processed. In this
way, only maximum one event can be scheduled when this is wanted (this
is not always the case by the mission designer). So providing a negative
value as the seconds would make the event being scheduled only once!
-- Added EventPriority field in EVENT logging
-- Removed logging from POSITIONABLE
-- Moved the start of the detection to the Start event handler in
AI_CAP_ZONE
-- Removed the sort
-- Implemented the order in the existing table.
-- 5 levels
-- _DATABASE = 1
-- SET and SET_ derived classes = 2
-- UNIT = 3
-- GROUP = 4
-- all other = 5
