Spring RTS Engine

I have seen a couple options on these forums to disable user luaui. I have seen multiple references to lockluaui.txt, so I was wondering how one uses this file to prevent user luaui.

You put a file by that name in gamedata, and then it'll load luaui.lua from the game rather than the spring folder. From there you can do whatever, normally you put in copies of the luaui files and either alter them to only read from the archive, or you use the luaui.lua file to replace all loading calls to be archive-only.

This means, of course, that any UI advancement will have to come through you and thus you'll be pulling all of your significant lua inhouse, which is something that many projects lack the dedicated scripting developers to do.

Whats the big deal there? How can a project rely on the user to provide his own reliable lua interface for a game that has a completely different economy and gameplay than Total Annihilation?

It can't, and it shouldn't. I'm just saying, be prepared for the additional work load, comparative to most projects. 1944 will move to that model eventually, so I'm obviously confident in our ability to provide as well.

Sorry, i havent read the great spring lua tome (aka the source) all the way through yet. What files can i copy directly out of my luaui directory (dont talk about widgets I mean the stuff that makes the widgets run)

Meanwhile ill study CA and see what they did and compare the results of my search to the response of this forum.

The attached file is a minimal locked UI LuaUI installation, produced by Lurker, and includes lockluaui.txt. Pretty much just drag-and-drop into your project.

Argh you are infinitely helpful. Hugs and kisses and pie!

Though that version has a flawed luaui.lua, because I misread the spec. Replace line 19 with
VFS.Include = function(file, env) return VFSInclude(file, env or getfenv(debug.getinfo(2,"f").func), VFS.ZIP) end

lurker wrote:Though that version has a flawed luaui.lua, because I misread the spec. Replace line 19 with
VFS.Include = function(file, env) return VFSInclude(file, env or getfenv(debug.getinfo(2,"f").func), VFS.ZIP) end

getfenv(2) does the same and doesn't rely on debug library being available. (and is shorter etc. )

It gives an error in some circumstances, I believe. I really think I would have tried it.. Something about stack depth and tail calls? Not quite sure. It's possible I screwed it up. And I know, using debug is ugly and makes me sad.

Fixed version here, thanks!

Argh wrote:Fixed version here, thanks!

I fixed my version. Did u do anything else to it besides what lurker posted above?

Nope.

kthx

neddiedrow wrote:This means, of course, that any UI advancement will have to come through you and thus you'll be pulling all of your significant lua inhouse, which is something that many projects lack the dedicated scripting developers to do.

That's sort of a half truth neddie. The modmaker can still include lua for the user. Evo for example includes a massive list of the "Essential" widgets. Course evo isn't exactly locked, it's just set so that the lua included in evo gets loaded before the user's lua.

without even really trying to get all functionality I want I have already copy pasted (with alot of editing and merging and such) about 10-15 "essential" widgets, like custom formations and ally startboxes etc.

How can i delete stupid things like resource bars and the chat pane from luaui? Has anyone ever modified the chat input before? Examples/howto?

Forboding Angel wrote:modmaker ... include

neddiedrow wrote:come through you

Yes?



What, not even looking around at widgets that do that? It's also in cmds.txt.