Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move field parsing to Observer #27

Open
Florisheinen1 opened this issue Jan 4, 2023 · 3 comments
Open

Move field parsing to Observer #27

Florisheinen1 opened this issue Jan 4, 2023 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@Florisheinen1
Copy link
Member

Is your feature request related to a problem? Please describe.
We receive a proto object from vision/simulator that describes the field. We convert it to our own Field type which is easier to use. But what if our received object contains missing information? And what if the received data is inconsistent? Filtering needs to be applied to ensure we use correct Field information, but that is not done at the moment.

Describe the solution you'd like
I suggest moving the conversion from the AI code to Observer code, as this is exactly why Observer exists. After that, Observer can apply filtering to make sure we have a proper representation of the Field.

Additional context
I suggest waiting until this PR is merged so having a reference of a Field is a bit more simple.

To send the filtered Field from Observer to AI, a new proto object that matches our way of describing a Field is probably very convenient, so I also suggest doing that. (I would be very willing to fix that part!)

@Florisheinen1 Florisheinen1 added the enhancement New feature or request label Jan 4, 2023
@rolfvdhulst
Copy link
Contributor

@Florisheinen1 Maybe a few points of discussion before I would start fixing this:
What to do in case we have not yet received a field from vision? There's basically 2 options:

  1. Use a 'default field' with sensible sizes (e.g. the default division A sizes for example)
  2. Do not pass a field at all/pass a null field.

I don't have a particularly strong opinion for either as I don't know enough about the AI, but I can imagine that in some situations having a field available is crucial. It also reduces the (mental) overhead of having to check if the field is present every time.

@rolfvdhulst
Copy link
Contributor

@Florisheinen1 Your opinion on this? You can also maybe make a PR drafting the field proto type already if you feel like doing so.

@JAndringa
Copy link
Member

In my opinion we should use the last known field or pass a null field if nothing has been sent yet. Checking whether the field is present should be done anyway as not having a field does impact our winning chances. Also we would only have to check one time per game, since we can assume that the field will not change during the game.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants