desc.ext: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
(Redirect to Description.ext)
Tag: New redirect
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=basics=
#REDIRECT [[Description.ext]]
 
Until bis break their own code again, mission related file references seem to follow the following conventions
 
note this is incompatible with Resistance (and Arma1). the rules have changed. any missions coming from there are automatically broken.
 
=Mission Related File References=
 
'Mission Related' files are
*bikb
*mission.sqm
*desc.ext
*any.sqX file call (execvm, loadfile, etc)
*any.fsm
 
The only consistent thing about bis file references is that there is no consistency. You end up spending most of your productive effort fixing file calls with a lot less energy available to create a decent mission. Most efforts end in exhaustion, or "i'd like to, but can't figure it out", or, the author just lives with 'missing sound' and hopes the players don't notice. (even in official bis campaigns. Chernarus campaign is full of wrongly addressed or simply missing files)
 
No matter which way Bis swing the cat, now, or in the future, there are only four classes of file reference.
 
*\HardPath\
*\HardFile (no path, just a file)
*SoftPath\
*SoftFile
 
Innocently similar references will result in drastically different search paths for the file of interest.
 
SoftPath is my term to describe the opposite of \Absolute path references. It is '''not''', a relative reference. With the sole exception of #includes, Bi have never been able to implement relative addressing for anything, including p3d's and wrp's. This in turn has made it an exhausting nightmare to even consider moving objects into other pbo's, let alone it's config.cpp or related rvmats and fsm's.
 
'''In general''' a \hardpath is a specific reference to a pboprefix. '''In General''', if the engine sees a \hardpath it avoids looking in most other locations.
 
The following 'truth' was gleaned from an invaluable tool that saved days of hair pulling frustration:
 
http://technet.microsoft.com/en-us/sysinternals/bb896645
 
All honor and glory to Kju and Alef
 
 
The file search algorithm is a wonder to behold, it essentially breaks down to the following, and in the following order
 
*\PboPrefix\
*mission\
*campaign\Scripts\ or DtaExt\ if a campaign
*arma.exe\Scripts\ or DtaExt\ if not a campaign
*arma.exe\
 
Bis dont use Scripts\ or DtaExt\ in Arrowhead or A2 and have probably forgotten them.
 
==bikb==
 
bikb is just another hair pulling inconsistency. You can't specify softpaths or files, it results in a rpt error
 
Protocol bin\config.bin/RadioProtocol_EP1_EN/: Missing word fred\05bv01.ogg
 
 
speech[] = {"\fred\05bv01.ogg"};
speech[] = {"\05bv01.ogg"};
either reference searches in the following order
 
*mission\
*campaign\
*fred.pbo (in the obvious case of a \hardpath)
 
==sqX==
 
  expActiv = "this = [] execVM ""playsound.sqf"";";
  expActiv = "this = [] execVM ""fred\playsound.sqf"";";
*mission\
*arma\scripts\ '''OR''' campaign\scripts\
*fred.pbo '''IF''' a SoftPath
*arma\    '''IF''' a SoftFile
 
  expActiv = "this = [] execVM ""\playsound.sqf"";";
*arma\ ONLY
 
  expActiv = "this = [] execVM ""\fred\playsound.sqf"";";
*fred.pbo
*arma\fred\
==desc.ext==
loadScreen="fred\piccie.paa";
loadScreen="piccie.paa";
 
*mission\
*campaign\dtaext\ '''AND''' arma\dtaext\
*arma\ '''IF''' SoftFile
*fred.pob '''IF''' SoftPath
 
loadScreen="\fred\piccie.paa";
*fred.pbo ONLY
loadScreen="\piccie.paa";
*arma\  ONLY
 
just scream. it helps
=earlier notes=
----
*DescriptionRoot is the location of the description.ext
*This in turn becomes a CampaignRoot or a MissionRoot (see below)
*A \hardpath or lack of one changes the search order.
 
**A relative path first scans the DescriptionRoot. If not found, it scans \addons
 
DescriptionRoot\Relpath\to\file// is first scanned then
\RelPath\to\file
 
**A \hardpath of the same name ONLY looks in \addons
 
The same algorithm applies to mission.sqm but not bikb (and probably not fsm)
 
=DescriptionRoots=
 
Two types of description.ext exist, and they operated differently.
 
==missionroot==
 
The desc.ext is located in the primary folder of a mission.sqm
 
Addressing rules as above.
 
==campaignroot==
The campaign root is defined as being the start of the campaign folder. It contains
desc.ext
missions\
scripts\ (optional)
DtaExt\  (optional)
 
Note that there is no mission.sqm
 
'''IF''' this campaign is, in fact, an addon (a config.cpp exists) additional folders and files may exist. They, don't have relevence to the addressing space of a campaign other than they will be accessed like any other \addon.
 
 
A campaignroot\desc.ext is 'special' in that the only useable locations are dtaext\ (and scripts\)
 
===Scripts\===
scripts\ are a global entity for mission.sqms. They aren't desc.ext related.
 
not tested: an exec/eval in desc.ext might? access this folder
 
the scripts\ folder is accessed by mission.sqm's as a last resort if relative addressing is used.
===DtaExt===
unlike MissionRoot, you cannot have a sounds\ child folder as such (or any other)
 
All references are implied DtaExt (sigh)
 
sounds[]=fred
and
sounds[]=\fred
 
mean DtaExt\fred
 
'''Not tested: \fred\...  might be scanned by the engine'''
 
In fact, the DtaExt default is quite pointless. Inconsistent as ever, campaignroot's can't have the same structure as missions. but, there's no reason anymore why they shouldn't.
 
Bis have crippled the original default folders of DtaExt\sounds for sounds, and DtaExt\Music for music. They must be fully specified as
 
sounds[]=Sounds\whatever; (which actually means DtaExt\Sounds\....
 
 
This isn't a bad thing, but there wasn't a reason to keep the dtaext at all!!!!
 
There may or may not be other 'special' folders, 'my documents'\arma\username and other trifles. But you can't rely on it or them. they are likely to break or disappear at whim. mission scripts eg seem to have default access to ca\data\scripts. Fool it is, who rely on Bis to maintain that.
 
Bis themselves dont actually use dtaext (or scripts) in any of their campaigns. Probably because their mission makers either weren't aware of them, or could understand them.
 
But, from not making used of the global architecture, means common sound files (and common scripts) are bloated in each mission that uses one, for any official campaign.
 
=other=
 
 
<pre>
class CfgRadio //straightfoward array of {filename,volume,pitch}
{
  sounds[]={};
  class Seq0{name="Seq0";  sound[]={"sound\09r06.wss", db-40, 1.0}; title=$STRM_09r06;  };
};
class CfgSFX
{
  sounds[]={hospoda2};
  class Hospoda2
  {
    name="Hospoda2";
    sounds[]={sound1};//<<<<<name of sound array
    sound1[]={"hospoda2.ogg", db-0,1, 1, 1, 1, 1};//who knows
    empty[]= {, , , , 1 , 5, 20};
  };
};
</pre>
=cfgSounds=
one hell of a mess with titleS note the plural
 
ofp used semi colons between
 
titles[]={StartTime,Text};
titles[]=
 
<pre>
class CfgSounds
{
  sounds[]={};
  class Seq1 {name="Seq1";  sound[]={"sound\09v07.ogg", db, 1.0};    titles[]={0,      $STRM_09v07};  };//standard
 
  class 11v01{name="11v01"; sound[]={"sound\11v01.ogg", db-05, 1.0}; titles[]={{0,0.4}, $STRM_11v01};  };
  class 11v04{name="11v04"; sound[]={"sound\11v04.ogg", db-05, 1.0}; titles[]={ 0,      $STRM_11v04,  {5.5,0.5}, $STRM_11v04a};    };
  class DX04v01
  {
    name="DX04v01";
    sound[]={"sound\DX04v01.ogg", db+60, 1.0};
    titlesfont="tahomaB24";
    titlessize=0.025;
  titles[]=
    {
      0, $STRD_DX04v01;
      10, $STRD_DX04v02;
    };
  }; //wierd
</pre>
 
=cfgENVsounds==
<pre>
class CfgEnvSounds
{
  sounds[]={dest};
  class dest
  {
    name="dest";
    sound[]={"sound\dest.ogg", db, 1.0};
    soundNight[]={"sound\dest.ogg", db, 1.0};//<<<<
    titles[]={};
  };
};
</pre>
 
 
=Scripts=
scripts are part of mission.sqm and \hardpaths to addons are valid. Therefore, all relative references in a mission.sqm (and their scripts) are relative to the mission.sqm, NOT the folder they are encountered in. (sigh)
 
expActiv="nul=[] execVM ""scripts\dialog.sqf""";
 
relative to mission.sqm
 
expActiv="nul=[] execVM ""\scripts\dialog.sqf""";
 
would refer to a (non existent) pboprefix 'scripts'
 
fowley kbAddTopic ["dialog", "scripts\dialog.bikb", ""];
 
again, relative to mission.sqm, even tho, this piece of text is in the 'scripts' folder.
 
Note that Campaign root scripts folder is implied if it cannot find file in the mission.
 
execvm thing.sqf // assumes it's in mission.sqm root, OR campaignroot\scripts
execvm Scripts\thing.sqf // will look in mission.sqm\scripts or campaignRoot\scripts\scripts
 
previously, mission.sqm\scripts and ~\sound were also a default folders. but it looks like they broke it.
 
==bikb==
 
    speech[] = {"\sound\02v1.ogg"};
 
similar to mission.sqm's and desc.ext, if the file is not found in a genuine addon, it's looked for in missionRoot. However:
 
'''you CANNOT have relative refereces'''
 
    speech[] = {"sound\02v1.ogg"};
 
 
goes off to wander land
 
this because of some hotfix patch in version 1.05, where previously, bikb couldn't access anything except addons
 
WHY to bis do this to themselves.
 
notes:
*bikb is only a convention. you can have any extension.
*the file cannot be binarised even tho it's classtext. This is marked to change at further engine revisions.

Latest revision as of 20:22, 22 April 2024

Redirect to: