Fix LockLuaUI.txt!!!

[Argh]

LockLuaUI.txt currently is a switch. If present, then only the gui.lua of the core game can operate, which in turn loads the Widget Handler, etc., which has to be duplicated.

Games which use multiple core directories are broken.

Map Widgets are DOA.

This is a terrible way to implement this.

Look, people. It should be a very simple thing: if game designers don't want players to be able to use Widgets that aren't part of their game files or a map... it should just be a really simple switch.

And no, don't tell me that CA fixed this, and that everything's fine, and that I'm stupid. Already heard that song and dance from Trepan, and it's a bunch of bullshit, frankly.

CA's method breaks map Widgets- I've already tested that.

Nor does it work with multiple mod directories and dependencies. I've already tested that, too.

So, CA would never be able to use World Builder, basically, and World Builder maps would be DOA, because I am using Widgets in them for visual effects that might kill low-end computers and aren't an essential part of gameplay.

Please... just fix it.

Widget writers keep coming up with new stuff that I consider cheating, and there simply isn't any other real way to deal with that.

I've tried blacklist and whitelist stuff, and the fact of the matter is that whitelist stuff can be circumvented, and blacklist stuff is impossible to implement because Trepan rather inconveniently doesn't allow Gadgets access to the Widget table (which is also set as read-only), where we could remove stuff, so it's flat-out impossible to use a Gadget to clear out bad Widgets (not that that would be a good approach in the long term anyhow).

We need a very straightforward, simple way to simply not allow Widgets that aren't created by game designers or map designers, period.

[jK]

erm what?

1. CA uses only a custom widgetHandler -> trepan disliked it that i overwrote the default one myself with a widget on each client (default one is missing many callins/arguments)

2. why shouldn't it work with "multiple core directories" and what are those?

3. why shouldn't a custom widgetHandler be able to load map widgets?

[Argh]

Ok, here's what's going on:

1. World Builder is a physically separate archive.

The idea behind it is that it's a bit like an add-on module for Firefox- game designers would get it, follow some instructions about how to integrate a SDK with their games and make a few minor changes to certain game files, and then their games are ready to use it. Ideally, they'd only have to do that once... then future updates to World Builder would be something they wouldn't have to worry about, because they'd already be ready.

2. Map Widgets, are, for obvious reasons, physically separate archives.

3. At runtime, what LockLuaUI.txt does is prevent all separate archives from being able to operate Widgets, whether or not you put a gui.lua into place, etc.

It doesn't do what it should do, which is merely exclude all Widgets installed by end-users (or, if we want to be really hardcore about the whole thing, maybe we need a second option- "LockUserLuaUI.txt" that just does that...).

Coding a workaround has proven to be a complete nightmare, because of VFS not having any way to know what's a "part of the game we're running", except in the narrow sense of PURE.sdz.

To make absolutely clear what's going on, here's a chart:

Without LockLuaUI.txt:


With LockLuaUI.txt:


What I think should happen:


At any rate, the problem here is exclusion of the files. I don't want to wipe out the UI, basically, I just want to prevent people from using Widgets that I haven't checked for cheating uses. If people make maps with cheating Widgets in them... that's just fine with me, players will decide if they like that or not, it's not my business.

[jK]

you are totaly wrong ...

I still don't understand what you think LockLuaUI.txt is, but your idea of it is just wrong.

fact is what you want is already possible.

PS: your 2nd chart is IMPOSSIBLE atm.

[Argh]

I know what it does. It wants us to load up a new gui.lua, widgethandler, etc.

That's all well and good.

However... I don't want to do that. I just want to lock user Lua out. That's all.

P.S.: that third chart is what I want. Which is why I wrote this. Maybe spend less time telling me I'm an idiot before looking at what I wanted to do...

P.P.S.: the SECOND chart is what actually happens. Don't tell me it's "impossible", when it's what happens, when tested.

[jK]

I know what it does. It wants us to load up a new gui.lua, widgethandler, etc. ...
However... I don't want to do that. I just want to lock user Lua out. That's all.

both is bound to each other ... (just think about the directory stucture and you will found out yourself why ...)

P.P.S.: the SECOND chart is what actually happens. Don't tell me it's "impossible", when it's what happens, when tested.

it is impossible, the VFS CANNOT differ between map and mod files!
and you still didn't spend 1 sentence on what you did!

[Argh]

Sorry, you're right. I am not explaining my test setup, and quite honestly I am being a grump-ass at you- I apologize.

Maybe there's a glaring hole in my conditions, etc.

Here was my test setup:

1. Make a "game" that is empty, and calls CA and some other thing called, I dunno, "CA_WIDGETS.SDZ", just like a "mutator" would.

2. Take all of CA's LuaUI Widgets,(leave main, camain, gui.lua etc. where they are) and stick them into a third "game", that is then called by the first "game" as CA_WIDGETS.SDZ.

Leave LockLuaUI.txt in the main CA folder.

3. Start Spring. You will not see any Widgets operating.

I'll pack up my demonstration of this here in a bit, but making a test setup to verify my results is fairly trivial.

And yeah... I am aware that currently, LuaUI treats user LuaUI like everything else, in terms of how the Lua works. It's all just Lua, to the Lua interpreter.

However, the VFS structure is not the same, and that's where the problem is.

There are files called from the MOD_LUAUI directory, and BASE. It seems really intuitive that you'd just cut out BASE, and voila, everything would be all right. However, that doesn't seem to actually work. I'll try something here in a bit- maybe I can gut the loading process for BASE, and if I add in enough from LuaUI... I don't think that will work, but what the heck, I'll try anything if I think it might work...

What I'm trying to make clear is that MOD_LUAUI does not cover multiple VFS locations- i.e., it only calls the originating mod that has LockLuaUI.txt in it, when tested.

And all I want, really, is for VFS to return an empty container for BASE, and then to operate normally- just bypassing BASE/LuaUI/Widgets, which is where third-party add-on LuaUI gets put. That way, using cheating Widgets is pretty difficult.

[quantum]

lockluaui.txt just makes LuaUI load the mod gui.lua. We tell CA's gui.lua to load user widgets (through cawidgets.lua), but you can tell it to do otherwise.

[dizekat]

lockluaui.txt just makes LuaUI load the mod gui.lua. We tell CA's gui.lua to load user widgets (through cawidgets.lua), but you can tell it to do otherwise.

What again stops me from simply renaming lockluaui.txt to something appropriate?

[lurker]

I just put Luaui/Widgets and nothing else in a mod with this modinfo:
[code][MOD]
{
name=Complete Annihilation widgets-2757;
description=Complete Annihilation;
shortname=ca;
version=widgets;
modtype=1;
numdependencies=0;

[NTAI]
{
tdfpath=CA;
}
}[/code]
The rest of CA I gave this modinfo:
[code][MOD]
{
name=Complete Annihilation base-2757;
description=Complete Annihilation;
shortname=ca;
version=base;
mutator=;
modtype=1;
numdependencies=3;
depend0=springcontent.sdz;
depend1=otacontent.sdz;
depend2=tatextures.sdz;

[NTAI]
{
tdfpath=CA;
}
}[/code]
Then I made an empty mod with nothing but this modinfo:
[code][MOD]
{
name=Complete Annihilation combo-2757;
description=Complete Annihilation;
shortname=ca;
version=combo;
mutator=;
modtype=1;
numdependencies=2;
depend0=ca-base.sdd;
depend1=ca-widgets.sdd;

[NTAI]
{
tdfpath=CA;
}
}[/code]
Then I loaded up CA-combo, and had all widgets available.

I opened CA's copy of widgets.lua, and commented out:

Code: Select all

-- stuff the raw widgets into unsortedWidgets
  local widgetFiles = VFS.DirList(WIDGET_DIRNAME, "*.lua", VFS.RAW_ONLY)
  for k,wf in ipairs(widgetFiles) do
    local widget = self:LoadWidget(wf, false)
    if (widget) then
      table.insert(unsortedWidgets, widget)
    end
  end

And only the widgets in the ca-widgets archive loaded.

[Argh]

Lemme test that tonight.

If it can be done like that, then great, problem solved. This issue has been driving me up a wall for the last two days

[Argh]

Didn't work, at least on this end. Meh, I'll look at this again after RC2 has been released, I'm probably just not configuring something correctly, if it's really that easy.

[Hoi]

what do you want to lock?