Complete sending and reporting for SingleRandomAgent

[ssardina]

This is the main objective. SingleRandomAgent should serve as a model:

1. Connect to server
2. Sense the environment and act
3. Assimilate all data into Java structures, but now re-use the EI classes
4. Report all data every cyle
5. Go to some random destination

[ssardina]

Hi @ayoung012

I think we have a healthy system now. I have done refactoring of names, always with simplification in mind. Also lots of clean-up in internal documentation.

What we need is to printout at every cycle ALL the information and fill whatever is missing, including the player info as you stated in #17

Can you take care of that?

I need to stop for a bit now, but my next step will be to factor out all event production.

[ayoung012]

I will work toward this. Although I expect I will have many questions. For example, are items important enough to extract out into a data structure in the aggregator? Or is simply reaching for them via a specific job or shop when required sufficient?

[ayoung012]

items need to be pulled out of the percept. the only way to get their weight is via the item term.

[ssardina]

We cannot do that? I would say that the MW can be set to either record in the aggregator or not record (e.g., if we use Prolog in our applicatin, so we don't want all the overhead). But if we record, we record everything.

[ayoung012]

@ssardina see 226d361 for a decent first go at making the updating/processing of perceived entity data a generic process. It got a little more complicated than I would like, so very much a work in progress. I may well go back to switch statements if I cannot make this at least look a bit simpler.

[ssardina]

mmm OK my thinking at this point is that while it is really fancy, it is as you suggested too complex for what is needed. As far as I can see there are two nice additions:

1. We check if everything we expect has been sensed.
2. We keep a track of what has changed what has not.

Both are nice things to record in the MW. But seems to me updateEntityBasic is so much simpler and readable, and no need to know advanced Java techniques, like Field.

Can't we enhance updateEntityBasic to accommodate 1 and 2? I think we should be able. I do like 1 and 2 features.

[ssardina]

BTW, please always pull bc I sometimes do improvements here and there. I decouple the sensing cycle in the agent template so acting is done in its own "event' hander.

But I noticed that the reporting gives error anyways, there must be something that is not working in the updates of the data?

[INFO, 9:10:15pm, AGENT-5fd56487-4bd1-4e04-80aa-998269259b07] **Single-RANDOM-Agent**: FINISHED SENSING THE ENVIRONMENT FOR ALL THE PLAYER CONNECTIONS. NEXT REPORT AND ACT FOR STEP 0!!!
[WARNING] 
java.lang.NullPointerException
    at au.edu.rmit.agtgrp.agtcity.sarl.mw.aggregator.CityAgentEntityManager.reportState (CityAgentEntityManager.java:364)
    at au.edu.rmit.agtgrp.agtcity.sarl.mw.skills.S_MassimTalking.MT_reportEntityState (S_MassimTalking.java:359)
    at au.edu.rmit.agtgrp.agtci

[ayoung012]

@ssardina yes. I agree that it is too complex. We will have to use the switch method instead. You have discovered that didn't get it working 100%, but that is ok, as most of this will go...

My only slight annoyance with the switch is that we will have to handle new feature 2: tracking changed data per attribute. ie each switch statement will be 4 times bigger: from:

case "lat": {
    entity.lat = Util.extractDouble(p.parameters.get(0))
}

to:

case "lat": {
    val lat = Util.extractDouble(p.parameters.get(0))
    if (lat != entity.lat) {
        entity.lat = lat
        attr_changed.add("lat")
    }
}

Not so nice anymore... Thoughts?

[ayoung012]

Take two: 0cf26b3 . Back to switch statements. Very verbose, very little ability to do generic processing of attributes. Probably for the best.

Entity percepts still to process: hasItem, role, team etc.

[ssardina]

Yes I understand what you mean. Much more verbose and repetitive, what can we do... I think nonetheless is more readable and each case is separate and clear, which helps here with so many different types.

Also, note this tracking of updated or not may be "luxury". In the end, we will aim to do data management with Prolog or something as managing all these data structures in Java is painful.

Now, I want to understand something Adam that I think you know well:

1. is is true that every entity will sense the SAME info every cycle on facilities and jobs? Or could it not be so?
2. is is true that there is never "missing' info? That is, can it be that a precept is missing some facility info? Is the sensing robust?

I am not talking here about specific entity data or info that depends on visibility.

In particular, your printout suggest that somehow you are not receiving the percepts that you were expecting:

WARNING: The entity attributes received from the server are different to what was expected.
We expected:
charge
chargeMax
facility
items
lastAction
lastActionParams
lastActionResult
lat
load
loadMax
lon
name
role
route
routeLength
skill
speed
team
vision
Server percept only has:
charge
facility
lastAction
lastActionParams
lastActionResult
lat
load
lon
name
role
route
routeLength
skill
speed
team
vision

[ssardina]

@ayoung012 , I forgot or never understood: what does the ^ in a variable name, like ^skill mean?

[ayoung012]

@ssardina I like this progression for entity. I think tracking of updates for entity is important for the middleware to support, and even though the switch statement is getting bloated, it is a necessary evil to support identifying changes to the entity, as it is when we care most about. Issue #9 should implement layer 3: defined as emitting events when changes are detected in EntityData.

The attributes I have reported as still missing are attributes of EntityData, and I think we should fill EntityData completely.

The attributes missing are:

• chargeMax - must be retrieved from role
• items - must be retrieved from hasItem percept(s)
• loadMax - must be retreived from role

I think these are achievable and I will aim to track updates for all EntityData attributes by tonight.

Now to address your two questions:

1. No, facilities are not necessarily the same every step. They may have changing attributes (shop stock, etc) over time. The tracking of these changes is indeed a 'luxury' and feasibility is to be discussed in a new issue, tagged below this comment.
2. Every entity will sense the same jobs and facilities, with the exception of wells and resourceNodes, which are affected by visibility. In this sense, wells and resourceNodes are not 'robust', alongside entities (visibility per agent) and jobs (exiration). It is the job of the aggregator to seamlessly combine this in the case where the mw skill is managing multiple agents.

^ is the SARL convention for escaping reserved keywords like agent and skill. We cannot use another variable name because skill is the name used in EntityData.

[ssardina]

Fantastic answer @ayoung012, thanks!

I think I was not clear in my question 1. I meant that every entity get, in each cycle, the SAME info about facilities and jobs. Which you answered in 2.

My second questions was whether there could be "noise" or gaps in a percept. This is because you printout that you were expecting something but you did not get it.

Excellent plan, if you complete the missing bits in EntityData we are very close to get a first final MW that can be used in JAS.

Great about ^, makes sense, I have added it to my SARL FAQ.

[ayoung012]

A nice formatted table is generated with the current entity state every step. It's looking pretty good.

[ssardina]

I saw it, very nice!

Now, shouldn't we have .toString() methods attached to each data class also?

I am finding it hard to find bugs in the getDifference

[ayoung012]

toString methods sound good to me. Go for it!

On Sat, 16 May 2020, 8:43 pm Sebastian Sardina, notifications@github.com wrote:

I saw it, very nice!

Now, shouldn't we have .toString() methods attached to each data class also?

I am finding it hard to find bugs in the getDifference

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ssardina-agts/agtcity-sarl-mw/issues/12#issuecomment-629626089, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYTLJBFH2PAVLZKBND2DDRRZU63ANCNFSM4MYM4KNA .

[ssardina]

THey are done and our MW updated to use that, please pull.

Now, I am a bit confused how we go forward. For sure we want SingleRandomAgent to report EVERYTHING it is tracking. I let you do that, you have almost done the whole thing for the entities we control. I guess you will then print out the facilities we know and jobs right?

I am doing the difference between states. I have done the entities. Will do facilities next

[ssardina]

Hey @ayoung012 . Sorry marking test 2 consumed me all these days.

Where are we here with the MW and the "template' agent?

This issue was about printing everything after we update so we are sure we are recording everything. Remember you now have .toString() in the protocol classes, so we just print what that function says.

We then have issue #23 to check differences between two states. I will cut down its extent and have a basic templtae which is almost there, but as you said, if somethody wants to do more, they can do it.

[ayoung012]

The entire state is now reported every step, subject to implementation of toString in the last three JobData classes mentioned in https://github.com/ssardina-agts/agtcity-server/issues/11