[Solved] Running a file from a string

[laperen]

Sorry if this has been asked before, but I had a hard time finding an answer.

I'm trying to run a file from a string representing the file name. so far I've looked at using love.filesystem.load, but it has not worked

what I hope to achieve is something like this, pseudocode

my current target lua file setup is something like this

Code: Select all

ObjName = {}
function ObjName.new(args)
	local self = {}
	--do stuff with args
	return self
end

and I hope to call it with another lua file like this

Code: Select all

Loader = {}
function LoadFile(args)
	tempObj = load("filename")
	return tempObj.new(args)
end

has anyone achieved this before? and if so how was it done? thanks in advance

[Tjakka5]

Have a look at loadile and loadstring:
https://www.lua.org/pil/8.html

That said; why do you want to load the file yourself, and doing thing with it; instead of just requiring it?

[laperen]

Coming for a unity background I've gotten used to the idea of scenes
I'm using CSVs to store my "scene" data. I've gotten to a point where i can read the lines of the CSV as strings
One of these is the object I want to create, where I intend to use the name of the file to create it
which leads to my current predicament

I'll definitely be taking a look at the link you provided, will post an update on any progress I've made

Also with that said, is this a good or bad approach? or is it a preference kind of thing?

[ivan]

I'm using CSVs to store my "scene" data. I've gotten to a point where i can read the lines of the CSV as strings

You're loading data, right?
Your "data" should never be Lua code.
Otherwise you lose the separation between code and content/data.
It sounds like you need a better format of storing your content/data.

PS. The reason why you this separation is important is because,
you want to be able to change the code (which runs the game)
without modifying your content (for example: level files).

[laperen]

I'm using CSVs to store my "scene" data. I've gotten to a point where i can read the lines of the CSV as strings

You're loading data, right?
Your "data" should never be Lua code.
Otherwise you lose the separation between code and content/data.
It sounds like you need a better format of storing your content/data.

I'm not very clear of your reply
CSV is Comma Seperated Values, which represents stuff in a semi tabular form. It is not lua code.

So far the data I'm storing in my CSV is
- the object
- and its position.
Intending to add additional stuff like scale and color eventually.

One of the elements I'm storing in my CSV is the object name which I intend to use to load the actual Lua script describing the object's properties and behaviour

I'd be happy to hear of proper or alternative ways to doing what I'm trying to achieve because I know full well this probably isn't ideal.

[ivan]

You can store the type of the object as a string, then use that without "loadstring".
object.lua:

Code: Select all

local obj = {}
function obj.new(x, y)
   local self = {}
   ...
   return self
end
return obj

loader.lua:

Code: Select all

objects = {}
function createObject(type, ...)
  -- just an example, alternatively, you can load all objects when the game starts
  objects[type] = objects[type] or require("path.to.file."..type)
  return objects[type].new(...)
end

CSV is not a great format if your objects.new functions accepts different parameters.

[s-ol]

You're loading data, right?
Your "data" should never be Lua code.
Otherwise you lose the separation between code and content/data.
It sounds like you need a better format of storing your content/data.

I strongly disagree. Many types of content are not suited to be represented in Lua code (for example images, audio), but a lot are. In a lot of cases, lua code is a great serislization target/format, loading a lua module that returns a table is one of the fastest means of importing data that is generated internally or externally (but not manually; think data from level editor like tiled or ingame level saves). It is also great because the data storage format matches the runtime format so there are no gotchas (like with json: handling undefined/null vs. nil, number-indexed dictionaries, "sparse arrays") AND you get all the flexibility of a programming languages, like assinging data to a variable and reusing it in the return table instead of redundantly declaring things.

Another Awesome use case is having hand-written content in Lua (like Dialogues). There's a recent thread about it somewhere and i just build sth similar myself recently; a lua script beats a json dialogue file in so many ways IMO. you get to trigger and query and interact with the game world on any level instead of building a crazy data format capable of covering all your cases and you can be dynamic and reuse code from other dialogues, write helper functions to shorten it, even write a data-description DSL for example.

[ivan]

I strongly disagree. Many types of content are not suited to be represented in Lua code (for example images, audio), but a lot are. In a lot of cases, lua code is a great serislization target/format

I agree as long as the serialized file only contains tables, numbers and strings.
If your serialized file contains functions (or function calls), then it's no longer "pure data".
It's not a big deal for smaller projects,
but a clear separation between code and content is a good coding practice in my opinion.

[laperen]

--UPDATE--
Apparantly, this fits my purposes
target file

Code: Select all

ObjName = {}
function ObjName.new(args)
	self = {}
	--do stuff with args
	return self
end
return ObjName

loader

Code: Select all

Loader = {}
function LoadObject(objName, args)
	local temp = require("folder/"..objName)
	return temp.new(args)
end

thanks for the input all.
Want to thank Tjakka5 for the idea. I didnt quite get the idea behind what you said until I put an ounce more thought into it and tried it out.
Turns out I was missing the "return" line at the end of my target file, causing "require" in the loader to return a bool instead of a table.

[s-ol]

I strongly disagree. Many types of content are not suited to be represented in Lua code (for example images, audio), but a lot are. In a lot of cases, lua code is a great serislization target/format

I agree as long as the serialized file only contains tables, numbers and strings.
If your serialized file contains functions (or function calls), then it's no longer "pure data".
It's not a big deal for smaller projects,
but a clear separation between code and content is a good coding practice in my opinion.

Still, sometimes code is content. Things like dialogue or behaviour (-scripts) can be written very clearly, nicely and succinctly that way IMO.

For example my last project was a point and click; everything intractable is a script that gets passed the layer data. There is an importable function that turns a dialogue coroutine into a clickable dialogue with walk-to animation, text output layers and a character talk/idle animation. That fits 80% of the interactions, but some differ; sometimes theres no walk-to, sometimes the walk-to is after thr dialogue, sometimes theres no character there that would have an animation change etc.

To cover one of these cases I just do the same things the function above does, with the necessary changes and specifics the case requires.

I would definetely call these scripts content since they are even loaded from within the level file and tied to a specific part of that. The scripts often contain actual logic and I don't even want to think about how my dialogue-engine Interface would have to look like to accomodate all it needs to cover if my data was "pure data".

I can see that one might disagree with writing logic and defining functions, but function calls are immendly useful as data-transformers (aka DSL) to make writing he data less repetitive and error-prone.