►
From YouTube: Open Match TSC Dec 2019
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Release
date
sounds
great
mid-january
and
then
six
weeks
later
is
the
end
of
February.
That's
just
in
front
of
GDC.
You
know
that's
a
dot
ten.
Ideally
we
can
figure
out
if
that's
about
10
or
100
I
feel
like
that's
the
one.
Oh
release
might
be
the
one
dot,
oh
yeah,
especially
if
we
get
the
scale
cuz.
That
is
when
we
want
to
yeah
yeah.
We.
A
B
C
Yep
I
think
the
one
question
I
had
I
checked
with
ish
as
well
and
I.
Don't
think
he
cares
as
much.
But
a
part
of
me
is:
are
you
from
a
legal,
contractual
blah
blah
blah
perspective?
Do
you
have
to
have
a
one-goal
before
your
folks
o
live
on
it
like
google
word
in
future,
but
like
is
that,
is
that
something
like
I
checked
with
ish
I?
Don't
think
he
cared,
but
it
is
it
you
know.
Do
you
need
a
one-off
or.
A
C
A
E
C
I
kind
of
the
reason
asked
is
a
goodness
heart.
I
mean
I
think
if
he
saw
wasn't
goodness
if
I
track
that
hard,
something
like
Google
has
probably
more
stringent
requirements
there
right
like
we're
before
we
declared
alpha
for
Game,
Servers
and
goodness
had
to
be
100
was
like
the
requirement,
but
anyway
he.
A
Is
also
it's
like
part
of
your
yeah
yeah
hosting,
probably
you
can
make
the
underlying
components,
your
mantra
and
therefore
the
amount
of
those
components
need
to
have
the
same
visibility.
Is
it
clear
you
know
and
for
our
for
our
specific
meeting
of
us
coming
and
that's
it
it's
a
footnote
that
the
whole
thing
is
even
running
this
way
right.
Most
people
don't
yeah
are
interested
so.
B
B
A
B
B
Like
what
the
types
of
function,
your
methods
calls
on
the
front
end
are
because
they're
all
dealing
with
like
singleton,
gets
our
small
groups
tickets
and
then
having
the
backend
be
purely
for
matches
and
analogic
be
querying
purely
for
querying
and
then
renamed
things
so
that
back
in
his
match,
API
front-end
this
ticket,
API
and
logic,
is
created.
Yeah
and
I
go
into
more
a
bunch
more
here,
but
I
don't
know
how
much
we
want
to
do
that.
First,
just
talk
about
it.
A
Let's
say
you
had
identity.
Let's
say
you
had
yeah
like
like
JWT
identities,
stuck
on
the
front
door
on
the
ticket
taking
api,
it
makes
sense
to
validate
the
caller,
is
a
player
or
a
service
that
is
like
wrapping
this
stuff
right.
You
know
I,
guess
in
that
context,
maybe
it's
less
of
a
big
deal,
but
the
director
having
an
identity
that
matches
with
the
match,
API
or
game
server
identity
right
you
just
have
to
you-
have
to
I
act,
errs
now
on
the
front
door
that
you
didn't
have
before
you
want
to
commit.
A
Way
is
the
components
that
were
talking
to
them.
Yeah
the
back
end
was
the
backend.
The
front
end
was
the
front
end.
So
if
you
were
coming
in
the
front
door,
you're
the
front
end,
if
you,
if
you
might
grow
service,
if
I
this
I
mean
yes,
the
correct
thing
is
basically
that
in
a
micro
services
world
things
understand
that
the
caller's
are
from
various
walks
of
their
they're
acting
lives
right,
so
I'm
trying
to
think
if
this
has
any
major
effect
that
I
mean
as
a
rapper
of
all
this
stuff.
A
A
Point,
though
authorizing
assigned
tickets
is
especially
hard.
It's
easy
to
authorize
ticket
because
I
either
created
the
ticket
or
I
my
identity
matches
the
ticket
or
identity
matches.
Some
piece
of
information
in
the
ticket
right
as
assign
tickets
is
like
you
need
be
coming
from
the
right
now
claim
somehow
to
say,
like
you're
allowed
to
do
this
where's
in
the
back
bird,
you
can
basically
be
like
everything
needs
to
have
that
claim
and
on
the
front
end
we
authorized
tickets.
I
might
have
to
solve
it
unilaterally.
So
it's
not
a
big
deal.
Yeah
I!
B
D
C
Need
a
front
end
before
the
open
match
front
end,
but
for
their
scale
and
for
their
requirements
they
just
don't
cave.
They
have
the
player
directly
talk
to
the
open.
My
front
end
I'm,
now
putting
a
sign
tickets
on
there
just
makes
their
solution
a
whole
lot,
but
only
assign
tickets
there
take
their
solution
better.
Oh
no,
it
doesn't
make
my
dough
better.
B
C
C
If
we
aren't
making
the
move,
I
think
back-end
and
front-end
staying
back
in
the
front
end
is
okay,
because
those
kind
of
then
indicate
the
components
or
the
actors
that
are
talking
to
them.
I
mean
that
was
kind
of
the
original.
Yes
I'm.
Okay,
with
that
I
mean
it's
not
like
I
have.
If
we
aren't
moving
the
sign
tickets,
then
I
think
it's.
What
else
can
you
do?
I.
B
A
A
Whereas
I
think
that,
if
you
were
to
look
at
this
from
how
you
would
see
them
in
production,
I
would
imagine
there
being
like
each
ticket
api's
three
query:
a
api's
and
two
reliable
match
api's.
The
reason
for
that
is
because
the
ticket
API
is
actually
the
front-end
scaling
component.
That
is
the
runtime
critical
piece
to
you,
know,
players
getting
into
consideration
sure
and
that's
where
I
think
things
are
more
comfortable
in
the
front-end
space,
because
when
you,
when
you
read
it
and
you
read
it
in
the
environment,
it's
like
it's
very
clean.
A
A
A
A
D
A
Is
there
building
on
what
are
they
saying?
Is
there
anything
because
it
makes
sense
today,
mmm-hmm?
Let's
say
we
have
moved
a
sign.
Take
it
like.
Let's
just
pretend
like
some
of
the
everything's
collection
oriented,
is
there
any
API
that
we
imagined
shipping
around
like
stats
or
config
that
suddenly
don't
fit
the
point
you
know
if
I
want
to
manage
index?
Is
there
an
index
API?
Let's
say
everything
isn't
just
kubernetes
configured.
If
it
is
it
changes
things
but
right
in
doing
it.
I
imagine
get
stats
from
the
query.
Api
yeah
probably
makes
sense.
A
A
A
C
It
again
totally
depends
on
what
we
are.
So
that's.
Why
I
think
it's
just
not
renaming
its
its?
What
exactly
do
those
mean
and
I
think
that's
kind
of
what
you
did
to
it?
Some
point:
it's
like
how
do
they
scale?
What
do
they
mean?
So
are
they?
The
the
suggestions
on
the
right
are
all
making
them
very
specific
collections,
but
I
think
that
has
concerns
around.
C
So
in
the
example
that
you're
mentioning.
Let's
speak
of
function
right
now,
I
think
oh
yeah,
the
scaling
characteristics
of
something
that
needs
to
register
a
function
or
like
essentially
be
a
control
plane
for
functions.
It's
very
different
from
both
the
think,
yeah
sure
and
the
actors
would
talk
to
it
may
also
be
will
be
very
different
because
at
that
point
the
the
entity
interacting
with
that
would
ideally
be
your
DevOps
or
not
so
much
your
director
director
isn't
gonna
register
or
that's
what
a
runtime.
B
B
We
had
a
good
point
about
the
security
bit,
but
on
the
other
flip
side
here
when
I
was
looking
at
like,
why
do
we
have
these
services
like
separate
binaries
that
are
running
and
stuff?
Just
like
one
big
deployment
and
service
I
mean?
Maybe
we
should
be
going
that
way,
but
it
seems
that
the
back
end
or
match
API
is
doing.
B
Long
loads,
like
a
map,
type
stuff,
where,
like
there's
a
lot
of
data
flowing
through
it
so
like
it,
shouldn't,
be
handling
all
their
stuff.
I
mean
like
you,
don't
want
to
bog
it
down
with.
You
know:
trading
tickets
because
it's
gonna
be
doing
like
this
bulk
processing
of
calling
out
to
mesh
functions
and
those
streaming
them
back
to
the
synchronizer
and
then
streams
and
not
to
the
director
and
the
ticket
API
has
or
the
the
front-end
currently
and
then
assignments.
B
C
B
A
A
C
C
A
Services
with
back
in
databases,
you
got
three
services
talking
to
the
same
database
right,
there's
reasons
not
to
do
that
at
the
same
time.
No,
it's
ok!
It
doesn't
bother
me
necessarily,
but
I
now
understand
more
about
why
it's
called
query.
I.
Think
query:
query:
query!
Api
query
server!
Whatever
you
want
to
add
the
suffix
that
one
seems
phenomenal.
Okay,
that's
one
yeah
for
sure
back
in
versus
front
end,
yeah,
yeah
I!
Don't
really
have
a
model
for
helping.
If
you
have
a
strong.
C
Opinion
about
it
actually
from
the
discussion,
I
think
I'm
leaning
towards
just
keeping
it
back
in
way.
It
is
just
because
I
think
both
the
the
identity
of
the
actors,
as
well
as
the
scaling
characteristics
make
I
mean
there
are
two
separate
things
that
the
name
and
the
stuff
that's
on
it
like
moving
the
assign
here,
I
think
from
the
latter
it.
C
A
C
That
might
that
might
be
another
interesting
one.
If,
because
today
we
have
like
oh
we're
all
on
on
like
we,
we
basically
have
to
anyways
enforce
that
when
it's
like
it's
either
all
on
and
informally,
but
anyways,
but
yeah
I,
think
I,
I,
plus
one
on
that
I
think
mm
logic
to
query
service
for
sure,
I
think
the
front-end
or
back-end
print,
front-end
and
back-end
I.
Don't
think
we
have
enough
evidence
to
make
that
change,
so
we
can
possibly
keep
it
like
that
unless
in
10
timeframe
we
think
of
strong
reasons
to
change
it.
C
C
Yes,
100%
because
I
think
that
that
one's
so
naturally
weird
that
I,
even
when
I,
was
making
this
smock
for
presentations
and
whatnot
for
the
five-minute
talk.
Now,
what
does
it
mm
watch?
It
yeah
like
I'm,
replacing
your
door
I'm
like
putting
it
in
the
bracket
mm
logic
with
query
or
data
API,
and
it's
like
yeah
that
that
clearly
means
it
should
change.
But,
okay,
we.
A
A
We
have
three
things:
we
assign
tickets,
that's
the
last
one
that
we,
because
we
accidentally
ended
up
mocking
the
entire
interface.
We
now
need
to
break
that
down
to
match
this,
so
yeah
assign
tickets
will
be
its
own
thing
for
the
back
end.
If
that
were
called
something
else,
it
would
still
be
fine
if
the
assign
tickets
API
rakaats,
we
also
be
fine,
I
mean
that's.
C
That
yeah
well
Saturday
by
the
way,
the
way
I
think
the
Redis
connection
works.
Is
we
have
an
internal
state
store
a
company
that
each
of
these
Lord
and
eventually
in
future,
like
let's
assume
we
have
to
change
stuff,
then
we
can
go
one
of
two
ways
right,
which
is
either
happen.
The
data
API
be
the
central
place,
or
at
least
have
that
as
a
service,
then,
where
that
becomes
like.
Essentially,
if
you
just
want
to
replace
right,
is
it
changes?
Don't
bleed
through
every
component?
C
C
B
A
A
Right,
like
maybe
maybe
you
swap
I,
actually
have
it,
have
an
issue
that
we
just
hit
yesterday.
That's
not
in
here.
Someone
had
to
talk
to
you
guys
about
it
real
fast,
then
we'll
add
it.
Okay,
if
I
do
a
delete
ticket
in
between
a
sign
ticket
being
called
like
if
I
call
a
sign
ticket
on
ticket
that
doesn't
exist
anymore.
What
happens
you
think
if.
B
B
A
A
We
cool
and
then
I
I'm
like
I,
actually
don't
to
matchmake,
so
I
delete
my
ticket.
The
director
will
come
back
long
and
say:
assign
tickets.
Here's
my
signer
information,
here's
my
ticket
ids!
What
our
system
does
is
it
does
a
hash
right
to
effectively
like
the
ticket
now
exists
again
sure
it
just
has
an
assignments
but
like
it
actually
creates
like
a
lot
of
exceptions
for
something
that
we
do
I
don't
want.
You
guys
had
that
problem.
Also
I.
C
B
C
A
I
think
we're
we're,
incidentally,
by
way
of
not
doing
too
much
on
the
optimized
side
mm-hm
and
we
actually
like
did
a
bunch
of
serialization
optimizations
around
when
we
read
and
write
do
transactions,
so
I
think
we're
gonna
be
close,
but
yeah.
We
can
certainly
go
in
and
try
to
help
on
the
database
side,
especially
exciting.
We,
incidentally,
as
part
of
having
our
own
implementation
like
created
some
our
own
problems
there
right.
But
actually,
if
you
did.
A
E
B
E
A
A
Lengthy
traits
multi
do
okay,
so
you
guys
have
Authority
is
possibly
a
couple:
multis,
okay,
but
that's
serious
in
some
places,
a
weird
amount
of
stress,
overhead
and
others.
So,
okay,
we
don't
know
how
to
profile
this
stuff.
So
we
might,
we
might
get
back
on
the
slack
threads
and
the
dev
channels
and
maybe
start
profiling
when
we
get
to
that
point,
maybe
we
can
get
a
shared
batch
maker
stood
up
or
something
question.
How.
C
Do
you
what
should
be
the
recommended
assignment
flow
story
like
why
we're
thinking
of
an
assignment
should
what's
because
right
now,
I
think
the
problem
is
streaming.
Assignments
is
not
a
great
idea,
so,
let's
drop
that
front
end
should
call
get
in
a
loop
which
is
okay,
except
do
we
really
think
that's
how
it
should
be.
A
A
C
Not
even
talking
about
the
sphere
like
the
game,
connection
to
the
player,
okay,
what
I'm
saying
is
there?
Is
you
have
your
grim
game
front
end,
which
is
at
this
point?
The
gate
assignment
is
being
done
from
your
game
front
enemies.
You
mean
not
from
the
player
right
in
the
open
match.
Yes,
make
sense.
C
What
I'm
saying
is
your
director
is
doing
the
assignment
Achatz
back
in
we're
using
open
match
as
a
channel
to
just
pass
that
assignment
through
yeah
we
are
directed
or
potentially
just
talk
to
your
game
front
end
and
be
like
by
the
way.
Yeah
here
is
the
assignment
for
this
jacket
minute
yeah.
There
should
be.
We
just
remove.
C
B
C
On
the
collar
then
to
delete
it
ticket
once
they
have
communicated,
be
right
assigned
right,
I
mean
at
that
point
of
the
matches.
I
mean
just
hypothetically,
but
at
that
point
of
the
match
is
like
everything
that
means
a
match
gets
in
here
sure
we
get
out
matches
from
the
back
end,
and
once
you
know
you
have
a
match,
just
delete
the
thing
that
was
waiting
like.
Why
have
this
easy.
B
A
By
my
hesitation
is
I
feel
like
we
actually
need
a
like
a
substantial
solution.
If
we
want
to
cuz
right
now
of
a
match
is
very
similar
to
a
database.
You
know
you
write
things
in
and
then
you
you
schedule
like
a
query.
That's
gonna
result
in
things
being
updated
on
tables
right,
and
so
to
that
degree,
it's
very
approachable.
A
This
way,
if
you
turn
it
into
a
pipeline
delegator
right,
which
is
more
like
the
I
footwork
in
the
front
and
I'm
gonna
hook
up
a
listener
on
the
backend
and
I'm
gonna
get
them
will
listen
for
changes.
I
think
you
have
to.
You
have
to
take
an
approach
to
the
listener.
I'm,
not
sure
an
ecosystem.
I
agree.
We
could
start
as
an
ecosystem
thing
and
then
maybe
it
graduates
and
we
delete
this
code
in
order
to
have
the
other
code.
I
mean
mildly.
Like.
C
That's
a
good
approach.
My
only
concern
would
be
and
again
I
think
the
scale
tests
would
educator
decision
here
is.
This
is
the
only
place
page
weren't
actually
actually
updating
the
database
again
right.
If,
if
sign
wasn't
present,
then
it's
all
just
create
a
ticket
and
where
the
query
query,
query:
query:
that's
it!
No!
No!
No!
You
would
need
to
resolve
the
ticket
yeah.
B
A
A
A
B
C
They
want
not
that
I
actually
had
another
tanker.
I
made
a
note
the
other
day
to
myself
core
discusses.
So
it's
good.
The
the
whole
alpha
testing
that
we've
kind
of
discussed
in
past
right,
where
it's
like
sure
you
have
a
match
function,
but
now
you
also
want
to
run
tests.
Another
match
function
to
see
what
output
gets
generated
by
it
and
but
but
you
really
don't
want
those
matches
like
to
to
be
real
matches.
I
mean
there
are
two
ways
you
could
do
it
and
your
match
function
itself
could
do
the
necessary.
C
So
that
says,
you
may
have
a
fake
function
which
not
make
function,
but
you,
you
have
a
function
that
you
don't
want
to
generate
the
real
matches
with,
but
you're
just
testing
this
out
in
production.
So
one
way
you
do,
it
is
send
request
for
that
function,
but
that
function
doesn't
actually
return
any
proposals
back
to
open
match
at
all.
It
does
whatever
it
needs
to
do
to
your
logging
system.
The
other
approach
is
early
third
party,
yes,
and
the
other
approach
is
open.
C
Match
provides
you
with
so
this
whole
awaiting
assignment
bit
open
match,
essentially
lets
your
fetch
matches
say
that
this
is
by
the
way,
don't
mark
this
as
a
reading
assignment
at
all.
So
at
that
point
it's
almost
like
that
function
would
participate
in
the
same
cycle.
It
would
generate
matches
part
your
evaluator
can
choose
to
just
ignore.
Well,
why?
Not,
because
you
know
you're
not
gonna,
be
I.
B
B
C
No
I
think
that's
a
separate
scenario,
though
right
I
mean
having
a
snapshot
up
for
data
and
feeding
it
into
a
non
production.
Environment
is
great.
What
I'm
curious
is
what
do
you
ever
want
to
support
the
case
of
it's
not
a
test
code
in
production?
Let's
say
your
function
is
ready
ready,
but
before
you
flip
the
bit,
do
you
want
it
to
essentially
be
like,
however,
on
this
see
what
might
just
get
generated
but
I'm
not
confident?
It
also
drop
the
results
and
I
think
from
open
match
code
perspective.
C
A
Sure,
third
party
approach:
we
don't
care;
okay,
yes,
the
worst
party
approach,
hey
like
first
party,
is
in
its
or
second
party,
let's
say
second
party:
it's
not
explicitly
like
a
scenario
that
we're
supporting,
but
because
we've
added
a
an
API
for
putting
the
ticket
back
into
the
pool.
The
director
could
technically
like
him.
A
A
Based
off
of
yeah,
it's
going
to
build
a
secondary
list
right
like
a
a
B
list,
so
the
a
list
is
the
real
list,
and
the
B
list
is
like
a
second
run
of
the
whole
thing,
but
doesn't
solidify
the
results
right
and
so
like.
How
does
the
the
director
say?
Hey
run
this,
but
also
my
evaluator.
This
is
a
category
stage
run
or
category
read,
run
or
something
like
that,
and
it
still
gets
results
back.
I
mean
they
think.
A
D
A
B
But
so
it's
you
could
console
the
evaluator
twice
one
with
all
the
matches
you
actually
care
about
and
one
but
your
care
about,
and
your
test
matches
and
but
like
I,
don't
I'm
not
seeing
the
like
strong
use
of.
Why
do
you
need
to
do
this
in
production?
This
kind
of
scary
thing
in
production
versus
yeah
well,.
A
Wouldn't
you
much
rather
have
that
layered
interior
thing
with
production
is
I've
I've
rewritten
to
match
function,
right,
I've
tested
it
on
a
replay,
but
now
I'm
gonna
do
a
rolling,
update,
zero
downtime
deployment
and
now
it's
just
live
and
it
either
is
or
isn't
doing
the
thing
I
thought
it
was
gonna
do
and
you
almost
want
a
totally
separate
stream
for
and
that's
not
gonna
affect
production.
But
arguably
well
you
could
imagine
this
being
similar
yeah.
A
Me
just
end:
there's
a
couple
of
things:
it's
a
different
than
I
do
buddy.
I
five
tickets
come
in.
Yes,
only
thing
can't
see
me
ready.
I'm,
tell
me
where
to
line
them
tickets
going
into
a
front
door
and
then
go
into
a
database.
Oh
man
database.
You
can
I've
got
a
bunch
of
functions
up
here
that
are
doing
query
reason.
Let's
just
say
some
more
than
others,
then
I
have
a
back-end
and
then
I
have
this
big
thing
called
an
evaluator.
A
This
is
the
thing
that
schedules
those
three
it's
back
results,
and
it
eventually
sends
a
big
chunk
of
these
into
the
evaluator
in
the
evaluator.
We
have
one
synchronizing
context:
yes,
there's
one
of
them
yep,
and
so,
even
if
you
have
a
concept
that
I
understand
as
being
part
issues,
I
don't
get
them
yes,
and
so
you
know
partitions
could
possibly
mean
multiple
synchronizers
sure.
So
you
can
also
have
categories
of
the
results
that
I
would
like
to
run.
Different
I,
don't
know.
A
Basically,
what
I'm
trying
to
say
is
there
might
be
a
first
party
understanding
of
like
the
contracts
of
the
evaluator
for
the
purposes
of
possibly
unlike
functions
where
we
then
ship
a
harness,
might
make
sense
to
have
more
information
that
we're
understanding
from
an
open
match
perspective
that
actually
gives
people
value.
This
is
an
X
cubed,
anything
more
than
that
restricts
the
game
logic
from
and
performance
this.
A
C
A
A
Okay,
ideally
were
able
to
put
match
functions
in
that
we
would
know
their
evaluation
score
sure,
but
then
wouldn't
necessarily
mint
the
results
and
also
wouldn't
affect
tickets
being
pulled
out
of
the
pool
only
to
be
put
back
in
the
pool
yeah.
Does
that
make
sense?
The
goal
is
for
our
evaluator
to
actually
see
how
that
function
compares
sure,
and
so
we
can't
use
the
evaluator
or
the
evaluator
affects
performance,
because
it
actually
changes
the
state
of
the
pool.
That's
unfortunate.
So.
C
A
C
It's
probably
not
so,
let's
assume
you
have
one
is
your
production
match
function?
One
is
a
test
match
function
and
both
of
these
are
the
same
pool
in
the
same
cycle
generate
the
same
set
of
results
comes
in
here.
You
have
something
in
your
extension
mark
which
your
value
door
now
understands.
By
the
way
this
match
was
generated
by
a
test
match
function
just
to
be
ignored,
it
does
its
own.
A
B
I
think
they're
do
little
on
solution.
If
you
have
live
replay,
you
don't
need
any
of
this
anyways,
because
if
you,
if
you
still
want
to
do
but
you
but
I,
want
to
do
a
rollout
test,
you
can
do
a
rollout
test
on
a
test
environment
with
the
library
play
sure
so.
You're
you're
still
not
actually
affecting
production
and
you're,
not
risking
touching
production
and
blowing
up
production.
I.
Think.
C
A
So
the
replay
is
critically
important
for
big
customers
who
are
training
their
match
function,
algorithms,
yeah,
absolutely
when
they
go
to
roll
it
out.
The
big
thing
they
want
is
they
want
the
ability
to
do
a
mix
so
they'll
deploy
it
get
it
live.
It's
no
tip
no
traffic,
then
they'll
send
10%
of
the
traffic
to
it
and
they'll
send
100
percent
of
the
traffic
to
it
and
let
it
scale-up
all
right
so
that
that
type
of
mix
that
rolling
update
you
need
something
like
that
supported
anyways.
C
A
You
can
do
it
at
a
community
level.
I
think
we
have
everything
we
need
with
the
exception.
I
think
we
could
get
the
ticket
replay
stuff
from
open
match,
specifically
like
over
match
could
have
the
log
of
the
tickets,
and
maybe
even
the
queries
or
even
whatever
was
executed.
That
would
get
you
90%
of
a
replay
right.
A
A
B
Why
I
think
you
should
just
go
with
a
she's
hot
yeah?
Well,
this
one
I,
don't
know
he
have
opinions
but
we're
thinking
of
reducing
down
to
one
your
PC,
an
HTTP
port,
because
we
have
a
whole
bunch,
of
course,
for
a
bunch
of
different
things,
and
we
don't
need
them.
We
could
just
have
one
court
for
each
endpoint,
okay,
theoretically,
you
can
put
them
on
the
same
port,
but
I
feel
like
that's,
so
the
liveness
will
also
be
on
the
HTTP
port.
A
B
Like
the
thing
we
kind
of
want
to
do
with
this,
though,
is
like,
instead
of
having
to
like
look
up
the
port
numbers
for
the
front
on
the
back
end.
Whatever
have
you
you
just
have.
The
port
numbers
like
the
like
is
just
one
sec
port
so
that
all
of
the
configuration
about
like
what
ports
are
open
on
the
open
that
services
and
all
that
all
likes
implies
down
to
this
is
a
GRB,
see,
parentheses
yeah
great
may
be
alive
in
this
port
and
the
metrics
part
to
okay,
something
like
I,
see
yeah
that
one.
A
Of
the
status
and
has
a
code
of
okay,
yeah
I
mean
I
in
general,
we
actually
have
quite
a
bit
of
problem
with
status
in
general.
It's
not
it's
not
robust
enough
to
do
air
handling
around
things,
like
validation,
where
I've
got
lots
of
errors
and
lots
of
messages
to
provide
the
user.
It
currently
has
a
string
in
a
code
and
the
code
isn't
defined
right.
There's
no
detail
links
it's
it's!
It's
a
pretty
thin
status
concept.
B
A
B
Yeah
good
bill,
Jeremy,
CSS,
better
yeah,
so
yeah
the
point
mean:
let's
put
the
oak:
let's.
If
they
don't
put
a
status
on
here,
which
you'd
probably
put
a
sentence
of
okay,
then
we
should
call
status
because
otherwise,
like
there's
some
like
weird
behavior
of
like,
if
a
client's
checking
that
I
don't
have,
an
error
must
like
and
they
are
the
mess.
Their
field
is
not
set,
but
it
is
set
with
the
status
of
okay,
like
what
is
the
like,
your
game,
your
interaction
there
true.
B
C
The
current
proposal
is
just
to
rename
the
error
the
status
yes,
which
yeah
I
think
what
you're
hinting
do
is
like.
Assuming
this,
the
status
field
stays
status,
I
think
that
proposal
totally
makes
sense
now,
whether
that
field
itself,
it's
is,
is
that
what
you
are
questioning
as
my
question,
a
tight
and
general
yeah.
A
D
A
Which
I
think
look
like
status,
so
we
made
the
status,
and
now
it
inherits
all
of
the
type
I
language
us
of
status,
which
it
is
not
yeah.
It's
not
a
request.
It's
an
assignments,
sure
right.
It's
not
a
request
concept.
It's
not
a
Google
RPC
status,
not
really
it's
really
some
type
of
assignment
status,
yeah,
okay,
we're
assigned
into
error;
and
so
yes,
proposal
to
rename
status.
C
We
one
dadÃs
type
is
odd.
I
have
a
feeling
like
I
vaguely
remember
at
some
point.
Jeremy
was
like
this
because
it
was
named
status
and
was
a
string
and
then
the
thing
was
like:
hey
I
mean
or
it
was
named
error
and
was
a
string
and
I
wouldn't
really
be
a
string,
so
he
had
replaced
that.
But
I
I
see
what
he's
saying
in
the
original
proposal.
This
was
just
a
string
being
returned.
I.
Think.
A
It
was
just
a
string
at
the
time
that
was
back
when
we
were
also
doing
J
object,
yeah
errors,
so
we're
doing
JSON
errors
right
now.
It's
like
we
I
think
we
can
agree,
there's
a
common
way
to
do
an
assignment
error
that,
like
exposes
enough
fields
for
a
developer
and
open
match
to
say,
link
a
code,
a
string
or
possibly
an
array
of
coda,
Street
I,
think
coach
bring,
is
probably
substantial
coach
string,
any
probably
also
is
fine.
A
B
I,
don't
the
thing
about
having
a
code,
that's
not
like
I
guess,
but
the
can
also
be
a
nanny
yeah,
the
any
on
a
string
I
just
like
that
yeah,
the
problem
with
making
it
like
an
int
or
a
string.
Is
that
suddenly
you
have
say
you
have
two
different
systems
that
can
set
an
error
on
an
assignment
right.
It
can
be
your
director
or
it
could
be
your
allocator,
for
example,
there's
some
BS
some
combination
systems
that
can
give
back
inside
an
error
on
an
assignment
yeah.
So.
B
You
might
want
to
be
able
to
like
have
it
flow
through
so
like
now,
I
guess
the
point
being
that
if
you
now,
you
have
to
reconcile
like
what
error
codes
or
like
if
I'm,
looking
at
strings,
you're,
saying
I've
ever
in
the
sound
before
it's
not
pretty
of
like
I,
have
two
different
things
that
can
put
our
messages
on
I
have
to
write
code,
to
figure
out
which
one
set
the
error
message
and
then
interpret
the
error
message.
I
mean
at
the
end
of
the
day,
the
edge
unit.
A
B
C
A
A
Are
BC
seven,
it's
not
an
RPC
object.
I
guess
it
is.
But
this
is
this
is
where
G
RPC
in
the
way
we
do
things
always
confuse
this
make
them
the
data
models.
Are
the
contract
models
they're?
Also
the
things
we
write
into
the
register
base
I
got
it
I
sort
of
don't
know.
I
need
guidance
on.
It
is
the
idea
that,
like
every
time,
we're
gonna
do
something
that
has
the
word
err
on
it.
We
should
be
instead
doing
a
status
that
has
an
internist
ring
in
the
details.
A
B
The
idea
here
is
that
we
are
streaming
entire
objects
from
the
back
ends
to
the
synchronizer
to
the
evaluator
and
all
three
of
those
know
the
whole
object,
but
we're
streaming
the
whole
object
back.
Anyways
do
we
want
to
just
say
you
returned
the
match
ID
and
the
back.
The
evaluator
will
return
that
to
the
correct
back
end.
B
A
Think
I
would
say
that
the
the
objects,
the
proposals
that
you
pass
to,
if
we
wanted
to
say
the
evaluator
can't
mutate
the
master,
it's
fine,
but
then
we
need
a
field
that
can
be
returned
along
with
the
match,
ID.
That
is
like
the
evaluator
results
or
metadata
that
the
evaluator
noticed
about
a
match.
So.
A
Meant
your
take
two
matches:
we,
we
don't
mutate
them.
We've
heard
of
people
who
want
to
mutate
them.
I
mean
I'm,
not
really
keen
yeah.
They
want
to
do
things
like
balance
the
teams.
At
that
point,
we've
kind
of
told
them.
That's
not
really.
It's
not
really
a
useful
computational
model.
Sure
you
should
do
that
ahead
of
time.
A
B
I
think
it
definitely
feels
like
it
should
be
in
them
yeah
yeah
for
sure
five
every
bit
there.
There
is
one
use
case
where
I'm
kind
of
like
maybe
evaluator
needs
to
be
mutating
stuff,
which
is
so
you
have
a
battle
royale
game.
You
have
100
players
from
this
match
hundred
players
in
this
message
returned
by
different
MMS
and
they
share
one
player
right,
like
the
correct
thing
to
do,
is
probably
just
evaluate
a
need
to
be
pretty
smart
right.
C
C
A
A
A
Everything
you
know
you
this,
the
evaluator
is
gonna
say
why
it
became
a
match
over
another
one
or
why
didn't
become
a
match,
might
be
interesting
right
and
you
could
say:
yeah
I,
let
this
you're
hosting
the
evaluator
like
offload
that
but
the
same
time
like
say
I,
think
we're
knocking
on
a
metadata
object
limit
for
actor.
The
director
allows
the
director
to
calculate
stats
without
needing
a
stat
system.
Why.
C
B
A
B
B
D
C
Want
to
revisit
is
yes,
this
one
and
today
I
think
this
is
more
of
a
correctness
thing
today.
So
today
what
happens
is
the
way
the
synchronizer
is
written.
It
uses
the
match
ids,
so
it
sends
a
whole
bunch
of
matches
to
the
evaluator
gets
stuff
back
and
then
the
stuff
that's
returned
like
for
the
evaluate,
let
me
put
it
this
way.
The
synchronizer
has
a
map
of
like
okay,
I've
called
the
evaluator
with
all
of
these
match
IDs,
but
there
was
a
fetch
match
request
that
each
of
these
belong
to
right.
So.
C
You
have
to,
there
is
one
request:
another
two
requests,
parallely,
the
basing
visor
today
work
says
request.
One
has
much
ID
one,
two,
three
four
five
and
request
to
has
six
seven,
eight,
nine
ten
club,
all
the
one
to
ten
give
it
to
the
evaluator.
No
evaluator
returns
like
four
five,
seven,
nine
other
results.
We
need
to
now
say:
oh
by
the
way
for
fetch
matches,
one
your
results
are
four
and
five
and
fetch
watch
it
now.
What
happens?
The
problem
is,
we
know
we're
in
force
that
match.
Ids
are
unique.
A
C
C
B
So
I
think
there's
I
had
a
person
two
things
up
like
we
should
like
define
the
correct,
behavior
and
like
force
the
users
to
do
it,
which
is
either
you
can't
set
the
match
ID
and
we
set
it
for
you.
So
we
know
it's
gonna
be
unique
or
we
require
you
to
set
an
ID
and
which
we
find
out
that
it's
not
unique.
B
B
A
C
C
C
C
Anyway,
I
think,
let's
keep
it
simple,
have
a
name,
an
ID.
We
give
you
a
chance
for
correlation
by
C.
You
specify
the
name
coming
in
into
the
match.
Yeah
we
set
the
ID,
which
is
a
UID,
so
you
are
evaluate
it
a
knows
both
it
can
correlate,
but
basically
we
allow
you
to
set
a
name
and
we
set
an
ID
I.
Think
that's
a
fairly
standard
part.
So.
A
I
really
like
the
name
concept,
because
I
think
we
actually
have
a
pretty
like
I
think
most
people
have
like
don't
want
to
name
these
and
they'll
be
like
yeah
like
this
is
my
simple
one.
You
know
some
people
will
choose
to
use
the
function
name
with
a
number.
Some
people
choose
to
use
whatever
mode
they're
supporting
with
the
number
and.
C
Practically
today,
even
higher
debug
stuff,
I,
actually
use
loves
from
the
match.
Name
dump
in
the
match
function,
log
for
what
the
director
sees
out
right.
So
my
name
is
the
only
thing
which
actually
will
exist
both
places
because
ID
will
be
set
only
after
the
match
gets
into
the
open
window.
So
I
think
name.
B
F
C
F
C
B
A
B
C
But
that's
what
I'm
saying
so:
I
think
that
that
comes
back
to
the
module
for
GCP
right,
like
think
about
it
like,
if,
in
an
ideal
world
I
almost
feel
like
your
correlation,
is
your
name.
You
can
set
it
to
unique,
and
the
ID
is
only
for
the
purposes
of
correctness.
We
need
to
have
a
unique
identifier
for
each
name
and
that's
why
we
internally
set
with
an
ID
the.
C
B
Profile
match
function
on
a
match
which
I
don't
think
of
meshes
today,
but
it
probably
should
because
we
know
yeah
yeah,
so
we
should.
We
should
be
doing
this
for
you
and
you
shouldn't
be
setting
it.
The
match
profile
in
the
match.
Id
know
the
mat
the
mat
function
of
the
match
profile.
Well,
this
event,
I.
A
B
C
A
Function:
okay,
let's:
let's
understand
how
to
fill
everything
and
if
Deena
they
were
like,
even
after
racking,
our
brains,
we
don't
understand
where
this
comes
from.
Then
we
figure
out
if
it's
promotable
to
the
in
contractor,
if
it's
useful
for
life
or
person
integrating
of
it
to
set
it
because
in
if
it
is
like
it
becomes
correlation
information.
Because
right
now,
it's
not
clear
to
me
how
I
correlate
the
evaluator
the
match
function
in
the
director,
oh
yeah,
which
we
we
suffer
from
this
in
our
system,
because
the
match
function
logs
are
just
like.
D
C
I
think
think
about
it.
There
is
the
actual
fetch
might
just
call.
Each
fetch
match
is
called,
has
a
context
ID
at
the
synchronizer
assigned
to
it
before
that
call
was
made
so
that
that's
a
correlational
actually
is
common
for
the
matches
generated
by
a
match
function
run,
but
we
want
to
like
kind
of
short
the
I.
Don't
know
what
I'm
saying
is.
That
is
there's
a
blob
of
information
here
which
is
like
hey.
What
match
profile?
Was
this
much
more?
C
B
B
C
A
You
need
any
lineage
that
is
like
director
created
should
be
optional,
I
think
yeah,
it's
the
the
main
takeaways
like.
If
there's
a
name,
that's
gonna,
be
flowed
through.
It
comes
in
with
a
profile
and
when
it
gets
the
match,
lineage,
it's
just
a
profile
metadata
name
that
gets
tacked
on
right
now.
I
think
we
actually
do
something
really
gross
or
we
actually
copy
the
profile
into
every
match.
Object
returned
at
the
backdoor
because
we
ended
up
using
that
for
storing
session
information,
but
like
the
director
could
totally
just
do
that.
A
If
we
actually
have
the
correlation
the
problems
right
now,
we
do
a
run
and
we
get
back
a
list
of
matches
and,
like
we've
lost
our
context,
that's
actually
useful
for
doing
things
like
we
put
in
the
session
to
do
back.
Folks,
we
have
the
initial
query
information,
so
Batman
I
was
just
reflecting
on
this
whole
project
the
other
day.
It's
come
a
long
ways:
yeah
yeah.
C
A
We're
gonna
we're
gonna,
do
the
due
diligence
on
each
and
get
us
souped
up.
I
had
already
done
this
couple
months
ago
and
dot
six
and
Starly
went
it
just
like
did
it
for
eighth,
so
we
still
have
to
take
into
that
he's
regretting
how
much
he
said
you
got
done
already,
but
yeah.
The
both
of
us
just
this
sprint
have
just
a
bunch
integration,
stuff,
so
I'm,
hoping
that
we
can
start
start,
but
I
have
a
feeling.