SendLuaRulesMsg wtf

[Argh]

It used to be possible to send Gadgets a message via this... doesn't seem to work in the build of Spring I'm using. Tests show nothing arriving via RecvLuaMsg() on the synced Gadget side.

I really need to send a Gadget information that is only available on the unsynced side of things (in particular, I need map light settings).

It's a one-time message that should occur right around the start of play, used to set stuff up for POPS.

Anyhow, if there's a straightforward way to fix it, I need it asap, it's one of the things I need to fix before I can release my tech demo.

[Niobium]

How can a gadget be synced while operating off unsynced information? I imagine this is the reason why the synced side doesn't/can't receive information from unsynced space.

Unless the 'map light settings' are really synced, at which point the issue is that synced doesn't have access to this synced information.

[Argh]

How can a gadget be synced while operating off unsynced information?

I'm just copying a constant that is identical across gamestates. It's done well before synced needs to read it, so it should be OK.

Anyhow, I fixed it, it was a screwup in other code causing the issue.

[AF]

POPS purpose is to do something that is by definition unsynced. To implement it in synced land in a way that requires unsynced to synced communication shows that this principle has not been applied correctly.

Eitherway what your complaining is not working, is something I would actually consider an engine bug if you had it fixed.

[Argh]

The problem's with Spring's design, AF.

Unsynced Gadgets have the same problems getting access to all the data that's required that Widgets do, including problems with callins simply not functioning, or true unitIDs not being available, unit scripts may not call unsynced Lua functions, etc., etc.

LUPS has exactly the same problems, and as a result has a similarly baroque design.

The best long-term solution is for all synced events to be mirrored in unsynced Gadget space, so that these kinds of workarounds aren't necessary. Until then, we're stuck with a lot of really awful kludges.

Anyhow... this particular problem was just user error. The other workarounds are, unfortunately, a different problem entirely.

[Tobi]

it's just a few lines that can be implemented as a framework/include for your other Luas

http://answers.springlobby.info/questio ... d-luarules

[Argh]

Hrmm.

That should save on SendToUnsynced traffic quite a bit- should be cheaper than the current method.

I'll have to globally handle particle initialization, or rewrite the subsystems as includes, though, which will be fairly yucky, but that should eliminate a lot of extra mess.

[Argh]

Thanks for the tip- took 4 hours to rewrite the event creation side of things and test it out, but it's definitely cleaner and faster this way.

Now I just have to convert all of the ancillary scripts over to the new format and test the hell out of everything, and finish the groundquad shader, and I'm finally ready <sigh>