file.Read() fails to read Lua files clientside when they do not truly exist clientside

[EstevanTH]

trafficstars

Hello robotboy and co,

I found a problem when trying to read Lua files. If the Lua file does not exist clientside (in general because of addon not mounted), the file can be found but it fails when attempting to read.

Here is my code to load vehicles Lua files with the minimum of problems regarding the startup Lua includes limit. It delays the load of Lua files and safely run every Lua script.

-- Run vehicles Lua scripts:
AddCSLuaFile()
hook.Add("PreGamemodeLoaded", "mr_vehicles", function ()
    local path = "mohamed_rachid/vehicles/"
    local succ,err
    for _,LuaFile in ipairs(file.Find(path.."*.lua", "LUA")) do
        local content = file.Read(path..LuaFile, "LUA")
        if isstring(content) then
            succ,err = pcall(RunStringEx, content, "lua/"..path..LuaFile)
            if !succ then
                ErrorNoHalt("\nlua/"..path..LuaFile..": "..tostring(err).."\n\n")
            end
            if SERVER then
                AddCSLuaFile(path..LuaFile)
            end
        else
            ErrorNoHalt("Unable to load lua/"..path..LuaFile.."\n\n") -- ERROR WITH file.Read()
        end
    end
end)

For people who have my addon mounted (SVN, Workshop or probably Workshop sent by the server), the Lua files exist clientside so the Lua files can be read. But for any Lua file that is sent by the server with no matching Lua file mounted clientside (not subscribed to the SVN and no usage of Workshop), then the Lua file cannot be read.

[sohpeach]

Use CompileFile. The decompressed contents of the Lua files don't actually exist anywhere on the file system so I don't see fixing this as necessary.

http://wiki.garrysmod.com/page/Global/CompileFile

[EstevanTH]

That is useful! Thank you. :smiley: Anyway it's too late, I chose to use include() when the file cannot be read properly, but I'm not sure that it will work if startup includes limit is over.

[sohpeach]

You're thinking of the CS Lua file limit? That limit is only for the amount of files which can be sent to clients by the server. Even with file.Read, include or CompileFile you'll be limited by the limit.

One issue with your file.Read system would be people (and people do abuse these systems) using it to get past sv_allowcslua.

[EstevanTH]

Nope, the problem that breaks includes (of internal stuff as well) after a given number of Lua files included. This is called the "too many addons" bug.

EDIT: Also, thank you for the info, I need to fix that finally...

[thegrb93]

Just hit this problem myself. Luckily I can network the files pretty easily.

[thegrb93]

Done... but file.Read would be a lot faster.

[govigg]

So yeah, we've got CompileString, but what when i want to read file contents instead of compiling it into lua function?

[thegrb93]

You can't, devs apparently don't want clients reading server's client code; (pretty sure there's workaround for this anyway though).

[govigg]

It's very simple outside of lua, secondly, if file.Exists returns true for these files, does the file actually exist or not?

[Grocel]

I mean, if nobody requested it in like 10 years, probably nobody wants it.

So Rubat, it looks like someone did, huh? (For context: #5719)

[garryspins]

Bump, a way to read them from the vfs (maybe a new function outside of file.Open) would be much appreciated and doesn't seem like it'd be too difficult to add. There's more reasons to have this than not, CompileFile doesn't fill every edge case especially for runtime code modification.

Another alternative would be allowing to send arbitrary (processed on the server) lua in place of AddCSLuaFile although that's a much tougher sell overall.

[robotboy655]

Just curious, what's the "reasons" to have this?

[garryspins]

Biggest one? Runtime preprocessors. Right now this is very possible sure, but with one big limitation. You cannot send processed code before Player initialization.

You cannot net.Send to an uninitialized player so there goes using that to send preprocessed code. You cannot read AddCSLuaFile'd files so there goes that for handling it on include. You cannot modify the stream sent by AddCSLuaFile so there goes that for handling it on the server.

Something has to give for this to be done properly.

Smaller one? Its just something that people expect to work. Things like file.Time and file.Write make sense to not work for the vfs, noone expects that to work, but reading AddCSLuaFile's is something that is expected to work.

Smallest one? Code analysis on the client.

tl;dr, This would enable abstract metaprogramming for the client AND server at runtime!!! If that isn't cool I don't know what is. Please just take half an hour and add this, even if you make it so the read files are still compressed (although neglects the 2nd point) we could find a way to decompress them ourselves, just something to make this work.

[garryspins]

Any update on this? Real curious to hear what you think

[Grocel]

Any update on this? Real curious to hear what you think

I wouldn't wait for this, I guess. Maybe Rubat will make it pass another 10 years. He is quite busy. 🤭

[garryspins]

10 years busy sounds a bit light, lets try 15.

[garryspins]

bump, really need this.