Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

How to update to the new runtime [follow up on Codea + Xcode's asset issue]

edited October 2015 in Questions Posts: 277

Hello all,

A few of us have been experiencing issues with submitting Codea projects with the Xcode 7 and its new assets-naming system (which happens to be the name currently used by Codea...) @Simeon has been working hard to promptly get us a new runtime which deals with new asset names, whoever, for people like me who exported their project a long time ago, things aren't as easy, as we need to first update our projects to be up to date with the current runtime (before applying Simeon's fix, that is).

I've had (I still haven't resolved them, actually) issues updating my project, and, since I might not be the only one, I was thinking we could make a step-by-step of the process.

Here's what I think I know:

  • On iPad, export a new, dummy project from the latest version of Codea
  • Open this dummy project's folder on a Mac and replace Libs/libcodea.a, Libs/libtools.a, Libs/RuntimeResources.bundle, Libs/ToolsResources.bundle in your current project by the ones from the dummy project
  • copy the libversion file from the dummy project's root folder to the current one

  • Convert your code to be Lua 5.3 compatible: make sure no floats are passed into math.random. If so, convert with math.floor(). Replace all "table.getn" with "#".

Then comes Simeon's tutorial on how to get this project ready for uploading on Xcode (verbatim from Simeon's instructions):

  • Find the file named libversion in the root of your exported project. It will contain a version number, most likely 2.3.1. Change it to 2.3.2
  • Delete libcodea.a and libtools.a from your Libs/ folder
  • Delete the "AssetPacks" folder reference from the "Resources" group in your exported Xcode project — if Xcode asks you to move the files to trash say NO.
  • In Finder: rename the "AssetPacks" folder to "Assets"
  • In Finder: Rename every "SomePack.assetpack" folder within it to "SomePack.assets"
  • Drag the root level "Assets" folder back into Xcode, tell Xcode to add this as a "Folder Reference" (not a "Group")
  • Build and test your project
  • Archive your project

@Mark adds:

  • Open RuntimeResources.bundle and ToolsResources.bundle and remove the Executable File string from info.plist

  • Dealing with multitasking. Unless your Xcode changes include a storyboard, the easiest way is to select the "requires full screen" option

Just to make it clear, this didn't work for me, as I think I'm missing steps at the "(...)"). I'd really appreciate any help on filling the gap...

Cheers!

Comments

  • @Rodolphe my suggestion: export from Codea your project on Mac, after, copy the 'old' code into the 'new' project.

  • Posts: 2,020

    This is probably a stupid question, but how come you're exporting a dummy project? (As in, why not re-export the actual project you're wanting to post to the App Store?)

  • edited September 2015 Posts: 277

    @yojimbo2000 Because that project was first exported more than a year ago, and all updates have been since made in Xcode. I'm guessing I'm not the only one doing this, am I?

    @Erickyamato Oh I see, so I should do the opposite than what I'm trying to do... I', try thins, thanks

  • edited October 2015 Posts: 216

    Probably too many screenshots, bundle ids, icons, launch images and screens etc to deal with, I'm guessing it's most likely easier trying to edit your project in xcode then to deal with that.
    EDIT: never mind, looks like you've awnsered it, and by the timestamp looks like we posted at the same time :)

  • Posts: 2,020

    Isn't this what version control is for? Turn on Xcode's version control, drop the fresh export into the folder, let Git worry about what's changed.

  • Posts: 1,255

    Note that while the steps above will get you to archive, you won't be able to submit the app.

    You'll also need to open RuntimeResources.bundle and ToolsResources.bundle and remove the Executable File string from info.plist

    Finally, you'll have to deal with multitasking. Unless your Xcode changes include a storyboard, the easiest way is to select the "requires full screen" option

  • edited October 2015 Posts: 277

    @yojimbo2000, can version control actually do that? I need to learn about this... :( Is there any free and private git around (I'm guessing this is too much to ask but well :) )?

  • Posts: 2,020

    Bitbucket lets you have free private repositories. Turning on Git in an already existing Xcode project is a little tricky, but there are plenty of guides if you google.

  • Posts: 2,020

    @Rodolphe thank you for posting this guide, @Mark thanks for the extra steps. I haven't tried following them yet, as I'm not ready for verification yet, still just experimenting with putting apps onto the phone. But I'm sure I will be working through these steps soon.

    @Rodolphe I was oversimplifying, and probably not being very helpful, sorry. I guess where Git can help here, is it can do a three-way merge between the new export from Codea (branch2), your current Xcode project (branch1), and the two branchs' common ancestor, which would be the file you originally exported and started working on in Xcode (although, if you've not used Git so far, then the repository won't know what the starting point was. Do you have your first export file somewhere, before you started making changes in Xcode? This might be a good place to start the repository with.)

    The merge would produce conflicts in those situations where the same lines of code have been changed in different ways on branch1 and branch2. For the areas of conflict, you can resolve them on a file-by-file, or a line-by-line basis (you choose go with branch1's version of this file/these lines; or go with branch2's). I've no idea how many conflicts this approach would produce. I should stress that I'm still very much a Git beginner, and you might no find it helps you much! Or rather, it presents you with a new set of problems.

  • edited October 2015 Posts: 277

    Thanks @yojimbo2000, I think it's probably too late for this project then...

    So, in my list, there is at least one important thing missing: conversion to Lua 5.3...

    I still can't get my old (pre Lua 5.3) project to work with the new runtime...

    I've tried two things:

    • In Xcode, I put my old project's Lua code into a dummy project freshly exported from Codea's latest version, and I end up with a bad crash:

    altText

    • I also transferred all my old project's code to my iPad via AirCode, and Codea crashes.

    I'm thinking, maybe there is some changes to Lua 5.3 I should take into account. Is there a list of changes somewhere?

    Thanks!

  • Posts: 277

    Cool, thanks, I'm converting all the math.random(float,float)... So many of them...

  • edited October 2015 Posts: 277

    Ok, thanks to you guys (including @Simeon), I think it's going to work. I'm going through tons of bugs, but it looks like it could work, thanks!

Sign In or Register to comment.