theRAPTLab / gsgo

GEM-STEP Foundation repo migrated from GitLab June 2023
1 stars 1 forks source link

Control Cursors, not direct agent control #197

Open benloh opened 3 years ago

benloh commented 3 years ago

In order for input controllers (e.g. charcontrol, ptrack, or pozyx) to switch control from one agent to another, input controllers need to be treated as cursors.

Technical Design

Current data flow:

graph TD
    I[script.instances] --> G[SCRIPT_TO_INSTANCE]
    G --> H[agent]

    A[pozyx] --> B[POZYX_TO_COBJ]
    B --> C[COBJ_TO_INPUTDEF]
    C --> D[INPUTDEF_TO_AGENT]
    D --> H

In order to support cursors, we need to introduce a new coupling.

graph TD
    I[script.instances] --> G[SCRIPT_TO_INSTANCE]
    G --> H[agent]

    A[pozyx] --> B[POZYX_TO_COBJ]
    B --> C[COBJ_TO_INPUTDEF]
    C --> D[INPUTDEF_TO_AGENT]
    D --> H

    J[GEMSCRIPT] --> K[SCRIPT_TO_INSTANCE]
    K --> L[agent.uninhabited]

    M[pozyx] --> N[POZYX_TO_COBJ]
    N --> O[COBJ_TO_INPUTDEF]
    O --> P[INPUTDEF_TO_AGENT]
    P --> Q[agent.cursor]

    Q --> R[agent.inhabited]
    L --> R

How would we define this?

  1. Blueprint parameter?

    {
    id: 'Moth',
    isInhabitable: true,
    isCharControllable: true,  // invalid and ignored?  This might be OK so long as charControl also has cursor
    isPozyxControllable: true, // invalid and ignored?  This would conflict with pozyx cursor.
    ...
    }
    • These agents by default would not be AI-controlled, nor would CharControl or Pozyx automatically map to them.
    • They appear as ghosts? Transparent agents? But how do you differentiate uninhabited from inert/dead? Full opacity grayscale? That means black and white sprites shouldn't be used?
    • Use isPuppet instead of isInhabitable? NO! puppet is input control of agent. e.g. a cursor would be a puppet.
  2. CharControl If CharControl sees a 'isInhabitable' type of Blueprint, then it needs to provide a 'cursor' agent selector?

  3. Pozyx If Pozyx sees a 'isInhabitable' type of Blueprint, then it automatically creates cursor agents? This means that all Pozyx inputs would be mapped to a cursor? So you can't automatically map some Pozyx to a specific agent type and others to a cursor? This is probably a good thing as it keeps the system simpler?

  4. Picking Up If a cursor center goes over an uninhabited agent center, then the uninhabited agent attaches itself to the cursor. Do we use Movement to do this testing? Does this mean Cursor agents always useMovement? And any blueprints that are inhabitable useMovement?

  5. Dropping If the cursor agent drops out, what happens to the inhabited agent? Does it eventually mark itself uninhabited?

    • If the dropout is detected, we can explicitly uninhabit the agent.
    • If the dropout is undetected, agents can have an update timeout -- if no position updates are received for 15 seconds, it marks itself uninhabited?
  6. Instance Definition Should we allow predefined pozyx ids to be mapped to specific instances? e.g. in an instance script:

    {
      id: 1301,
      name: 'Predator1',
      blueprint: 'Predator',
      initScript: `mapToPozyx ft-pozyx7119`
    },

How are Cursor agents defined?

Do we hardcode GEMSCRIPT definition of the cursor agents? Or do we use a js class?

dc-inputs

benloh commented 3 years ago

changed time estimate to 80h

benloh commented 3 years ago

Spend design 6/16 1h Spend production 6/16-6/167 7h

benloh commented 3 years ago

added 8h of time spent

benloh commented 3 years ago

marked the checklist item An inert/inactive agent releases the cursor as completed

benloh commented 3 years ago

marked the checklist item Cursors can pick up and inhabit an agent as completed

benloh commented 3 years ago

marked the checklist item Map inputs to cursors as completed

benloh commented 3 years ago

marked the checklist item Display cursor (target graphic?) as completed

benloh commented 3 years ago

See !111 for implementation.

benloh commented 3 years ago

Spend 0.25h jitter issue 6/22

benloh commented 3 years ago

added 15m of time spent