Replies: 1 comment 12 replies
-
Not sure what the core problem is -- a ground action is one that combines the lifted action (identifiable by name) and the object parameters. I think a step makes sense still as a tuple of state / ground-action. The objects don't really relate to the state (at least not directly). Is the issue that an action object is uniquely defined ( |
Beta Was this translation helpful? Give feedback.
12 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In manually constructing traces, I noticed an issue similar the the fluent-value one with
Action.obj_params
.The
Action
constructor takes a name and a list ofCustomObjects
which the action acts on. By storing this on theAction
itself, it isn't clear which object it actually acted in that step because the list either holds all the objects it could act on, or is overwritten each time the action occurs.Multiple actions with the same name ("pick up" acting on A, "pick up" acting on B) could be used but as with the fluents that doesn't seem right.
This one doesn't affect model extraction, but makes it difficult to print action information.
As it is, can't determine which block was actually "picked up" from within the
Action
's__str__
method unless multiple "pick up" actions exist:Output of printing the trace list:
I think the solution would be to store action parameters in
Step
,ie
Action(name)
andStep(state, action, objs)
instead of
Action(name, objs)
andStep(state, action)
as it is now.But seeing as this doesn't pose a problem to model acquisition, maybe it is better to leave it and just leave out
obj_params
in theAction
string?Beta Was this translation helpful? Give feedback.
All reactions