We already have the problem of letting unsynced communicate with synced.
I know. I'd been doing a little bit of modding on the side, you know.
I've actually dealt with it. It certainly did involve some pretty ugly messaging made hugely inefficient by the lack of engine support.
Didn't I say just two posts go I've dealt with a funnily convoluted path:
For my "dump" command, I've had to use LuaUI -> Spring.SendCommands -> LuaRules (synced) -> SendToUnsynced -> LuaRules (unsynced) -> Script.LuaUI -> LuaUI ?
Oh yes, yes I did say it. So why do you presume I never needed such?
There aren't a lot of situations that demand this, to be sure, but there are a few. Let me enlighten you
1. ...
2. ...
No one ever contested we need synced <-> unsynced communication. Everybody here operate under the idea of: We need it, how do we do it? So, strawman much?
The big problem is that your solution amounts to: Use magik!
But, if you had bothered to think about the quoted part of my previous post, you'd see that either:
- Magik is sure desirable, but not really achievable.
- Any system appearing easy as magik to the user is actually powered by unintelligible super advanced technology.
If you prefer, to make synced<->unsynced Lua gadget comm as simple as a shared table, you will need an awful mess in the engine. And, worse, you can't avoid side-effect breaking the shared table illusion about, oh, roughly everytime it's used maybe. Again, refer to the quote of my previous post:
On the surface, that exemple gadget would looks simple: unsynced get the pressed key, pass it to synced. Until you realise that in multiplayer, all synced state must the same, all unsynced state can be different, which mean that no matter how you want the engine to handle it, what is read in synced isn't what is written in unsynched.
- Player A press key 1, so SYNCED.kp=1
- Player B press key 2, so SYNCED.kp=2
- The Player A & B computer's synced states are identical, so 1=2
Oops your sytem requires a breach of logic. Well, no big deal, uh?
After all if it's desirable for all your FBO and mutex and threadlock and MT and OpenGL, then let it be!
By wishful thinking of Argh, 1 should from now on be declared as equal to 2.
And indeed, if we could have 1=2, then we'd have resolved any and every problem!
So that is the solution! Why don't dev make it happen?
Or, we get serious and realise that it wouldn't really be a shared table, but some bulky system in the engine that collect all the values from the unsynced side of every computer, pick one (which? Lastest? Host?), make sure every client pick the same, then send the chosen value back to every computer accross the nework. So, an unclean, slow, and
deceptive system.
So:
- The ugliness of the black magik needed engine-sided would counterbalance how clean it'd appear on the Lua side.
- Presenting as a shared table what conceptually can't even be would be dangerous, the user would think it's table, while it's a fake, an illusionary bridge over a fiery pit. Better expose the peril clearly.
Of course, this answer operate on the premises you understand what synced/unsynced means to Spring. Which I'm pretty sure you don't, at least not completly, not with its implications. Answer the quote of my previous post if you do.
Using GameFrame() means that it occurs when sim has mutex lock and has access to the single data source
Typical Argh sentence: sounds impressive, until you get to its meaning, and realise it's senseless, just a grammatically correct sentence formed with words randomly picked up from dev threads.