No multiple translators for the same class

[hmyeh]

It is currently not possible to have multiple translators for the same class, because the translate function retrieves the translator for a specific class from a hashmap. This means that there can only be one translator per class in the hashmap. For example: the indicator_Link percept #22 needs the stakeholder class #26 to translate from, but the stakeholder percept also needs this class. So there can only be one translator for both percepts.

[spiderbiggen]

You can override a percept and once you're done you can put it back see PR #28 EntityEventHandler.createBuildingPercepts

[MaxGroenenboom]

Can this issue be closed?

[NickTUD]

Well the solution from spiderbiggen was considered by multiple groups as 'dirty' so there is no real solution/template for the problem.

[MaxGroenenboom]

But not every percept requires a translator right? Translators are just for converting the internal data structure to a eis lang data structure, so it can be converted to Prolog for the agents?

[spiderbiggen]

Every percept requires it's own translator unless you want to use the same format as another percept, but then why would you create a new one.

[MaxGroenenboom]

I see it is indeed coded to use translators as percepts, but it is possible to create percepts in other ways... I suppose Wouter would not approve of those ways though, so we have to keep using this method. Thus I think this issue can be closed. It is still an issue, but it cannot be fixed and wouter doesn't look at these issues.

[Wouter1]

Indeed normally I do not follow these tickets but I was checking up if things are rolling here

If you need some change in master branch to proceed, you can contact the TAs after you agreed on how you want it.

Translators help you translate recurring elements in data structures so that you dont have to re-code the translation code each time. I would recommend that you keep using them

I suppose you want to extend existing translators. The simplest solution would be that you override EisEnv#installTranslators.

[Wouter1]

Did I understand right that you just want to override? Or do you have another reason to propose multiple translators?

[MaxGroenenboom]

@Wouter1 I think what we want to have is the ability to add percepts that don't link to any data structure. This is impossible in the current implementation of the connector. We have managed to add custom actions though, so adding custom percepts should be possible in roughly the same way.

[Wouter1]

You do not need to use the translators. EntityEventHandler collects Percept objects, not objects.

Basically, you do not need to call createPercepts, you can allso call addPercepts directly

[MaxGroenenboom]

I know, but we would need to implement a structured way of adding these custom percepts.

[Wouter1]

So there is no need for multiple translators after all?

[MaxGroenenboom]

Not for multiple translators I think, just for custom percepts. It would be impossible to translate a Data Type to multiple results anyways.

[MaxGroenenboom]

Do we still need this issue? If so I can create a framework for percepts similar to the actions framework. I think it is a bit late for those kinds of additions though.

[spiderbiggen]

I don't think we do

[MaxGroenenboom]

I hope this issue can be closed then. It's almost a month old now ^^