Split from viewtopic.php?f=1&t=33366
https://springrts.com/wiki/Lua:WidgetDirectory
+
https://springrts.com/wiki/WidgetDatabaseFAQ
Both link to http://widgets.springrts.de/ which just redirects to the main Spring page.
Is there a correct link?
widget database
Moderator: Moderators
-
Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Wiki: issues + quick questions/answers
I don't think so.
I personally think the "games are so diverse we shouldn't have a widget database anymore" argument is rubbish. But games are diverse enough that it will often need a lua/game dev to spend a few minutes modifying a particular widget to work with a particular game. And I think the reality is that any Spring game that is released outside of Spring will disallow users to add widgets, by default, simply because its the only way to ensure players don't break their own game and not even realize it was their fault.
So I think it makes sense to have a quite disorganized, throw-it-all-in-even-it-its-a-bit-broken style widget archive (I guess on github) for devs to fish code out of. I'd be happy to maintain this, if it existed, in the sense of keeping it organized (but not in the sense of maintaining all the semi-broken code).
I personally think the "games are so diverse we shouldn't have a widget database anymore" argument is rubbish. But games are diverse enough that it will often need a lua/game dev to spend a few minutes modifying a particular widget to work with a particular game. And I think the reality is that any Spring game that is released outside of Spring will disallow users to add widgets, by default, simply because its the only way to ensure players don't break their own game and not even realize it was their fault.
So I think it makes sense to have a quite disorganized, throw-it-all-in-even-it-its-a-bit-broken style widget archive (I guess on github) for devs to fish code out of. I'd be happy to maintain this, if it existed, in the sense of keeping it organized (but not in the sense of maintaining all the semi-broken code).
Re: Wiki: issues + quick questions/answers
I partially agree, although I think libraries(frameworks) as dependency modules or separate repositories are the way of the future.
We need a better way of distributing, modifying and maintaining code than simple copy-paste-edit.
Currently some games like ZK have a large number of widgets included which are disabled by default, and that's their (imo, not so great) way of distributing widgets.
I'm lazy to dig it up, but I think AF once mentioned some sort of improved dependency management, which is what we'll do with rapid dependencies. This, along with library/module-based development is something I'll try to push.
Widgets can of course be libraries, but so can gadgets and other resources.
A repository with up-to-date addons is what some feel is needed. (It would also make it easier to port games to chili if that were the case)
We need a better way of distributing, modifying and maintaining code than simple copy-paste-edit.
Currently some games like ZK have a large number of widgets included which are disabled by default, and that's their (imo, not so great) way of distributing widgets.
I'm lazy to dig it up, but I think AF once mentioned some sort of improved dependency management, which is what we'll do with rapid dependencies. This, along with library/module-based development is something I'll try to push.
Widgets can of course be libraries, but so can gadgets and other resources.
This is good too (especially for now), and I'm willing to lend you a hand in this.So I think it makes sense to have a quite disorganized, throw-it-all-in-even-it-its-a-bit-broken style widget archive (I guess on github) for devs to fish code out of. I'd be happy to maintain this, if it existed, in the sense of keeping it organized (but not in the sense of maintaining all the semi-broken code).
A repository with up-to-date addons is what some feel is needed. (It would also make it easier to port games to chili if that were the case)
I would be surprised if that turned out to be so. Certainly I can expect ZK (as well as most Steam games) to enable the Steam workshop which would at the very least include widget distribution. I really don't think we should limit ourselves to only Steam, since we're an open source community and relying entirely on a third-party closed-source solution (even though it's considered quite favorable among the gaming and Linux crowd) is wrong.And I think the reality is that any Spring game that is released outside of Spring will disallow users to add widgets, by default, simply because its the only way to ensure players don't break their own game and not even realize it was their fault.
-
Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Wiki: issues + quick questions/answers
I don't think submodules & rapid dependencies work for individual widgets, because there are too many tiny differences between games. I'm also a bit hesitant about it in general, for all except the largest dependencies (e.g. lups, chili) because its a pain to debug something when the code is spread across multiple archives & some of these archives might be inside rapids impenetrable pool of incremental updates, which in turn can cause painful archive location conflicts if you then try and get a sdz version of it, or change things in modinfo.lua, etc etc. Whenever I've had to do this in past I usually ended up wiping archivecache/pool and friends.
As soon as a widget has some interaction with the UI or has interaction with gadgets, there are likely to be small differences between the "same" widget in different games. E.g. for BA(R)
> Ghost Site - enemy wrecks are visible to all, so these have to be removed from the widget, which normally draws them
> Healthbars - there is an special extra "charge" bar for the commanders dgun
> Adv Pl List - shows ready states of players with a "traffic light system" that interacts with multiple BA specific spawning gadgets (although ofc I don't mind if others copy the gadgets), displays TrueSkill in a way specific to SPADS hosts, etc.
I could provide similar things for maybe 60% of the widgets in BA(R), probably nearly all the gadgets, and I would guess other game devs could do similarly. As a result, although these widgets can be modified by a competent dev in only a few minutes to work with another game, if taken "out of the box" they will have visual defects or just crash.
So if a widget repo designed for players was to exist today, afaics for the majority of widgets it would have to contain different versions for most games. At this point I think you may as well just distribute & maintain the game specific version with the game, although ofc gamedevs often won't want to add new code into their game unless its clean and maintainable, but that's just life, if the feature is wanted by the game then the work has to be done somewhere; but it can't be done by someone who is just maintaining a generic widget database.
As soon as a widget has some interaction with the UI or has interaction with gadgets, there are likely to be small differences between the "same" widget in different games. E.g. for BA(R)
> Ghost Site - enemy wrecks are visible to all, so these have to be removed from the widget, which normally draws them
> Healthbars - there is an special extra "charge" bar for the commanders dgun
> Adv Pl List - shows ready states of players with a "traffic light system" that interacts with multiple BA specific spawning gadgets (although ofc I don't mind if others copy the gadgets), displays TrueSkill in a way specific to SPADS hosts, etc.
I could provide similar things for maybe 60% of the widgets in BA(R), probably nearly all the gadgets, and I would guess other game devs could do similarly. As a result, although these widgets can be modified by a competent dev in only a few minutes to work with another game, if taken "out of the box" they will have visual defects or just crash.
So if a widget repo designed for players was to exist today, afaics for the majority of widgets it would have to contain different versions for most games. At this point I think you may as well just distribute & maintain the game specific version with the game, although ofc gamedevs often won't want to add new code into their game unless its clean and maintainable, but that's just life, if the feature is wanted by the game then the work has to be done somewhere; but it can't be done by someone who is just maintaining a generic widget database.
Re: widget database
I think this thread discusses BA and BAR more than widgets in general. What's the problem of keeping the widget database as it is? Just fix the link.
Re: Wiki: issues + quick questions/answers
@Silentwings:
I think it would be ideal if most addons could be customized with configs, and in many cases that should be possible.
With submodules you can still have custom modifications while simplifying updates (which is what my projects do with chili for example).
In any case the point is that modifications should be avoided whenever possible, but more importantly I want people to have a number of packages they can use with minimal setting up.
@Jools:
What's the link? Is it still hosted someplace?
Also he was right to give examples.
I think it would be ideal if most addons could be customized with configs, and in many cases that should be possible.
With submodules you can still have custom modifications while simplifying updates (which is what my projects do with chili for example).
In any case the point is that modifications should be avoided whenever possible, but more importantly I want people to have a number of packages they can use with minimal setting up.
@Jools:
What's the link? Is it still hosted someplace?
Also he was right to give examples.
Re: widget database
oops, got broken due server config change. just fyi, its hosted at the springfiles.com server.
-
Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: widget database
Based on history, I don't think there's any practical chance of persuading game devs & random lua devs in general to not customize stuff, and only a very slim chance of persuading them to customize widgets/gadgets in ways that preserve compatibility with other games. I think it's reasonable too - there are simply too many other games to test against in sane time. Even if they really tried and did it, I think it would often result in such a complex set of configs that soon no person would bother to maintain the result & divergence would gradually happen anyway. Maybe someone has the motivation to maintain sanitized minimal versions of useful addons; I could see that working but I at least don't have the spare time to do it.
But, my point is, if you forget the "it must work out of the box with all games" and replace with "it will probably work after you spend 15 minutes fixing/adapting it" then (you get what actually already happens) game devs hoover up and maintain good widgets/gadgets automagically. Then all that has to be done is occasionally collate/update them from their games, include new widgets if they appear "at random", throw out the ones with really poor code, and for very little effort you get an archive that imo is probably helpful to most lua devs.
But, my point is, if you forget the "it must work out of the box with all games" and replace with "it will probably work after you spend 15 minutes fixing/adapting it" then (you get what actually already happens) game devs hoover up and maintain good widgets/gadgets automagically. Then all that has to be done is occasionally collate/update them from their games, include new widgets if they appear "at random", throw out the ones with really poor code, and for very little effort you get an archive that imo is probably helpful to most lua devs.
Re: widget database
Im up for hepling out if this happens.
So I think it makes sense to have a quite disorganized, throw-it-all-in-even-it-its-a-bit-broken style widget archive (I guess on github) for devs to fish code out of. I'd be happy to maintain this, if it existed, in the sense of keeping it organized (but not in the sense of maintaining all the semi-broken code).