Closed ayoung012 closed 4 years ago
Should resolve issues #12, #17 and #22
Perfect, we are going well with this. I have added a reportState(entity)
in the agent to report the whole state.
We'll merge this PR once that is full and reports the whole state. We can then move that in some shape to .toString()
in PerceptAggregator
Also note I improved the server and allow to set the log OFF so that XML packages are not printed. I am getting tired of so much XML.
One question: we are doing he checks for what has changed when updating, in each switch. An alternative would be to provide a method getChanges(PerceptAggregator, PerfceptAggegator)
and let the user decide if she wants to keep previous and new aggregator and call the changes with that? Do you understand what I mean?
Ah! Amazing, the XML is so annoying. The state reporting will now actually be visible... I will work on this.
Your question: this getChanges() method you propose, I don't understand how this would be any different to the aggregator.updateAggregatedGameState()
currently used in the agent sense loop.
Yes XML was bothering for a long time. We can always start the skill setting EI log to True and XML will be printed
What I mean is that SARL agent may track 2 aggregators: aggregator-prev
and aggregator
.
Agent first does aggregator-prev = aggregator
to store current aggregator, then senses and builds a fresh aggregator
.
Then, if the agent wants, you call static aggregator.updates(aggregator-prev, aggregator)
and a mapping will be given with things that are different.
By doing that we separate the logic of update vs recognize changes, and we make all that effort optional, can be done by the agent when the agent wants, or never. Makes sense?
Is there any Map
method that extracts differences? something like .equals()
?
Actually Google Guava has it: Map.difference
We are already using Guava, SARL uses it so it is in the Maven repo
BTW, we should change "aggregator
" to state
!
@ayoung012 please pull, have refactored aggregator into "State". Much nicer and AI-ish.. ;-)
Building a state each step is a nice idea. It gives transparency to the agent that in fact we do recreate the state each step. We could also leave change analysis and creating triggers/events etc in response to changes as an exercise for the user! Brilliant!
Now guavas difference
method.. did this just solve all our problems?
I am doing a first cut of difference.
You just take care of completing the reporting so we report 100% of the state and we find any bug in our updates. OK?
should we merge this?
I'm happy to merge. Version bump?
mmm look how job data is printed, is this correct?
ShopData{restock=3, stocks=[StockData{name='item0', price=82, amount=9}, StockData{name='item1', price=42, amount=17}, StockData{name='item2', price=114, amount=13}, StockData{name='item3', price=37, amount=14}], name='shop0', lat=48.84222, lon=2.26791}
ItemData{name='item0', volume=7, parts=null, roles=null}
ItemData{name='item2', volume=7, parts=null, roles=null}
ItemData{name='item1', volume=10, parts=null, roles=null}
ItemData{name='item8', volume=8, parts=[motorcycle, truck], roles=[item5, item7]}
ItemData{name='item7', volume=8, parts=[drone, car], roles=[item0, item5, item4]}
ItemData{name='item4', volume=6, parts=[motorcycle, car], roles=[item2, item3, item0, item1]}
ItemData{name='item3', volume=5, parts=null, roles=null}
ItemData{name='item6', volume=8, parts=[motorcycle, truck], roles=[item2, item3, item0, item5, item1, item4]}
ItemData{name='item5', volume=8, parts=[drone, car], roles=[item2, item3, item0, item1]}
massim.protocol.scenario.city.data.JobData@383083a8
massim.protocol.scenario.city.data.JobData@2b5ea2d
massim.protocol.scenario.city.data.JobData@55fdbabb
massim.protocol.scenario.city.data.JobData@2c1a2ed0
massim.protocol.scenario.city.data.JobData@c959d89
massim.protocol.scenario.city.data.JobData@215ceab4
massim.protocol.scenario.city.data.AuctionJobData@194cb446
massim.protocol.scenario.city.data.JobData@645d6511
massim.protocol.scenario.city.data.JobData@4404d5c6
massim.protocol.scenario.city.data.JobData@24b8eb8
massim.protocol.scenario.city.data.JobData@7e59f433
massim.protocol.scenario.city.data.JobData@71236304
massim.protocol.scenario.city.data.JobData@136b2203
massim.protocol.scenario.city.data.AuctionJobData@4c0c0a0f
massim.protocol.scenario.city.data.AuctionJobData@47e8878f
massim.protocol.scenario.city.data.JobData@4d8b4098
[INFO, 11:00:07pm, Single-RANDOM-Agent] I will ask player **entityA1** to to buy item0
Could it be that JobData
is missing a toString()
You are spot on, see https://github.com/ssardina-agts/agtcity-server/issues/11
@ssardina server PR https://github.com/ssardina-agts/agtcity-server/pull/14 should be merged, then MW needs to be updated with final eismassim version.
@ssardina merge when you are ready
The final push for an acceptable layer 2 data aggregator. I have not checked actual values yet, but I am confident all data is at least being updated with something.
Fixes #12 Fixes #17