Scheduled Pending Tasks in 3.6

[bevans2000]

Recently the simulation has come to rely more on the Pending Task concept.

Scheduled Task Implementation

The ScheduleManager is essentially duplicating the existing ScheduledEventManager. The latter is a more efficient implementation with UnitTests and support in the Console to display events. It is also already integrated into the Settlement.timePassing method.
The current implementation relies on Settlement.setAppoinmentTasks to create future pending tasks every sol. It would be better to have the concept of a Rota that is scheduled when there is a change of Shift. So when a Shift comes online; the future Tasks would be scheduled as part of the Shift rollover. The Rota creation would be just focussed on those that have come on Shift.
This would be more useful as it could be expanded to cover other Tasks.

However this has to be careful that it does not overlap with the shared SettlementTask backlog which works very well.
Both of the above can be done as part of a redesign in 3.7.

Sleeping on Shift

Currently Persons are forced to Sleep on shift before undertaking an EVA activity. Do we really want people sleeping when they are on a shift?

Ignoring Important Tasks

Whilst the above is easy to fix as part of 3.7 there is consequence of more pending tasks. Currently the TaskManager starts the next pending task without evaluating the potential other Tasks. This will cause a problem if there is a higher importance tasks. For example if there is a pending task available but a Class 1 Malfunction the repair tasks will be ignored. In most scenarios this would be OK because other Persons would pick up the Task BUT if there are not many people in a Settlement it could be ignored.

It suggests that the Task Manager needs to compare the next Pending Task to the potential options before progressing. Pending Tasks should not be done blindly; they need to be started in the context of what else needs to be done.

Potentially Pending Tasks should have a score such that a high scoring Task would still take precedence.

@mokun

[mokun]

Yea ScheduledEventManager is better by design.

Please go ahead and add more features to ScheduledEventManager.

Currently Persons are forced to Sleep on shift before undertaking an EVA activity. Do we really want people sleeping when they are on a shift?

Good point.

Can we create a special shift called EVA Shift ?

Say we dedicate 20% (or a player adjustable) of settlers to do EVA. They'll be required more or less to sleep enough prior to EVA.

But this requirement can be relaxed by gauging the individual fatigue and energy level prior to sleep.

Potentially Pending Tasks should have a score such that a high scoring Task would still take precedence.

That makes sense.

Repair tasks should take precedence. I haven't considered that till now.

Do make those changes as you see fit.

[mokun]

So does ScheduledEventManager execute a task via SettlementTask and backlog ?

Also, my number one mortal enemy has been the horrible assignTask method in AbstractMission and I have wanted to get rid of.

So far, OperateVehicle, NegotiateTrade and a lot of Walk tasks still rely on assignTask.

Pending Tasks would have been considered the less evil. :D

In the last couple of mars-sim versions, I've made assignTask less intrusive and less damaging by adding more prerequisites prior to running it.

Since it uses the raw instantiation constructor (e.g. new DigLocalRegolith(...)) as a param, it's a big waste to create the task first and only later to find out it would be terminated when a person is outside and is not supposed to be the best condition to start another EVA task.

Any plans to get rid of all 'assignTask` ?

[mokun]

I just found out all these classes below make use of assignTask

5 of your new mission class needs it.

Practically all of the old mission class requires assignTask.

What's the best way we can replace them with ?

[bevans2000]

But the point is a Task has to be assigned to a Person when they are under the control of a Mission. The fact they are calling one of the Mission executePhase methods means they have no Task. I think for a Mission using assignTask is correct. what's the problem with it.

[bevans2000]

I will create an Issue for 3.7

[mokun]

The fact they are calling one of the Mission executePhase methods means they have no Task.

To my knowledge, assignTask is run whether a person (ideally assigned to a mission) is performing a task or not.

But having said that, we can some changes to exclude anyone who are already having a task. Do we want to do so ?

Internally, assignTask calls checkReplaceTask and they will prematurely end a task in order to perform a new task.

One idea I struggle in the past is,

should we allow any settlers/robots to come help load vehicle cargoes ?

Also should anyone be recruited to help unload vehicle cargoes when they arrive home ?

[bevans2000]

I don't understand why we need these changes so can't really comment on what is needed because I don't know the problem they are trying to solve. Changes to how Tasks are started previously has been difficult and needed lots of thought and testing, so I guess you have identified a problem that's not obvious

[mokun]

My purpose has been no other than refining the pending task method in order to queue a task decently without undesirable side-effects.

When assignTask is run, the current task instantly gets replaced with a new task.

No mercy spared. The current task got cut shorted of getting finished.

So what I'd like to do is to refine how a pending task is queued or use whatever better mechanism that you can think of. That's all.

But we can deal with that later.