Edit in Xcode loses non-.png resource

Elements Fire
1

I added a .png and a .sks for a particle emitter to a project. I then did “Edit User Interface Files in Xcode”. When I looked at the Xcode project, the .sks file was no longer in the resources. In VS, doing “Sync with Xcode” that same project generated a project where the .sks file was present as expected. (I also verified by looking at the project.pbxproj file inside the bundle that there was an entry for the .sks file in one case, but not in the other).

Looks like a regression in the Xcode-export code for Fire.

2

Fire and vs use the exact same sync code. Check that the build action is set correctly. Fire won’t know to set it for sks files by default.

3

OK? It’s the exact same project anyway. I opened it separately in each environment (not both at the same time, obviously).

4

Odd. i’ll have to test here, i guess.

5

Found and fixed for the next build — thanx!

6

I tested this again in the May 23 build. The Xcode project now correctly has the .sks file. However, when I edit the .sks in Xcode (changing the look of the particle emitter), save the Xcode project, quit Xcode and rebuild the Fire project, the particle emitter looks the same when I run the project as it did before I made the changes in Xcode. I’ve verified that the .sks file’s date indeed changes when I make the Xcode changes. Any idea what could be going wrong here?

7

Now I’m totally confused…I added a second .sks file and changed the code to load that one instead, and I still get the original emitter showing after rebuilding. It’s like Fire is running an older version of the compiled project but I don’t see how…

8

That’s definitely what’s happening. I changed physicsWorld.gravity in this small SpriteKit demo and there was no visual change when I ran it. Somehow what’s running after I build is a older version of the executable code. Can you suggest how I might track this down? I’m not expert in the locations of various files during the build phases of Fire.

FYI I rebooted the Mac, reset the iOS simulator, cleaned the build, etc.

9

What sks file ends up in the app bundle? Does the build log mention the file being copied?

10

I’ll check when I can get to that machine again. However, the fact that a CODE change had no effect seems to support the theory that it’s a different version of the bundle completely that’s being executed, and not the one that was just compiled.

11

Ah, yes. that could be. the Simulator CAN get flaky with that. I’ve found cases where only a full Simulator reset and a reboot of the Mac helped.

12

I did that, although maybe not in that order (I first rebooted, and then reset the simulator). I guess I can try the other way around.

13

it’s all black magic once it comes to this :wink:

that said “ps” should be able to show you the path for the process, on disk. try checking that, see what’s there (and compare it to what you have in /bin and /obj), and maybe deleting the .app bundle there, if it indeed doesn’t match.

14

Hmmm. Fire is creating the .app in bin/Debug/iOS rather than in bin/Debug/iOS Simulator, even though I’ve set the CrossBox Server to Local | iOS Simulator. So when it tries to run, it’s running the existing old version from bin/Debug/iOS Simulator and not the newly-compiled one.

Similarly Clean gets rid of the app in the iOS folder, not the iOS Simulator one.

15

Figured it out. Using the internal compiler (now the default, apparently), the .app bundle gets put in bin/Debug/iOS even when compiling for the simulator. I switched to the external compiler, and now the .app bundle gets put in bin/Debug/iOS Simulator as it should.

16

Ah yes, i should have mentioned that. The embedded mono (3.0.12) is old and has a bug in that xbuild doesn’t honor the .users file. Set tour target device to Simulator on project or configuration level, in settings.

Latest Mono 3.4 has that fixed, and i have a build thats ready for embedding, but it crashes on startup one out of fine times :(. That’s why the last beta still had 3.0.12 embedded. Did i mention that i’m really confident in Mono’s stability, these days? :frowning: