| 1 |
(new post to break wall of text and respond to something else)
|
1 |
(new post to break wall of text and respond to something else)
|
| 2 |
\n
|
2 |
\n
|
| 3 |
[quote]These issues may be specifically addressed with some very creative solutions but almost everything that happens in the engine fires up some lua event and if these will run in parallel all hell will break loose[/quote]
|
3 |
[quote]These issues may be specifically addressed with some very creative solutions but almost everything that happens in the engine fires up some lua event and if these will run in parallel all hell will break loose[/quote]
|
| 4 |
\n
|
4 |
\n
|
| 5 |
Are there lua things that need to interact back with the engine (while also affecting [i]relevant[/i] stuff) before the next lua callin should happen? Otherwise, collecting and then sequentially processing them may allow that part to be done. I'd imagine such situations would exist, but I can't think of one in ZK right now...
|
5 |
Are there lua things that need to interact back with the engine (while also affecting [i]relevant[/i] stuff) before the next lua callin should happen? Otherwise, collecting and then sequentially processing them may allow that part to be done. I'd imagine such situations would exist, but I can't think of one in ZK right now...
|
| 6 |
\n
|
6 |
\n
|
| 7 |
[quote]If they die in parallel, their ids may get switched leading to desync.[/quote]
|
7 |
[quote]If they die in parallel, their ids may get switched leading to desync.[/quote]
|
| 8 |
So
basically,
all
dependence
on
sequentiality
of
events
would
need
to
be
removed.
I'd
imagine
this
to
be
possible
by
making
both
the
RNG
and
the
distribution
of
IDs
be
decided
by,
say,
a
hash
of
relevant
arguments
(
unit
id/health/location/reload
timer/target
id
etc.
)
and
the
game
frame.
I
get
that
hashing
a
bunch
of
garbage
every
time
you
want
to
assign
a
unit
ID
is
a
lot
more
time-consuming
than
incrementing
a
counter,
but
I'm
not
under
impression
that
unit
creation
is
a
major
bottleneck
right
now.
|
8 |
So
basically,
all
dependence
on
sequentiality
of
events
would
need
to
be
removed.
I'd
imagine
this
to
be
possible
by
making
both
the
RNG
and
the
distribution
of
IDs
be
decided
by,
say,
a
hash
of
relevant
arguments
(
unit
id/health/location/reload
timer/target
id
etc.
)
and
the
game
frame.
I
get
that
hashing
a
bunch
of
garbage
every
time
you
want
to
assign
a
unit
ID
is
a
lot
more
time-consuming
than
incrementing
a
counter,
but
I'm
not
under
impression
that
unit
creation
is
a
major
bottleneck
right
now.
For
RNG
you
might
even
find
something
that
behaves
well
with
being
seeded
every
time
you
call
it.
We're
surely
not
the
only
ones
with
need
of
reasonable
(
but
deterministic
in
given
parameters)
randomness.
|
| 9 |
\n
|
9 |
\n
|
| 10 |
And yeah, it's easy to suggest something from the outside with no clue how things work [url=https://xkcd.com/793/](relevant xkcd)[/url], but I'm just trying to come up with solutions for presented problems. It's what I like to do.
|
10 |
And yeah, it's easy to suggest something from the outside with no clue how things work [url=https://xkcd.com/793/](relevant xkcd)[/url], but I'm just trying to come up with solutions for presented problems. It's what I like to do.
|
Zero-k Running on ONE core at a time!!!