[DiscordArchive] I see how that is a downside for projects with intensive use of Eluna.
[DiscordArchive] I see how that is a downside for projects with intensive use of Eluna.
Archived author: Honey • Posted: 2022-08-20T10:01:51.849000+00:00
Original source
I see how that is a downside for projects with intensive use of Eluna.
Would it be possible to let a map state pass a command to a global state and the global state sends it to other map states async?
Archived author: Honey • Posted: 2022-08-20T10:02:09.382000+00:00
Original source
As in "Do it when you can".
Archived author: Foe • Posted: 2022-08-20T10:02:22.469000+00:00
Original source
that would enforce locking again, so the performance benefit would be lost
Archived author: Foe • Posted: 2022-08-20T10:02:46+00:00
Original source
on each world update we'd have to lock everything to process the global state
Archived author: Honey • Posted: 2022-08-20T10:05:47.361000+00:00
Original source
Hmm i don't see how i could make use of that feature then, sadly
Archived author: Foe • Posted: 2022-08-20T10:11:05.974000+00:00
Original source
Much can be done with proper core side support for caching, but that's not part of the scope right now at least. It will only really make data available for all the states (even if you can only rely on the next-tick accuracy) so you'd use it more as an async queue. Eluna at some point will have to adopt multi-state as default though, the locking we currently do with the amount of map update threads is very bad
Archived author: Honey • Posted: 2022-08-20T10:18:03.862000+00:00
Original source
I get the motivation, and it might make sense from your perspective.
But if it limits my ability to do global things, i don't see how we can use that at all.
You say "caching" support in the core. What is that about?
Archived author: Foe • Posted: 2022-08-20T10:21:37.251000+00:00
Original source
Ideally we'd have a structure in the World object where we can store key-value pairs, then the Lua states could read and write to that asynchronously. It would have to be up to the scripter to make it work as intended, but you'd have say a WriteGlobalData(key, value) and ReadGlobalData(key).
In scripts, you'd then have a timed event that reads the global data for a specified key and performs actions based on this data. It doesn't ensure that this data is "fresh" on the current tick, so you'd have to take that into account.
Archived author: Foe • Posted: 2022-08-20T10:29:03.156000+00:00
Original source
So lets use your map wide hide and seek as an example, with map 0, 1 and 2:
All maps checks on a local timer if a global data value has been set for an object being found. Lets say the object exists on map 1 and is found on the 2nd tick
Tick 1:
Map 0 - No object found, no value in Global Data struct, checking next tick
Map 1 - No object found, no value in Global Data struct, checking next tick
Map 2 - No object found, no value in Global Data struct, checking next tick
Tick 2:
Map 0 - No object found, no value in Global Data struct, checking next tick
Map 1 - Object was found, write value to Global Data structure, execute event
Map 2 - No object found but value was found in Global Data struct, execute event
Tick 3:
Map 0 - No object found but value was found in Global Data struct, execute event
Map 1 - Event was already executed
Map 2 - Event was already executed
This is the only "real" feasible way to deal with cross-state communication in a non-locking way
Archived author: Foe • Posted: 2022-08-20T10:29:34.440000+00:00
Original source
The issue is that data could be stale by the time you need it, or not be there when you expect it to, since threads are ran async