Closed rafaelcaue closed 9 years ago
Isso.
Por exemplo, criei uma abstração das ações no common.asl da ação goto, que pode assumir dois tipos de parametros: o id da facility ou a posição x,y. Fiz assim pois acho mais fácil tratar no Jason, já que precisa englobar o parametro numa classe Identifier, com uma string "Location=" blablabla, várias voltinhas.
Mas vamos ver como será com as próximas ações, aí refatoramos qualquer coisa.
Resolvi seguir o caminho do @anibalsolon e continuar no Jason/AgentSpeak a descrição das ações comuns. Link para o common-actions.asl Notei que existem 3 variações (ignorando os valores default de algumas ações, que não sei como seria interessante usar):
No post_job existem N items com M quantias: item1=item_id1 amount1=10 item2=item_id2 amount2=5 ...
, o que torna difícil postar tarefas. Por enquanto fiz a ação esperar um paramêtro Items
já nesse formato. Acredito que suportando esses detalhes seria o suficiente.
Observação: ainda não testei as ações, apenas descrevi as mesmas me baseando no manual.
Muito bom! Acredito ser o bastante para começarmos a arquitetar estratégias.
Acho que para essa tripa de items e amounts dava para usar literais e algo que serialize para esse formato. Tipo _postjob( ..., [item(10, 12.13), ...]). Mas não acho que valha o empenho agora, pois nem sei postaremos algum job (só se for para bagunçar o reasoning do inimigo hehehe).
Btw, ficamos de ver se os jobs tem identificador de quem lançou ele. Até onde lembro não, right? Podemos guardar os IDs dos jobs iniciais (do sistema) e os novos IDs serão dos inimigos, dunno. Just wondering.
Acho que para essa tripa de items e amounts dava para usar literais e algo que serialize para esse formato. Tipo post_job( ..., [item(10, 12.13), ...]). Mas não acho que valha o empenho agora, pois nem sei postaremos algum job (só se for para bagunçar o reasoning do inimigo hehehe).
Ou para terceirizar certos materiais que precisamos para outros jobs.
Btw, ficamos de ver se os jobs tem identificador de quem lançou ele. Até onde lembro não, right? Podemos guardar os IDs dos jobs iniciais (do sistema) e os novos IDs serão dos inimigos, dunno. Just wondering.
Não, a princípio não tem como identificar quem postou o job. Os jobs só devem entrar na base de crença dos agentes quando chegar no firstStepActive (no caso de priced) e firstStepAuction (no caso de auctions), o que significa que no início da execução não temos essa informação. Nós sabemos quando os 3 jobs vão entrar nessa simulação, mas na competição provavelmente vai mudar ou ser aleatório. Portanto acho que não tem como adivinhar quem postou o job.
Acho que não vale a pena encontrar uma solução melhor para o post_job
agora, mas concordo que tem espaço para melhorar. Ainda sobre os jobs, eu acredito que se postarmos algum job nós teríamos que salvar o ID deste para não pegarmos o próprio (forçar outro time a pegar).
Sobre o continue não funcionar (código do servidor eismassim):
Sacanagem, agora só falta descobrirmospq o jason n eata conseguindo enviar uma açao por step.
A princípio podemos utilizar o skip no lugar do continue, mas quem conseguir arrumar o continue posta aqui,
Eu vi que o código dessa screenshot é da classe EnvironmentInterface no eismassim-2.2.jar. Ela é instanciada na classe Entity. Está me parecendo que eles esqueceram de atualizar essa classe (envinterface), mas ela não deveria ser específica do cenário de qualquer maneira. Qual classe que chama o isSupportedByEntity? Não consegui encontrar aqui.
Anibal vamos enviar aquele e-mail para a lista, tenta mais uma vez se não conseguir posta aqui que eu envio.
E-mail enviado, assumo que todos já estejam inscritos na lista de e-mail então vão receber a resposta automaticamente.
Fechando a issue.
Durante a última reunião (03/06), achamos que teria que fazer a tradução manual de cada ação do Jason para o EIS, porém pelo que vi no translator.java esse processo é automático e generalizado, portanto o continue que estavamos tentando deveria funcionar.
As ações que precisam de parametros é realizado uma manipulação de strings no common.asl, podemos padronizar e deixar todas la, até as que não utilizam parametros.
Eu vou testar o continue e depois posto o que eu descobrir aqui. Quem for testar as outras ações, criem um novo issue informando isso, para que não aconteça trabalho dobrado.