Codea Runtime Questions

Ok I got Minesweeper working in the Xcode simulator. Before I write the next part of the tutorial I just wanted to get the collective knowledge of forum. If there are known issues I would like to highlight them. To be frank this hasn’t been a particularly easy exercise and I want to determine if I am the problem and just can’t read instructions.

Here are my observations:

  1. I think the Runtime supports dependencies (there is an array item in the info.plist) but I couldn’t get them to work. I wasn’t sure where to copy the dependency library. I tried sticking it in the same location as Project.codea using the same technique (“Copy items into destination folder’s group (if needed)” and “Create folder references for any added folders”) but the classes didn’t seem to get copied across. I also tried manually editing the Buffer Order array and copying the dependent Lua files across into the Project.codea folder but that didn’t work either. This issue is probably related to the one below on copying the project files but in the end, to remove this as a variable I deleted the dependency and copied the classes into the main project. Now I have it working, I could try again with dependencies but if anyone has done this already I would welcome their input.

  2. If you use custom drop box images then after step 1 (in these instructions: https://github.com/TwoLivesLeft/Codea-Runtime) you need to copy across your Dropbox.spritepack folder (using iExplorer it is in Apps → Codea → Documents) and place it in the SpritePacks folder in the project created by running the script. You will see the other standard spritepacks in the same location. To save space you could delete the images you don’t use in this App from the copy of your Dropbox.spritepack folder. Although it is common sense I would suggest adding this step to the runtime readme on GitHub.

  3. Then things got a bit tricky. Having sorted out the above when I tried to compile and run the Codea Template with the Minesweeper project replacing the default, Xcode crashed with a mighty:

Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[__NSCFNumber isEqualToString:]: unrecognized selector sent to instance 0x8a54770’

The error is shown as occurring in main.m, but this is just symptomatic of the real issue. I tracked the problem down to the following code in the CodifyAppDelegate:

//If there was an error copying it means we are upgrading the project rather than just installing it,
//So we need to ask the user what to do.

    if(![[NSFileManager defaultManager] copyItemAtPath:path toPath:destPath error:&error])
    {
        if(![self migrateProjectAtPath:path toPath:destPath])
        {
            NSLog(@"Error migrating project");
        }
    }

The first thing I checked was the source and destination paths. On the simulator these are:

DS DEBUG:: Path: /Users/dsuch/Library/Application Support/iPhone Simulator/5.1/Applications/24948B5F-BE37-4208-8FA9-1B59C18B39A7/Minesweeper.app/Project.codea

DS DEBUG:: Destination Path: /Users/dsuch/Library/Application Support/iPhone Simulator/5.1/Applications/24948B5F-BE37-4208-8FA9-1B59C18B39A7/Documents/Project.codea

which I compared with the working default project and they looked the same (apart from the different app name). I then commented out if(![self migrateProjectAtPath:path toPath:destPath]) and this got most of the lua files loaded and then crashed because it didn’t load all the classes. Consequently, NSFileManager must be returning an error when it tries to copy the files. So I suspect I haven’t put Project.codea in the right spot, but I have followed the instructions and I’m not sure what else to try.

I then just manually copied the missing classes into the destination path above and bingo - the app compiled and ran in the simulator.

  1. A couple of more minor issues, the TextBox class (from Spritely) doesn’t seem to render in the simulator, but it works ok apart from that. I also couldn’t get the App to run back on the iPad from Xcode, even though it worked in the simulator ok. Are there any known issues with this? I tried the default project and that didn’t work either (and then checked with one of my other apps and that was fine).

  2. Anything else I need to know?

  1. The runtime doesn’t support dependencies. This will require changes to build script and execution environment. For now you’ll have to package your dependencies into one project, with your main project.

  2. Good point, we should add that to the Readme.

  3. Not sure what is going on with that crash — it sounds like a bug in the way the runtime is migrating the project.

I have narrowed down the crash to the following line in the CodifyAppDelegate - (NSString*) versionForProjectAtPath:(NSString*)path method:

NSString* version = [infoPlist objectForKey:@"Version"];

Looking at the default Dungeon Roller project, the info.plist file included in the Project.codea folder does not have a Version key. The Minesweeper one does (which is set by the saveProjectInfo(“Version”, version) command). So the code above is trying to assign a Number to a string. I tried changing the info.plist type for Version to a string but that didn’t help.

What fixed it was replacing the above line with:

NSString* version = [NSString stringWithFormat: @"%@", [infoPlist objectForKey:@"Version"]];

Alternatively, you could tell folks not to use the Version key. Thoughts?

@Reefwing odd that it didn’t help when you changed the Version data type to a string in the project’s info.plist (though it would have had to be changed on the old and new projects).

I think that our code needs to be written more sensibly. We were actually hoping people would modify the project migration code to suit their needs — what is in there now is what we used for Cargo-Bot, and won’t suit everybody.

You could also do:

NSString* version = [[infoPlist objectForKey:@"Version"] description];

Which is what your stringWithFormat line does, in terms of results.

Thanks @Simeon - I think people who understand Xcode and Objective C will modify the migration code to suit their projects. However, Codea is a great entry point for new coders who may not have this experience so ideally the runtime needs to be bullet proof.

I would have a go at a more robust version - except I don’t really understand how it works (particularly how you are running Lua code within Objective C), and reverse engineering it would be a big effort. I’m having enough trouble trying to debug Lua code running within Xcode (see thread: http://twolivesleft.com/Codea/Talk/discussion/1501/3d-doesn-s-work-on-a-real-ipad#Item_3).

If I suddenly get some free time I might have a shot, in the meantime, maybe some other gun coder will step up? :slight_smile:

You are correct about the plist issue. I didn’t go in and change the old projects version type.

Reefwing, perhaps one bit you can add to your tutorial is how to make sure custom sprite works in iphone/ipad apps.
For me, the tutotial works fine to get apps running with custom sprite on xcode->iphone simulator, but doesn’t load the custom doprbox sprites for ad hoc /commercial distribution.

I followed your other post on commenting out the version check in CodifyAppDelegate.m and then it worked.

Hi @zapaper - I did insert an update on this into the tutorial (http://codeatuts.blogspot.com.au/2012/08/tutorial-12-submitting-to-app-store.html) just below Figure 3b.

Is this what you mean?