Spring RTS Engine

Niobium wrote:

zwzsg wrote:Then I'd say that widgets that do nasty stuff even when disabled should be killed on sight.

Exactly this. To write a widget that messed with things mod-wide, only on particular mods, and even when disabled would require either deliberate intent or gross incompetence. Do you have the names of some of these widgets?

http://trac.caspring.org/changeset/8169
Nothing that crashes, but very annoying. Executed regardless the widget is enabled or not.

Read the P.U.R.E. source, it has a working whitelist for things that are known to be safe and tested. And I wrote a blacklist that worked OK at one point as well, although I agreed with the feeling at the time that it would be more of a time-waster than not.

There aren't any other solutions.

Widgets as a concept without game filtering was a mistake. Now we're stuck with either invalidating all of the old Widgets (which, personally, I'd be fine with) until they're updated to deal with game filtering, or just customizing a game to do whitelist. There's nothing else worth bothering with.

I already said I don't want whitelist, i am trying to understand why the selections.lua isn't read in vfs.

Oh, so you're hoping that Widget writers will, eh, "Gundam-certify" their wares?

Good luck with that. I guess that we're done here.

Smoth's current plans have quite some merit imo. It's about (much) more than widgets.

widgets are the start point.

Niobium wrote:

zwzsg wrote:Then I'd say that widgets that do nasty stuff even when disabled should be killed on sight.

Exactly this. To write a widget that messed with things mod-wide, only on particular mods, and even when disabled would require either deliberate intent or gross incompetence. Do you have the names of some of these widgets? I'd like to see what was done, as I've never seen this kind of widget before, I also reckon they could be fixed with a simple copy-paste into :Initialize.

Its not deliberate intent or that gross incompetence, but many people put their initialisation code "outside of any function" instead of within Initialize(). Trepan showed the way but using variable initialization and some small "if" test on game constants, but he knew his stuff and never used command that change things. But then people started coding in the same manner, and then they started using commands there, without thinking about the consequence.

But the only exemple I remember is indeed Regret's specrun. I remember Smoth raged alot and Regret was delighted upon learning he accidentally broke GRTS. Then maybe it was Regret's weird humor, I don't know, maybe he fixed it later, well at least so I hope.

Its not deliberate intent or that gross incompetence, but many people put their initialisation code "outside of any function" instead of within Initialize().

Wait wat, I did that too.
Only short init stuff though.
So to understand correctly, this is basically bad because stuff outside functions gets executed even if the widget/gadget is disabled?
Tbh I thought files with enabled=false in GetInfo() are just ignored.

Yes, that is why when I disable widgets in evo but leave them in (because I might have use for them later) I actually rename the file. Enabled = false, doesn't actually work most of the time.

Enabled = false only work for the first time a mod sees a widget. Afterward, the mod reloads the LuaUI config.

knorke wrote:

Its not deliberate intent or that gross incompetence, but many people put their initialisation code "outside of any function" instead of within Initialize().

Wait wat, I did that too.
Only short init stuff though.
So to understand correctly, this is basically bad because stuff outside functions gets executed even if the widget/gadget is disabled?
Tbh I thought files with enabled=false in GetInfo() are just ignored.

No.

Remember Lua is an interpreted language. The object and the GetInfo() function are created by executing the whole file. So the logic is "execute file, take resulting object, call GetInfo on resulting object... .when enabled, call Initialize on that object".

See? If you have any code in the file, it gets hit in the first step.

hmmm I see I didn't mentioned it yet here, but I have a new widgetHandler in work, it will make configuration easier and will add sandboxing to the first loading of the widgets (GetInfo thingy) and maybe add a new trepan-style widget format (with backward support for the old one). Estimated time till it's finished 1-2months.

so apparently it WAS
local text = VFS.LoadFile(filename, fromZip and VFS.ZIP or VFS.RAW)

simple fix was.
local text = VFS.LoadFile(filename)

Flozi helped me debug it last night. Chest bump bro!