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
-- ROE fine tuned.
-- Detection events cross firing and exploding...
-- Crash, Ejected, PilotDead is detected, makes the FSM stop.
-- FSM bug fixed. There was an issue with the onbefore and onleave
events returning false, which did not stop the transition! Fixed now.
-- Event calling can return errors, and these must be logged correctly
-> xpcall implemented.
-- Added help from moose club members as a reference in the
documentation. -> delta99 en whisper.
-- ...
So, when the Scheduler that is passed to the AddScheduler is nillified,
the internal arrays that keep the Scheduler reference are also
nillified. And it does what i need for further utilization in MOOSE
classes. When the Scheduler is nillified, but, a schedule was planned
for that Scheduler, once the scheduler fires off, it will ignore that
call... cool.
Sven
Reworked the hierarchical state machine processing in terms of sub
processing.
Now, the declaration and usage of subs is completely understandable and
easy to implement.
I am excited to see how end-users will see the possibilities.
