Addon handler development direction?

Addon handler development direction?

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Addon handler development direction?

Post by gajop »

Any thoughts on what should be done with the various addon handlers?

To my understanding, right now in the engine we have 3 different handlers:
- LuaUI for LuaUI. The oldest (?) of the bunch, with most games using some offshoot of that. Really annoying to update with new callins all the time.
- An equally old LuaGadgets handler facing most of the same problems, but with the main difference being that this one is actually in the springcontent archive.
- A more modern LuaHandler, which automatically adds engine callins as far as I can tell. Also probably more modular and better for other reasons?

Can't maintain them all, would like to pick one and purge the rest. Ideally the choice would be the "new" LuaHandler (still like 5 years old lol), with LuaUI and LuaRules based on that.
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Addon handler development direction?

Post by Silentwings »

I'm afraid this isn't going to be much help, but I always found the "new" style handler were a pain to get working, less clear code to read, seemed to be missing "matching" features (selector/actionhandler/...), and were less helpful in fixing/detecting "hard" bugs related to callin order/execution, also when flexibility was needed e.g. to interact with BARs chili widget selector or BAs "factory reset Luaui" facility.

In practice updating the classic-style handlers took ~no time, because callin changes are rare and simple. I think games will always want to modify the handlers at some stage in their development, even if the current situation was cleaned up, and they certainly need access to them (or else bugs like https://springrts.com/mantis/view.php?id=4659 would be serious wtf to detect).

What's perhaps worse and more easily fixable - the action handlers are a mess too, viewtopic.php?f=14&t=34611&p=576864#p576864
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Addon handler development direction?

Post by Kloot »

Just leave them.

Existing games are not going to make the transition anymore at this point, and the old-old handlers have proliferated too many times. More importantly their codebases are debugged (except for #6023) / well-understood whereas the addon handler has received nowhere near the same amount of attention. The automatic callin registration system could (and probably should) also just be backported if manual labor gets too annoying.

It would be nice to at least unify the WH and GH, but as Silentwings said there are bigger fish to fry.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Addon handler development direction?

Post by gajop »

You both make good points, I'll avoid doing big destructive changes, and suppose I can leave it entirely for now.

Regarding games using their own addonhandlers, I think that's awful, and is part of the reason handlers aren't seeing much work lately. Hard to bug fix and improve them when no game used them anyway. Surely there are other way to customize them instead of forking.

In addition, it can take ages for new callins to propagate, and we can't make reliable libs/frameworks that depend on such functionality. I remember the frustration of TextInput being randomly broken in various games, making Chili editbox adoption slower and very error prone.

But anyway, I'll do some other task for now
User avatar
Jools
XTA Developer
Posts: 2816
Joined: 23 Feb 2009, 16:29

Re: Addon handler development direction?

Post by Jools »

Kloot wrote: 22 Oct 2018, 16:45 Just leave them.

Existing games are not going to make the transition anymore at this point, and the old-old handlers have proliferated too many times. More importantly their codebases are debugged (except for #6023) / well-understood whereas the addon handler has received nowhere near the same amount of attention. The automatic callin registration system could (and probably should) also just be backported if manual labor gets too annoying.

It would be nice to at least unify the WH and GH, but as Silentwings said there are bigger fish to fry.
+1

Old code is good. Code, unlike food, has no expire date.
Post Reply

Return to “Engine”