productbuild chaning permissions on resources prob
Archives Forums/MacOS X Discussion/productbuild chaning permissions on resources prob
| ||
| Hi all, i'm having an annoying problem with productbuild (command line tool for making app store installer packages). Basically, i'm keeping my game assets (sounds, images, meshes etc.) in the resources folder of the app bundle, and productbuild is changing permissions on this folder and all files and folders contained within such that after the pkg file is installed the game is not able to load it's resources, and crashes. I'm using Minib3d, which may or may not be a cause. I can't seem to incbin stuff with that. Any clues? Cheers Charlie |
| ||
| MiniB3D 'mini fixes' version? That one has a fix I made that enables using streams on everything, even on incbin. I have a game (Fruzzle) being ported, and it can load textures and models from inside a zip file, inside the app bundle. I didn't sign up with Apple yet, so I can't comment on productbuild, I just hope it doesn't break stuff for me too :( But... it is changing file permissions to what? Read-only? If that's the case, check if any OpenFile/OpenStream are set to read only - trying to opening the file to read and write, or just write may indeed break things. Last edited 2011 |
| ||
| Oh, so i can incbin meshes+separate textures with the small fixes version then? I'll have to take a look. How does loading a .b3d mesh with a separate texture file work in this case? Cheers Charlie |
| ||
| It all works normally. Just think as the zip as being a folder :) I wouldn't recommend to incbin stuff - as it would consume 2x the same ammount of RAM (first inside the EXE loaded into RAM, second when MiniB3D loads it), but it will work the same way as being a 'normal file'. If you incbin both mesh and texture, loading the mesh *will* load also the texture. Last edited 2011 |
| ||
| Cool, i'll give it a whirl in the morning. Hopefully it'll fix things... Also, i've discovered that if i copy the app from where the installer puts it into a different folder, the permissions error disappears and the game runs as normal. I'm guessing this is probably a bug with the product build tool. Cheers Charlie |
| ||
| Ah cracked it! One for the small fixes version i reckon... On line 9 of TModel.bmx, change file=OpenStream("littleendian::"+f_name$e) to file=OpenStream("littleendian::"+f_name$,True,False) and suddenly things seem to be loading! woohoo! Cheers Charlie |
| ||
| great find! please post for the small fixes version, nice to have all the little gotchas swept up together, hopefully simon will have time to make them all official before too long, in the mean time, a more complete small fixes does the trick (thank god for it's implementation, has saved me having to re-implement my own fixes that I've forgotten about multiple times already when I jump between machines :0) |
| ||
| Ok, this works for me as i only need to read the meshes/textures etc. Are there any circumstances where you would want to load a model with write permissions? Because this would obviously cause problems for that purpose. Cheers Charlie |
| ||
| There's currently no way to modify an existing model in place, so no, there's no reason to write back to the file. If you had to make changes you'd have to overwrite it with a new model anyway. Further more you're not allowed to change files inside an application bundle (per apple documentation, and the reason that stuff get's readonly locked) so you wouldn't be allowed to even if you wanted to (in this circumstance). Theoretically you could load a model, tracking it's points in the file so when you make a change you could modify the file, but a) this is a huge amount of work b) why not just overwrite? all the model data is in memory at once so there's no problems with overhead and throughput c) how often do you make permanent changes to a mesh anyway? I could only see it being worth considering if you had an autosave system in a mesh editor and were working on VERY large meshes that take a while to re-save. In which case you'd probably write a bespoke loader/saver anyway... So IMO, go for it, lock it down! Afterthought: one tiny possibility would be changes to the header space (embeded copywrite etc.)... if it has one... and it's designed to be editable post creation (i.e. has extra room to pad things out). But again, I don't think it has this so pointless. Most importantly, as you've see, elevated permissions only cause problems. It's best to only ask for what you need so that this kinda thing doesn't happen (what about loading off a CD... locked app bundles on mac are one things, but read only media will have a place in distribution cycles for all platforms for quite some time...) Last edited 2011 |
| ||
| Heh, I've done that a long time ago in my build... thought it was also on minifixes, but glad you found it out :) |
   |