Talk:Island Anims - Care and feeding

The problem - what problem?

One wrinkle remains however with Island Anims. They cannot be inside a pbo. Neither their own, nor any other. This then prevents relative references being made to them. They must be hard wired to a known folder.

I think this is not true. I see no reason for this. Opening Island Anim files is done the same way as any other file in OFP and it really should use pbo as appropriate.

--Suma 09:32, 17 July 2006 (CEST)

relative path to cutscene

haven't looked at this issue for some time now, but certainly intend to with ArmA

cutscenes[]={"..\ADDONS\doe1_anim\intro"};

the ..\

is the problem. It pulls pack to the root directory from (I dont' know where) and as such a hardwired folder is required. (you cant use an \addon(.pbo), nor, for that matter ..\addon(.pbo)

it can't find the addon(.pbo) as such.

if wrong, i'm wrong, but i am not aware of ANY user created island that has successfully attached an anim other than a hardwired folder (conventionally \Addons\anim\blah)

Mods (as opposed to addons) get round this by having their own \<Mods>\ directory, but they too, must hardwire the anim into (by convention) \<Mods\Addons\blah

--ook? 15:08, 17 July 2006 (CEST)

I see no need for anything complicated here. I would try something along lines of cutscenes[]={"doe1_anim\intro"}; --Suma 15:40, 17 July 2006 (CEST)

Haha, if that is possible, it would be an easy solution for a "problem" we had as we were "copying" from BI's configs... --Raedor 15:46, 17 July 2006 (CEST)

cutscenes[]={"doe1_anim\intro"}; never works. period. Been there, dun that. As for overly complicated, after five years 'out there', someone by now *would* have done just this (if it worked) considering the upwards of 50 very very good third party islands 'out there'. These people aint dumb, and their readme's always contain the corrollory to place the anim in \addons. Exception as I keep saying is when an entire mods addon is employed, but *even* then, it's hardwired it's just hidden from the user) --ook? 16:02, 17 July 2006 (CEST)

This got my interest and I launched debugger with 1.96 to see what is really going on. The path to the Island Anim is always constructed started with "anims". This means the anim can be placed in the anims.pbo, which is what all anims done by us do (and they really work from that pbo), but not in any other pbo, because it is not possible to reach pbo files using relative parent directories like .., only plain files. The path you receive in the end in the example quited in the article looks like this: "anims\..\WinterEveron\ADDONS\doe1_anim\intro.WinterEveron" --Suma 07:07, 18 July 2006 (CEST)

am hoping you meant anim.pbo in the dta folder <>. At least this is now an explanation of _why_ the .. is required for 3rd party anims and explains the need for a hardwired address from the flashpoint root, i might try and word that into the blurb providing I dont' confuse the issue further.

'relative' paths inside pbo's.

this seems an appropriate place to ask Suma for the following with config.cpp's since it's (partially) related to above.

we all have a bugger of a time with

icon=\ActualRealFileNameOfPbo\blah;

It would be *really* *really* good for us if, in ArmA say, we can start using inherit filepaths INSIDE the pbo such as

model=RightHere.p3d;
picture=AnyFilePath\Inside\Pbo\thing.paa;

ie we can avoid the disaster of having a hardwired, set in concrete, NAME of pbo, because we are unable to ever give it a revision number as a result. Eg MyGreatAddonV1.1.pbo

--ook? 02:10, 19 July 2006 (CEST)