Can Gideros Run lua file not present in the project folder

bysreg

Just like the title says,

for example, im trying to create a platformer game with many levels. After that, i want to add more levels to the game, without having the user to download all over again the game. So, i was thinking, when the game starts, the game checks to server for any new released levels, and when there's one, download it and miraculously, the game has new level. in short, can gideros run .lua file from external file(something that's exist only after development)?

i'm new to lua and sorry if its a noob question

thank you

MikeHart

yes should be able too. Gideros has not restricted it's Lua implementation and you should be able to download a lua file, store it and then run it.

bysreg

thank you

more question,

do you mean loadfile? functions thats defined with loadfile, will it pollute the global namespace?

techdojo

Unless you ever want to submit to Apple, downloading "level data" is one thing, however downloading and excuting code is a fast route to "rejectsville"

atilim

@bysreg loadfile load the file as a separate chunk and returns the compiled chunk as a function. If you don't call the returned function, loadfile doesn't change/execute/pollute anything. If you call the function, any global variables inside the chunk are put into the global namespace.

For example, create a new project. Add test.lua to the project and exclude it from automatic execution (right click test.lua > Exclude from Execution) and put this content into it:

-- test.lua local a = 10 b = 20

Add main.lua to the project and put this content into it:

-- main.lua local func = loadfile("test.lua") print(a, b) func() print(a, b)

When you execute this program, you should see:

nil nil nil 20

When you load the chunk, none of these variables are created. When you call the compiled chunk, local variable a is created but you cannot access it and global variable b is created.

Hope this helps.

bysreg

@techdojo oh no. we want to submit it into iOS too..

@atilim thank you very much!!

techdojo

Check the App store review guidelines.

2. Functionality.
2.7 - Apps that download code in any way or form will be rejected

Codea has been falling foul of this since day 1, it's been a constant cat and mouse game to try and get round this kind of restriction.

gorkem

A small addition: Apps that are "uploaded code" are also rejected (like, Gideros Player)

techdojo

Interesting note - The AGK system also includes the source to the player (like Gideros) , they DO have a "viewer" app in the store, but it only got accepted as it actually streams video to the device whilst your PC does the "heavy lifting".

Still if you've got a Mac and a developer account it's not too much of an issue.

gorkem

It's indeed a nice solution, but looks like a workaround to me in fact. I asked that point to an Apple employee and he said "no way, sorry". So we didnt bother to send the Player to Appstore. Well even if we did, we had to update it on every release. Not much of a burden, anyhow.

techdojo

IMHO The current solution works much better and besides if your serious about iOS development then you'll have a Mac and an Apple account anyway so it's not a problem.

Also - the existing plugin architecture wouldn't work, you'd have to find another way to handle that.

jack0088

... and if you would want to try out Gideros Player without apple subscription on a jailbroken device, there are a view tutorials on how to fake or ignore the codesigning process :P
.... just thinking loud :-\"

bysreg

@techdojo by AGK, do you mean this http://www.appgamekit.com?
well, it seems i have to find other solution. just for curiosity, how does apple check that?

MikeHart

@bysreg: They don't need to check it. When you publish an app it uses the same method like Gideros does. Or Game Maker Studio. They all use a player app which has the runable code inside they document directory and they load it at startup time. It is all the same with all these tools. And you need to compile this project yourself in Xcode to get a file that you can submit to Apple.

They differ a little in the way the player apps work when you develop with them. And the only one that has an extra viewer app in the appstore is the AGK. But that is just a viewer with the ability to send back the input to your desktop computer. It displayes screenshots and is much slower as a normal running app. But they deliver a player project that you can compiel and install just like Gideros does. The Gideros Player waits actively in the local lan and then the IDE transmits the resources to it. The Game Maker player monitors a local webserver and reads its content when you publish a game to the webserver from Game Maker Studio. But this is all done on the local lan and for development only. Like I said before, when you publish your final app, it is a XCode project with a player app and with embedded resources (code, sounds, images). And that goes for all of these tools.

bysreg

@MikeHart
I see. well what i meant for other solution is for the loadfile. i think i'll stick with gideros for our following game. stay tuned it's gonna be a great game(but sadly not free )

techdojo

@bysreg - to be honest I'm not sure. The review process is (to my understanding) part automatic (they have tools that analyses the code looking for calls to private API functions and other things) and part manual - if a reviewer sees that option to download stuff in your app then they might check further, if they think it downloads code then they just press the reject button.

As I said before, downloading level data will (should) be fine as it doesn't contain any executable code, if your level data is stored in lua tables then just export them to JSON and download them as text and re-encode them locally. Ideally your app should already contain all the functionality to support any gameplay elements in the new levels, if not just release an update to your app that does BEFORE releasing new levels.

Dale

@atlim - please tell me that loadfile() isn't accessible (or is stubbed out) from the Xcode project, or at least restricts loading to files in the gideros studio project.

Otherwise, if it just relies upon each developer's honor, I could see Apple getting pretty cranky with gideros apps and the potential of running dynamic code... Having gideros apps banned would be a very bad thing...