Removing Widgets

[Argh]

Um, I need to write some code that disables certain Widgets that are included in Base, as well as several popular Widgets for people playing BA that will screw up P.U.R.E.'s UI.

How do I do that?

[aegis]

there's a text file

[Argh]

Care to be more specific?

I need to do the equivalent of widget.RemoveWidget, but not self-referential, and I'd like to do that during PreLoad, if possible.

[Argh]

Oh, fudge! Worse than just graphical screwups, Custom Icons causes a crash, when I enable it then try to remove it!

Look, people, I've tried including copies of main.lua, empty versions of the Widgets, and an altered version of the Config script... none of that works. How do I kill Widgets that should never, ever be allowed to run with my game?

[lurker]

LockLuaUI doesn't have any ability to use parameters, it only blocks out the entire user folder. I think that's what aegis was referring to.
I'm currently writing a simple widget to temporarily disable other widgets, if you want it, argh. The key is to put the widget into raw handler mode, not safe wrap mode.

So it crashes just to load it? That's a bit more complicated to do, but still easy enough, I should get that done today if there is no better solution.

[trepan]

SafeWrap ('unsafe') and widgetHandler ('handler') widget modes are independent.

You could use LockLuaUI.txt and setup your own widgetHandler
to screen out the undesirables. It's not a particularly easy thing
to setup, nor is it supposed to be.

As for crashes, stacktraces are useful.

[Argh]

LockLuaUI doesn't have any ability to use parameters, it only blocks out the entire user folder.

Ok, I've just tested LockLuaUI... my Gadgets, such as my UI, display, but all of my game's Widgets are disabled, the UI is screwed up, and F11 is now the screenshot button- not exactly what I wanted

And yes, I definitely want to test what you're writing.

You could use LockLuaUI.txt and setup your own widgetHandler
to screen out the undesirables. It's not a particularly easy thing
to setup, nor is it supposed to be.

Ok, so I'd disable it, then I'd have to include all of the files in the LuaUI root, and change the following in widgets.lua?

Code: Select all

local ORDER_FILENAME     = LUAUI_DIRNAME .. 'Config/widget_order.lua'
local CONFIG_FILENAME    = LUAUI_DIRNAME .. 'Config/widget_data.lua'
local WIDGET_DIRNAME     = LUAUI_DIRNAME .. 'Widgets/'
local MOD_WIDGET_DIRNAME = MODUI_DIRNAME .. 'Widgets/'

Please let me know if I'm totally off base. I've already wasted 3 hours on this, and I wanted to code up an example of lighting-over-time into the World Builder map

This is something that practically everybody wanting to write a new UI needs. What I think is that we need a statement that simply allows only named Widgets and Gadgets in a config, and will only let users override it if they specify it in Settings. I'd rather maintain a list of Widgets I know are good, because I've configured them for my game, than weed out the huge list of Widgets that I haven't tested yet.

I'll sit down and see what I can do with that.

As for crashes, stacktraces are useful.

Yes. I wasn't expecting that, it's been stable otherwise.

Attached.

[trepan]

Translated stacktraces are even better,
but it didn't matter in this case, committed
the fix to SVN before your post The
more important thing here is that a crash
bug wasn't reported either via Mantis or
this forum.

[Argh]

I've just tried LockLuaUI, and despite copying the entire LuaUI folder to my game, it doesn't work. No UI was loaded, no Widgets will run. What am I doing wrong?

[lurker]

Oh, I thought the safewrap thing was what set handler mode. So safe mode adds some pcalls and GL state saving?
Anyway, I'm making a simple handler=true widget to block the loading of specified widgets.

[Argh]

I've added gui.lua to my project, and pointed it to MODUI, but it still isn't working right. The Lua WidgetHandler dialog UI won't show, and it "jams"- it won't even run the Widgets until I hit shift-escape, and I have to hit it twice before Spring quits

I assume that this was built with the intention of providing a way to write a new UI from the ground up. I've been wanting to tackle this at some point, what other files do I need to include, besides the root of LuaUI and gui.lua?

Oh, and Lurker, that's great news... if you can get that working, it'll give me a roundabout way to wipe the UI out. Personally, I think that's the way to go anyhow- wipe out all of the standard Widgets, then design a Gadget UI...

[lurker]

All of them? That confuses me.

[Argh]

I'm exaggerating a little bit.

I wouldn't drop the ones that don't jack up the UI or ruin the game. I think it's probably the fastest way to get to an all-custom UI- junk everything by default, build the UI, then let stuff back in once it's tested, not assume stuff is Ok by default. I know you're taking the opposite approach, and building a 'ban list', but reversing it to only run those things that have been tested shouldn't be too scary.

Basically, all of this comes down the fact that game versions of a Widget should override user versions. We (me, Gnome, WZ and others, IIRC) saw this coming a long time ago- when it's time to finally have professional-looking UIs, it'd make life a lot easier for UI developers if we could just take the current, well-tested Widgets, clean them up a bit visually to match the rest of our games, and correct issues like their placement on the screen, as well as flat-out banning the ones we don't want users to be able to run- one game's friendly add-on is another's exploit that gives an unfair advantage. And no, I can't think of any off hand, I'm just saying that it's a possibility and that I'd rather not have my hands tied- that's a game designer decision, imo.

As that's currently impossible, the next-best route is to disable them all, then selectively re-enable them, under new names, and then fix them. Kinda stupid, imo, but hey, that's how it goes.

[Argh]

Ok, I've done further testing.

With LockLuaUI enabled, gui.lua in the root of my game, and all of the files in the root of LuaUI in the ModUI folder, I see the following problems:

1. At the beginning of the game, I see text, but the UI doesn't draw as normal. I assume this is because it got deleted.

2. When the game starts, I can see elements drawn by Gadgets, but nothing drawn by Widgets draws, until I hit the ESC key.

Then Spring reports that it's loaded all of the Widgets, and they run. But it will not show the Widget Selector UI at that point, so users couldn't turn them on / off.

Moreover, I see graphical problems- the Healthbars Widget I'm using, for example, is being fed bad data about the reload times for weapons, and draws a huge bar when they're reloading.

Basically, this route is buggy, unless I'm missing some crucial file that fixes it all.

[EDIT] Re-tested everything, and I'm entirely sure it wasn't anything else wrong. Removing the files and returning to my stock configuration restored everything to normal. So, until either the LockLuaUI route works correctly, or I have some way to remove Widgets, I'm stuck [/EDIT]

[Argh]

Any progress on this? I've been away for the last two days...

[quantum]

How about:

Spring.SendCommands{"luaui disablewidget CA Interface"}