Changing relative position of runtime to linked assets?

Currently when I save a runtime, linked objects only work if I save it in the same folder as the .blend it was saved from. If I save it elsewhere, none of the linked assets are brought in. Is there a way to be able to save a runtime in a different relative position with the correct paths automatically? Note, I’m not talking about textures and sounds which can be packed. I’m talking about linked .blend file objects/groups which don’t seem to get packed at all.

When you linked in the objects did you check the relative paths button?

If you didn’t you can go to File > External Data > Make all Paths Relative

Thanks. Yeah, I used that already and resaved the runtime to the same effect… :frowning:

if relative paths are not working its probably a bug. could you report a bug in the tracker with a simple example?

Sure thing. Will do as soon as I can. I really appreciate all the effort you guys are putting into bug fixing atm for 2.49. :smiley:

OK, here’s the bug report:

Would be great if people not on Linux could try the 4 quick steps in the report and post if it worked for them or not.


When you save a runtime, it uses the linked paths in the .blend, If you want your game to be in a folder that stores all of the gamedata, you can just create another .blend that uses the game actuator to load that .blend then create a runtime of the new file. Otherwise your runtime will either need to be placed in the same folder as the .blend, or you can copy the folder with your .blends you linked in to the same folder as the runtime. The runtimes relative paths aren’t changed based on where you save it, and I don’t believe this is a glitch, although it could be a nice setting.

Thanks for the explanation Gomer. I don’t know though, it doesn’t seem unreasonable to me, for users to assume that a runtime should work regardless of which folder is selected in the save runtime dialogue. If it’s designed to only ever work in one folder, why give the user the option to choose a folder at all?

<begin monologue that has very little to do with you at all> It seems to me that a lot of bizzare usability issues, that just flat out look like Blender is broken to the average user, are ignored as bugs if highly experienced users have gotten used to them. A normal user, doing a normal action would end up with a non functional runtime with no warning or explanation.Even though it could be hard for people that understand the tech to get: “If it appears broken to the average user, then it is as good as broken to those users.” Saying “It’s supposed to work in that way that appears broken.” doesn’t increase Blenders adoption as most users won’t hear the message before giving up.

I’m grateful to you for taking the time to reply to my post with this work-around. I’ve just seen a few too many “It’s not a bug, it’s expected.” situations. I would really like to see Blender 2.5 get picked up by a whole new generation of artists who love it and spend their time creating beauty, rather than figuring out why it doesn’t appear to work.

I do appreciate that all the Blender dev’s are doing amazing work on both 2.49 and 2.5. That’s awesome. They’re awesome. Heck, I’ve seen your work and know that you’re awesome. While I’m embarrassed to complain, when I can’t code and haven’t produced work of your caliber, I’m just hoping it’s remembered that making a feature that appears to be broken, work as expected is as good as a new feature, and often requires a lot less work! :slight_smile:

Thanks again for your reply!
</monologue that has very little to do with you at all>

PS: Hope I haven’t scared you off dropping by Toronto some time!