You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been talked about a bit on the MCF and been discussed a bit more in semi-private: I'm planning to add "servers" with remote terminals. Originally the idea was to have them wired, but I felt this would be too similar to what could be achieved using normal computers, some cable and screens. So right now I'm planning to have the terminals be wireless handheld items. A server rack would act as primary access points, further access points (blocks) can be placed that, as long as they're connected via cable to the server rack, act as extension of the range. Each rack can contain multiple servers, each server can be bound to exactly one wireless terminal.
Individual servers could be upgraded by adding RAM and hard drives as computers can be, but possibly also by adding more CPUs. I've been thinking long and hard about the suggestion of multiple CPUs allowing for multi-threading in the servers, but have decided that this wouldn't be worth the effort it'd take: all Lua states have to yield within a very short time frame anyway (enforced by the kernel so they don't lock up an executor thread), so there isn't really any need for multi-threading - you can just start multiple coroutines, which in turn by definition above have to yield quickly. You can then resume all of these sequentially until they're all done. A scheduler library could abstract this to a level where it'd be impossible/pointless to distinguish whether the underlying workers are coroutines or threads.
Instead, I think I'd prefer another effect - allowing more components to be addressed by the server. Which brings me to the next point: I'm also thinking of adding a new restriction to low level computers to make upgrades and servers more attractive: the number of components that can be attached to them (see #18).
The text was updated successfully, but these errors were encountered:
This has been talked about a bit on the MCF and been discussed a bit more in semi-private: I'm planning to add "servers" with remote terminals. Originally the idea was to have them wired, but I felt this would be too similar to what could be achieved using normal computers, some cable and screens. So right now I'm planning to have the terminals be wireless handheld items. A server rack would act as primary access points, further access points (blocks) can be placed that, as long as they're connected via cable to the server rack, act as extension of the range. Each rack can contain multiple servers, each server can be bound to exactly one wireless terminal.
Individual servers could be upgraded by adding RAM and hard drives as computers can be, but possibly also by adding more CPUs. I've been thinking long and hard about the suggestion of multiple CPUs allowing for multi-threading in the servers, but have decided that this wouldn't be worth the effort it'd take: all Lua states have to yield within a very short time frame anyway (enforced by the kernel so they don't lock up an executor thread), so there isn't really any need for multi-threading - you can just start multiple coroutines, which in turn by definition above have to yield quickly. You can then resume all of these sequentially until they're all done. A scheduler library could abstract this to a level where it'd be impossible/pointless to distinguish whether the underlying workers are coroutines or threads.
Instead, I think I'd prefer another effect - allowing more components to be addressed by the server. Which brings me to the next point: I'm also thinking of adding a new restriction to low level computers to make upgrades and servers more attractive: the number of components that can be attached to them (see #18).
The text was updated successfully, but these errors were encountered: