Strategies for deliver_job(job)

[artur-freitas]

pensei em irmos conversando e elaborando primeiro a estratégia mais alto nível, para implementarmos após estarmos de acordo. Uma forma de montar estratégias para o deliver job seria a seguinte:

1ª condição (a ser verificada): alguém do time está segurando o item que conclui algum job (qualquer job, sem considerar que o time esteja tentando completar algum em específico). Isto pode acontecer porque foi feito assemble do item, ou porque surgiu um trabalho cujo item algum agente já tem em mãos. Sendo mais dummy, o agente que está segurando usa as estratégias de goto até o storage indicado pelo job e executa o deliver_job. Futuramente, pode ser incorporado uma estratégia para analisar:

• se entregando o item para outro agente a entrega é otimizada;

• se não vale a pena entregar a tarefa, mesmo tendo em mãos o item (exemplo: o item pode ser necessário para outra tarefa mais recompensadora)

  2ª condição: é possível recuperar o item para alguma tarefa de um storage (escolher o agente que possui energia e capacidade de carga suficientes), e então: usar goto até o storage, usar retrieve no item, e agora caimos na situação descrita pela condição 1.

3ª condição: é preciso construir o item.. eu acho que não deveria existir estratégias/planos nesta situação, para fazer deliver de algo que não existe. As outras estratégias deveriam se encarregar de criar os entregáveis, até cairmos nas condições 1 ou 2, sendo que a condição 2 leva a 1.

talvez possamos usar algum tipo de diagrama para organizar melhor as ideias..

[rafaelcaue]

Legal, ótima ideia Artur.

Pelo que entendi cada uma dessas condições vai ser um plano, onde a condição seria testada no contexto.

Sobre a primeira condição: Acho que é isso mesmo. No corpo desse plano podemos adicionar uma crença _jobDone(jobId,storageDestination)_, e chamar o _goto(storageDestination)_. O plano para o continue pode ser o mesmo que já discutimos, o goto já adicionaria a crença _going_, então vamos cair no continue corretamente. Vamos precisar outro plano para completar o job, a condição pode ser a crença _jobDone(jobId,StorageDestination)_ e _inFacility(StorageDestination)_, e no corpo a ação _deliver_job(jobId)_.

Sobre a segunda condição: Acho que não precisamos desse plano para os dummies, lembra que eles nunca vão executar a ação store. Esse plano seria útil para os dummies se executarmos o deliver_job parcial, e algum time completou antes de terminarmos, aí poderiamos utilizar esse plano para pegar o que estava no storage e utilizar para outro job.

Sobre terceira condição: Concordo, essa condição vai cair nas estratégias para o goto(shop) e goto(workshop).

Sobre o diagrama: Sim, criei um diagrama compartilhado, vou criar uma nova issue com o link para não misturarmos discussões (vou postar essa issue depois do almoço).

[ramonpereira]

Como complemento no código da motorcycle, adicionei um plano para depois de comprar todos o items (se não precisar montar nenhum item) entregar o job. O teste que eu fiz não monta nenhum item (até porque estamos testando com items base), ou seja, simplesmente entrega os items o qual o job solicitava. Fiz alguns testes e está OK.

[rafaelcaue]

Oi Ramon, testei aqui e está perfeito, só algumas coisas que mudei:

A ordem dos gotos, para seguir a prioridades que estabelecemos no grafo que está no google drive:

1) buy,charge,... 2) continue charge 3) goto charge 4) continue goto facility 5) goto shop 6) goto workshop 7) goto storage 8) skip

Removi o inFacility(Shop) do contexto do plano gotoworkshop e gotostorage, apesar de nesse caso funcionar, pode ser que futuramente o agente não esteja em um shop quando recebe os itens, ou quando constroi eles.