search

StephenGss / PAL

Polycraft World AI Lab
3 stars 6 forks source link

[HUGA] Enemies might move between SENSE_ALL and the SAIL-ON agent's action #56

Closed jhostetler closed 2 years ago

jhostetler commented 2 years ago

This is possibly just a manifestation of #55, or it might be a separate issue. In the attached log, on line 18911, the SAIL-ON agent is facing left and there is a gray patrol (Y) to its right. The SAIL-ON agent executes a "move forward" action (line 18961), but it doesn't actually move, and in the next frame, the gray patrol is in front of it and has apparently blocked the move (line 18987). This is reported as a novelty (line 18965) because the move command was expected to succeed HUGA_L00_T01_S01_X0100_A_U9999_V0-entity-moves-before-agent.log .

StephenGss commented 2 years ago

It looks like there might have been a delay for the actor move intended to happen after your agent's action on lines 18533 and 18896. Is there a delay implemented between receiving a command response and sending a sense_all command? I can't tell from your log what the exact timestamps are when the commands were received and sent. I would be able to see this from the PAL log if you can supply that.

If there isn't a delay, I think adding one for 200ms would be enough to resolve this issue.

jhostetler commented 2 years ago

If I understand right, you're saying that the SENSE_ALL result is being sent before the Move action has finished "happening" in the environment, and if we wait between the Move and the SENSE_ALL it might fix it?

We can try this, but it seems like an unreliable solution. What you're implying is that there is a race condition in the simulation. Ideally the simulator would not return a result until it's in a stable state.

(Incidentally, we also have some workarounds in our code for when the MacGuffin doesn't register as picked up or dropped immediately; could this be the same issue?)

EricKildebeck commented 2 years ago

My understanding is that this is very similar to the MacGuffin issue we ran into in Phase 1. These race condition are something that in the current iteration happen in the base Minecraft communication between the server and client. We continue to look into paths to change that, but it is fundamentally different than the other bugs that result from our additional Polycraft code and we can fix easily.

The agents movement is a similar, albeit more complex, instance of the MacGuffin issue. The workarounds for the MacGuffin may be a good solution if the 200ms delay is not suitable.