Author Topic: Scripting file access  (Read 3057 times)

0 Members and 1 Guest are viewing this topic.

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
im somewhat concerned about the directories scripting likes to work out of. its always the base fs2 directory for one, meaning you need to strictly enforce mod directory names, if you want to be able to get at files saved in the mod dir. its also not a user writable area. we need access to files in mod, player, and fs2path directories, for whatever file access is called for. files that are read only and store mod specific data is best located in the mod dir, files that store user settings are not. its entirely possible to create menus that configure scripted controls, on any screen in the game and saved to file, and im sort of concerned about file permissions. wouldn't mind having input management for scripting built into the game and save data to the pilot file or some other file, so we dont have to really be concerned with permissions.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Zacam

  • Magnificent Bastard
  • Administrator
  • 211
  • I go Sledge-O-Matic on Spammers
    • Steam
    • Twitter
    • ModDB Feature
im somewhat concerned about the directories scripting likes to work out of. its always the base fs2 directory for one, meaning you need to strictly enforce mod directory names, if you want to be able to get at files saved in the mod dir.

Uh....what? I have scripts no where in my main FS2 data dir, but I do in my Testing mod (which I use for explicitly loading my custom content when testing stuff, so that I can also test it WITHOUT said content without having to go through and move things. Example's: removal of the 2D Radar image so that 3D Orb is clean, HUD Escort Script, Velocity Script, Shield Management Script and Mouse Script)

What you CAN'T do is have PART of a script (or the main TBM for the mouse script) in MOD-A tables dir and the CFG file in MOD-B's config dir.

If MOD-B wants to engage the mouse script, then it should include the mouse script. Though, I can admit that just being able to deliver the CFG might be sweet, this is just one example.
Report MediaVP issues, now on the MediaVP Mantis! Read all about it Here!
Talk with the community on Discord
"If you can keep a level head in all this confusion, you just don't understand the situation"

¤[D+¬>

[08/01 16:53:11] <sigtau> EveningTea: I have decided that I am a 32-bit registerkin.  Pronouns are eax, ebx, ecx, edx.
[08/01 16:53:31] <EveningTea> dhauidahh
[08/01 16:53:32] <EveningTea> sak
[08/01 16:53:40] * EveningTea froths at the mouth
[08/01 16:53:40] <sigtau> i broke him, boys

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
its not so much about the location of the scripts but rather the locations of files that scripts can be made to read and write to. for example the config file of the mouse script.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Zacam

  • Magnificent Bastard
  • Administrator
  • 211
  • I go Sledge-O-Matic on Spammers
    • Steam
    • Twitter
    • ModDB Feature
its not so much about the location of the scripts but rather the locations of files that scripts can be made to read and write to. for example the config file of the mouse script.

And by changing:
Code: [Select]
filename_mouse = "mouse_script.cfg"
boolmousefileOK = cf.fileExists(filename_mouse, "data/config/", true)

to something like:
Code: [Select]
filename_mouse = "mouse_script.foo"
boolmousefileOK = cf.fileExists(filename_mouse, "data/sponge/", true)

I can place it in a "sponge" directory if I feel like it, so it's not like it is hard-coded behaviour.
« Last Edit: February 07, 2011, 01:58:07 am by Zacam »
Report MediaVP issues, now on the MediaVP Mantis! Read all about it Here!
Talk with the community on Discord
"If you can keep a level head in all this confusion, you just don't understand the situation"

¤[D+¬>

[08/01 16:53:11] <sigtau> EveningTea: I have decided that I am a 32-bit registerkin.  Pronouns are eax, ebx, ecx, edx.
[08/01 16:53:31] <EveningTea> dhauidahh
[08/01 16:53:32] <EveningTea> sak
[08/01 16:53:40] * EveningTea froths at the mouth
[08/01 16:53:40] <sigtau> i broke him, boys

 

Offline Wanderer

  • Wiki Warrior
  • 211
  • Mostly harmless
FS2 file access is a tad odd occasionally. Via scripting that is. Normally you are limited to the current top most mod folder you happen to be using. Both for opening and closing files. However if the file in question is mapped by CFILE (details of which directories and which file formats are mapped are in the cfile code in the codebase) then it can be opened regardless of which mod directory it happens to reside in. Which was the main reason why i changed the script data files into .cfg (as .cfg happens to be mapped in data/config/ directory).

As for data and script being in different mods.. As long as they are properly cfile archived it should not pose any problems. Using custom file extensions and locations where to store them however would hinder their functionality.
Do not meddle in the affairs of coders for they are soggy and hard to light

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
i use my tbl parser to mod my scripts, and those custom tbls are loaded from the mod dir. problem there is that the mod dir needs to be what the script expects it to be, otherwise the files are not found and not used. but that was not my concern, as that can be idiotproofed with an installer. my concern was more about write permissions. for example if the data/config/ directory was in the fs2 folder, which in turn was in a non-writable location. would that not hinder the script's ability to carry out a successful save.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Wanderer

  • Wiki Warrior
  • 211
  • Mostly harmless
Just run a test... i mod a dummy mod directory as 'bug_testing/scripting' into which i placed a mod.ini - and nothing else - which pointed to mod directories as follows: scripting\sct_clean_mouse,... which was the directory where i placed the mouse script which i used for this example

And i added following little bit into the mouse script for this purpose only...
Code: [Select]
odd_file = cf.openFile("test_drive.uuga", "a", "data/config/")
odd_file:write("MY BAD, My bad...")
odd_file:close()

And as I expected the new file - test_drive.uuga - was written to 'bug_testing/scripting/data/config/' (though that directory had not previously existed) and contained ASCII string of "MY BAD, My bad...". So as far as i can see it writes exactly where it is supposed to write the data.

Tested both with dummy extension as well as with mapped extension (.cfg). Both worked fine.

Now.. Continued testing... i deleted the existing test_drive.cfg files and placed test_drive.cfg to scripting\sct_clean_mouse\data\config with content of
Code: [Select]
Now the catch...
MY BAD, My bad...
Modified the script to
Code: [Select]
is_even_file = cf.fileExists("test_drive.cfg", "data/config/", true)
if is_even_file then
even_file = cf.openFile("test_drive.cfg", "r")
odd_file = cf.openFile("test_drive.cfg", "a", "data/config/")
odd_file:write("MY BAD, My bad...\n\n")
odd_file:write(even_file:read("*a"))
odd_file:close()
even_file:close()
ba.warning("SCAMPER FER YER LIVERS!!")
end
And as a result the old file stayed as it was in the sub mod directory (scripting\sct_clean_mouse\data\config) while the new one in bug_testing\scripting\data\config contained following
Code: [Select]
MY BAD, My bad...

Now the catch...
MY BAD, My bad...
Exactly as it was supposed to. All new data goes to the current top or 'working' mod directory while mapped data may loaded from elsewhere keeping in mind the usual load priority order. All that needs to be remembered is that data is saved only to working mod directory. Of course it should be noted that using identically named files is a recipe for devastation as the next time you start game would map the new file into the cfile archiver and use it instead of the original one now hidden beneath the higher - in load order - ranked file.
« Last Edit: February 07, 2011, 04:04:32 am by Wanderer »
Do not meddle in the affairs of coders for they are soggy and hard to light

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
got your pm and i didnt realize this got split out. i thought it got buried in the mouse thread.

many times someone will want to mess around with one of my super scripts on my svn server and wont be able to get it ruining because they will try to use a mod that i did not account for, and files will fail to load because the working directory is somewhat different that the scripts expected. most of the files read are not user files and are typically in a predictable location. i figure somewhat smarter cfile access script is in order, which would remedy most of these error reports. 

neither script attempts to write to any location, though im somewhat interested in using my gui script to allow in-game configuration of input options. this is where i have concerns. many users these days do not run as an administrator. say you were running win7, as an underprivileged user, and freespace was installed in a typically non-writable locations like program files\games\. and say freespace ran a script that wanted to write anywhere in the fs2 directory structure. wouldn't the os try to stop that write throwing some kind of access denied error?
« Last Edit: February 10, 2011, 09:51:42 pm by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Iss Mneur

  • 210
  • TODO:
many times someone will want to mess around with one of my super scripts on my svn server and wont be able to get it ruining because they will try to use a mod that i did not account for, and files will fail to load because the working directory is somewhat different that the scripts expected. most of the files read are not user files and are typically in a predictable location. i figure somewhat smarter cfile access script is in order, which would remedy most of these error reports. 
It should be relatively simple to write a lua wrapper of the games cfile system, the important calls are in cfile.h (which may be what Wanderer was using with the 'cf' object, though).

neither script attempts to write to any location, though im somewhat interested in using my gui script to allow in-game configuration of input options. this is where i have concerns. many users these days do not run as an administrator. say you were running win7, as an underprivileged user, and freespace was installed in a typically non-writable locations like program files\games\. and say freespace ran a script that wanted to write anywhere in the fs2 directory structure. wouldn't the os try to stop that write throwing some kind of access denied error?
This concern is not specific to lua.  Lua gets around the issue in the same way that FSO gets around the issue for where to write the model cache and the pilot files.  Vista and 7 provide compatibility layers or we just tell people "don't install FSO into Program files".

This issue is known to SCP and actually rather well hash out on at least one occasion, however I have not had the time to work on the FSO platform interaction.
"I love deadlines. I like the whooshing sound they make as they fly by." -Douglas Adams
wxLauncher 0.9.4 public beta (now with no config file editing for FRED) | wxLauncher 2.0 Request for Comments

 

Offline Wanderer

  • Wiki Warrior
  • 211
  • Mostly harmless
As long as the files are in 'cfile mapped' directory with valid file extension in any one of the active mods (though not necessarily the working mod) there should not be any problems. Game will be able to find and read (though not write into them - so 'r' mode is a must) them regardless of where they have been placed.
Do not meddle in the affairs of coders for they are soggy and hard to light

  

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
k i think i figured out how to load "libraries" without having to know of an exact location of the lua files. this  replaces dofile() calls, which needs to know the way from root to where the files are in the mod dirs. it does this by using the cfile facilities to locate and open files independently of any known path. so essentially i load the lua code into a string. i then use loadstring to turn it into a lua chunk (which is essentially a code block). loadstring then returns a function that runs the block when called. to make things a little faster i made it so it only needs to read the file once, to generate the chunk function, and then it caches it into a table for later use.

i put the function at the head of the global init hook. i figure i can use it to chop up my script into manageable pieces and make things somewhat more modular, though its main purpose is to load libraries. id rather the scripting table had better facilities to load multiple files per hook. but this is a good interim solution. im still kind of concerned about cheating though. im not sure if script ran in this manor would get past anti-cheating checks if it were modified. i would assume those checks only apply to what is in the scripting.tbl and not lua files loaded by the table (and likewise lua files loaded by other lua files). something to think about anyway.

Code: [Select]
--function to load and run lua files
--takes string filename and boolean cacheonly
--cfile will try to find filename in all accesible locations and load it only if it hasnt done so already
--if cacheonly flag is set, code will be cached but not executed, good for inits. however it is ignored when calling an already cached chunk.
--returns true on success, false on failure to compile, or nil on failure to find/load file
chunck_cache = {}
function execute_lua_file(filename, cacheonly)
--dont reload chunks from file if they have already been loaded. because faster == badass
if chunck_cache[filename] then
chunck_cache[filename]()
return true
else
if cf.fileExists(filename, "", true) then
--open the file
local file = cf.openFile(filename, "r", "")
local fstring = file:read("*a") --load it all into a string
file:close()
if type(fstring) == "string" then
--use the string as a code chunk and convert it to function
local func, errorstring = loadstring(fstring, filename)
if type(func) == "function" then
--cache function
chunck_cache[filename] = func
--maybe execute
if not cacheonly then
chunck_cache[filename]()
end
return true
--compile error
elseif errorstring then
ba.warning("Error in '"..filename.."': "..errorstring)
return false
end
end
else --file not found error
ba.warning("File '"..filename.."' not found")
return nil
end
end
end


and all you have to do is call it with the name of the lua file you want to run

Code: [Select]
--call lua from file or chunk cache if file has already been loaded
execute_lua_file("somefile.lua")

--precache lua file for later execution
execute_lua_file("somefile.lua", true)

*edit: script updated for better error handling*
« Last Edit: February 14, 2011, 11:10:32 am by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN