Research on OFP preprocessor

[General Barron 0]

Hello all! I was recently very unsuccessful in an experimental project of mine. But in the process, I found out some information on exactly how OFP handles configs and functions, at least in terms of preprocessing. Even though my attempted project was a failure, I figured it would be best if I shared what I had learned here.

-----------

What I wanted to do

My goal was to create an addon that could be configured by mission makers. That is, the addon's config would be loaded from the currently loaded mission, allowing mission editors to 'include addons' inside of their missions (though this addon would be required). Obviously this would be incredibly useful and exciting for mission makers.

How I wanted to do it

I had seen others (UNN specifically) include scripting commands in #defines in an addon config. Example thread:

http://www.flashpoint1985.com/cgi-bin....present

This intrigued me, and made me wonder if I could somehow include code in the config from inside of a mission (via the 'loadfile' scripting command). This might be done, for example, by using

#include loadfile PATH

Where PATH is a global variable (string) that the mission editor sets in his init.sqs, pointing to a config file inside his mission. Sounds great, right? Well, unfortunately it doesn't work. Nor does any variation on the above work. I tried for hours to no avail. Here is what I found out:

OFP's preprocessor

OFP uses a C preprocessor on both addon configs, and on files loaded via 'preprocessfile'. A preprocessor basically runs thru the file, and does things based on commands like #define, #include, etc. Wikipedia has a great article on it:

http://en.wikibooks.org/wiki/Programming:C_The_Preprocessor

HOWEVER, the preprocessor will only respond to certain commands. The following commands WILL work:

//

/* */

#define (including defines with arguments)

#ifdef

#ifndef

#endif

#undef

#include

#, ## (when inside a #define)

See the wikipedia link for details on how to use the above commands. The following commands will NOT work, however, and will result in NOTHING being returned (they will be removed from the code after it is preprocessed, however):

#error

#if

#elif

defined

Remember, OFP preprocesses configs, description.ext, and files loaded with 'preprocessfile' (functions). So the above preprocess commands will work with all of those things.

How useful is this?

Most of the preprocess commands aren't really that useful. Comments are obviously a huge help, as are includes and defines (all commonly used in configs). Conditional defines can also be EXTREMELY helpful, especially when you have repetitive code (for example, defining 100 similar magazines in a config, or 50 similar resources in a description.ext).

Other then that, well, this is up to you whether you can find a use for it or not. Many configgers already know all of this. I don't think anyone has really done much with functions loaded via 'preprocessfile' however.

What OFP does when it loads an addon

1) It runs the addon's config thru a .cpp preprocessor. If there are errors here, it will throw out an error saying simply "preprocessor failed on X".

2) It then runs thru the addon's config and translates it into whatever OFP uses. At this point, it will run any scripting commands found in the config (see below). Errors given here are more specific than ones given for #1 above.

This is the reason why my experiment can't work. FIRST preprocessor commands are run, THEN scripting commands are read. So there is no way to get the output of a scripting command into the preprocessor stuff--i.e. you can't #include a "loadfile". Nor can you use scripting commands to randomly #define something or not, and then check it with the #ifdef command. All you can do is use #define to PASTE a scripting command somewhere else in your config (as done by UNN in the linked thread).

Scripting commands in configs

Okay, you can include scripting commands in configs, but with certain conditions:

-They only work inside of a property assignment. That is, you can only have a scripting command after an = sign.

-They can not be used if the property requires a STRING (although they can be called from a stringtable via $. Basically, they can only be used when the property requires a NUMBER (not sure about arrays though).

-$ can only be used inside of a property assignment (can't be used to paste code directly into the config).

Possible ideas for use

Since my editor-config addon didn't work, I'd like to see the next-best thing: certain properties in addons being customizable by editors, via global variables.

For example, say you are making a weapon addon. You could include a second version of that weapon, where you write:

dispersion=GENB_disp;

Now, the mission editor can define GENB_disp in his init.sqs, and thus tailor the dispersion of that weapon to his individual desires. There are better ways this idea could be implemented, but that is the basic idea.

For example: an external 'config' file placed in the mission directory, contains an array, with each element representing a different property of the addon. Each element is separately loaded into each part of the config via a call, select, and loadfile command.

Addon makers could even 'help' the mission maker along, by letting him set one variable, which would affect a number of properties. For example, a single percentage could be multiplied by a tanks move speed, turn speed, and other movement properties. This would let mission makers increase or decrease the 'power' of a certain vehicle/weapon/whatever, by adjusting a single variable, allowing for better compatibility between addons for example.

[granQ 293]

does that work, or is it an idea you got?

I like the idea, would be easy for big packs like the swedish forcespack or FDF and so on to put "alternativ" configs into use.

Like less fuel for vehicles, for making the fuel trucks more used or like you say for dispersion..

[UNN 0]

Quote[/b] ]This intrigued me, and made me wonder if I could somehow include code in the config from inside of a mission (via the 'loadfile' scripting command). This might be done, for example, by using

Perhaps the best way of doing this is via stringtables. The guys over at MCar made good use of this option by storing functions. Although I'm not sure how quick the Localise command is at locating string table entries, given the potential size of the entire string table.

Ok I have not experimented much with this and it's based on the assumption that, addon configs can access string tables included in a mission folder?

Quote[/b] ]#include

I've never used #include with a pre-processed *.sqf file, just congig.cpp's. Would it just include the #defines within the external file, or any regular function code as well?

Quote[/b] ]What OFP does when it loads an addon

1) It runs the addon's config thru a .cpp pre-processor. If there are errors here, it will throw out an error saying simply "preprocessor failed on X".

2) It then runs thru the addon's config and translates it into whatever OFP uses. At this point, it will run any scripting commands found in the config (see below). Errors given here are more specific than ones given for #1 above.

Just to elaborate a little on the loading sequences, as I think there is a lot still to be learnt\used on this side of things.

This is my (rather sketchy) view on some of the startup procedures.

1) You start the game and it goes off and compiles (or does some sort of error checking) all the config.cpp's. It does not seem to check for the presence of files (p3d's, scripts e.t.c). I cant remember if it starts referencing the stringtable at this point.

It will also call any functions defined in the configs. The functions seem to be called from some reserved or temporary memory location. You cant set persistent global variables. If you try to create objects or run scripts from these functions, it crashes.

There is an option to pre-load *.rtm animations in the config. SO I guess this is done sooner rather then later?

I always wondered about this bit of config:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgAddons

{

       access=2;

       class PreloadBanks

       {

               class WeaponBIStudio

               {

                       list[]= {"LaserGuided\","ABox\","6G30\","Kozl\","G36A\","MM-1\","Steyr\","Bizon\","XMS\","M41a\"};

               };

               class MiscBIStudio

               {

                       list[]={"Flags\","VoiceRH\"};

               };

       };

       class PreloadAddons

       {

               class WeaponBIStudio

               {

                       list[]={"LaserGuided","6G30","Kozlice","G36A","MM1","Steyr","Bizon","XMS","M41a"};

               };

               class MiscBIStudio

               {

                       list[]={"Flags1","VoiceRH"};

               };

               class ResistanceBIStudio

               {

                       list[]={"Noe"};

               };

       };

};

I guess it's something to do with Resistance overriding some of the hard coded addons of the original OFP, like the Laser Designator? Weapons seem to work differently to vehicles to, as you don't have to create them with any special command like createvehicle, camcreate e.t.c

2) At some point before you hit the game menu, it must load all the required addons, stringtables and map data for the interface. You know the guys walking across the desert island with the wrecked vehicles scattered about. AFAIK The mission exists in it's own reserved memory, I could not set persistent global variables e.t.c using the start-up mission. Depending on the intro mission, I guess it could include combat? So it would have to load the weapons data e.t.c

3) The mission Editor. Ok, I only really know about this one. When you enter the mission editor and double click to place a unit, OFP reads though all the addons to determine what it can and cant display (side,scope,type e.t.c). So with a function assigned to scope, it will calculate it every time you place a unit. Again, no global variables can be carried over to the actual mission once it's run.

4) The last one is obvious, OFP has to load all the p3d's and samples e.t.c once you start the mission.

I'm sure there are more stages and properties we could access, perhaps for pbo missions and the MP interface? But the only way to debug the loading procedures is to find properties like Scope & Dispersion (as GB mentioned). That allow you to call functions that return messages.

Quote[/b] ]For example, say you are making a weapon addon. You could include a second version of that weapon, where you write:

dispersion=GENB_disp;

Now, the mission editor can define GENB_disp in his init.sqs, and thus tailor the dispersion of that weapon to his individual desires. There are better ways this idea could be implemented, but that is the basic idea.

Does this work? I've been looking for config properties that call functions at mission startup. I assumed they were all pre-calculated when OFP starts up.

If it does work, then that’s another reference stage for the configs:

5) In Game - Calculates config weapon properties according to ammo type e.t.c

[suma 8]

Since my editor-config addon didn't work, I'd like to see the next-best thing: certain properties in addons being customizable by editors, via global variables.

For example, say you are making a weapon addon. You could include a second version of that weapon, where you write:

dispersion=GENB_disp;

Now, the mission editor can define GENB_disp in his init.sqs, and thus tailor the dispersion of that weapon to his individual desires.

This probably will probaly not work at all, and it certainly will not reliably.

I think preprocessor variable space is kept separate from mission variable space, therefore I doubt you could even force the preprocessor to load the variable in the first place, but I am not completely sure here and I have not enough time to verify this with source code archive.

Even if you could be able to force config loader to parse mission variables, the weapons loaded this way are not necessarily discarded when the mission ends. When you start another mission, it can reuse the weapon definition if it is still in the memory, and its own values of GENB_disp.

[.kju 3245]

well not directly answering to your stuff, but i'd like to add some bits.

as a missionmaker you can make a map use different addons for the same units if you create any units by script and make some condition to load the different parts, like

(no ofp syntax)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">param2 = WGL

if (param2 == WGL) then 'load script (part) with WGL units'

else 'load BIS units'

of course not only via param possible - should be possible any time during the mission.

only addOns[]= and addOnsAuto[]= might get a bit tricky.

check DAC for a good example how to do this. (its way of assigning units to vars and use the vars instead of the actual different units in the scripts is even better of course).

next - you can set "stringtable variables" in config files for string based values ( only ! - afaik ) (didnt test all config strings ) and assign a value to the var inside a mission.

like i made an m1a1 with different weapon loadouts - m60 / a10 etc.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class M1Abrams: Tank

{

weapons[]={"Gun120","MachineGun12_7"};

magazines[]={STR_DN_M1A1_1,STR_DN_M1A1_2,"MachineGun12_7"};

and mission based stringtable.csv - properbly bin\stringtable.csv too.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">STR_DN_M1A1_1,Heat105,,,,,,

STR_DN_M1A1_2,Shell105,,,,,,

next - you can make defines in a config file and include the values from some other point, like an external text file  

WGL5 does just this to have a dynamic models system - user side switching between BIS / WGL / DMA models.

ECP does almost the same for their sound values. yet our system has two different levels. simple part, choose between the different configs in a text file - more complex: edit / make new model configs in the external text file.

with this approach one can make a dummy addon which has a interface where you can add any "addon" (package of all different kind of values for the defines).

so this should be what you are looking for GB  

[.kju 3245]

some chatlogs with ECP god Komuna  

i hope its readable and someone gets the idea. sorry i dont have the time these days to polish this information.

Quote[/b] ]You don't have to reload OFP or even reload missions. Design your resources through "description.ext" and alter the values through ingame variables. That's our little secret for animated graphics overlay.

Like the OFP startup we made for ECP.

Such as, in description.ext: { size = MyVar; }

And then, during the k

mission: MyVar = 2

Load that resource (titlecut, e.g.) and you'll notice that that value was assigned.

Check our "resource.cpp" for ECPLogo and the script startup.sqs to learn how to do such kind of trick.

by Komuna

Quote[/b] ]Q

ive got a question about testing resource changes via missions: you said by assigning values from the resource, i can change them while the mission right ?

Komuna

Exactly. But they must be reloaded.

Q

really ? as thats why i need to do know - without the approch. what i am doing is this:  

_ok = createDialog "RscDisplayClientWait"

Komuna

E.g.: cutRsc ["MyRsc","PLAIN"]; <wait for condition> ;cuttext["","PLAIN"] ; <resize MyRsc> ; cutRsc ["MyRsc","PLAIN"]

Q

description.ext contains the resource

Komuna

Oh...

Dialogs? That's different.

"cut" and "title" resources are the only ones requiring the trick I mentioned. The content of dialogs can be alteret with proper commands.

Q

without the need to reload the mission ?

or reload the dialog

Komuna

Two concepts are fundamental in my trick:

1 - You don't have to reload a mission to alter the config of a graphical resource.

2 - You can alter the content (text and controls) of a dialog through the commands designed for such purpose. Check the command reference.

1.1 - In adition, you can make those fancy "type writer" scenes with a resource overlay instead of a dialog. In that way, we won't see the cursor.

Q

okay. i am not too certain if i got your system right - #define ECPlogowidth 1.2 class Background1:RscBackgroundStripeTop { w = ECPlogowidth; or is there a difference with assigning a 'variable' and set the 'variable' at a certain area ?

Komuna

The code you've posted above becomes static ingame.

Now, instead of defining constants - which will be replaced by the value that follows in the #define - we just put "some text"... E.g.:

class Background1:RscBackgroundStripeTop { w = some_text;

Then, Ingame, we'll assign a value to the variable "some_text".

That's it!

There's a script inside "ECP_Effects/resources" that does the same, but can be called from anywhere. Take it. It will:

MMK_DynamicVariation.sqs  

Assign values to variables, call commands, variate the values of "some" variables.

The "variation" is the only true ability of that script.

For example:

Set a background colour variable for a pic overlay resource and then assign a variation of its values... You'll be able to have a pic whose background is constantly changing its colour.

Have you seen the OFP startup with ECP?

That's an examle of the "variable" trick potential.

Quote[/b] ]Q

you told me that its possible to use variable assignment for dialogs (like resource.cpp) - do you know in what kind of files its possible in general (i guess depends on the method when a file is loaded/re~)

Komuna

It's not a variable assignment...

A variable is a reference to data of a certain kind (or type). You can assign variables to data through memory references. Then, you'll pick that data

from the memory, through the link that the variable gives you.

Therefore, when you do

class Picture { <snip> size=Q_SIZE; };

Q_SIZE means nothing

However, the interpreter know that after "size=" it's supposed to be a value of a predefined kind.

Such value can be either literal data (size=2.1) or a reference (size=Q_SIZE), where Q_SIZE is supposed to "contain" data... I, ergo, say it's a variable.

Why a variable? Because that text as is means nothing.

If not referenced, Q_SIZE will be a null value.

However, you can assign -- ah... know it sounds better -- Q_SIZE to some data.

That's what we need to do during the mission.

Q

the reference can be dynamic right ?

Komuna

Well... The "reference" it's my way of classifing something abstract that happens by the interpreter-level. So, nevermind.

What I wanted you to understand is that you must CREATE that reference.

And the only way you can do such is by assigning values to variables through the old-fashioned way of OFP:

Q_SIZE = 3

You can do this in:

Code fields (units, triggers, waypoints), scripts, functions, functions from event handlers, etc...

Now, what you wanbt to know is where can Q_SIZE be a variable?

As far as I know, you can do it wherever you're supposed to put code... Eventhandlers, code fields, scripts, etc...

PLUS Description.ext!

That's the other place where a token like "Q_SIZE" can be understood as a variable.

Q

can you please specifiy "code fields" that we understand the same thing.

Komuna

Resource.cpp is, somehow, a sort of Description.ext, but systemwide.

The code fields are those places where you can add commands in the Mission Editor gui: in the trigger interface, the unit interface, the waypoint i...

[crashdome 3]

Since my editor-config addon didn't work, I'd like to see the next-best thing: certain properties in addons being customizable by editors, via global variables.

For example, say you are making a weapon addon. You could include a second version of that weapon, where you write:

dispersion=GENB_disp;

Now, the mission editor can define GENB_disp in his init.sqs, and thus tailor the dispersion of that weapon to his individual desires.

This probably will probaly not work at all, and it certainly will not reliably.

I think preprocessor variable space is kept separate from mission variable space, therefore I doubt you could even force the preprocessor to load the variable in the first place, but I am not completely sure here and I have not enough time to verify this with source code archive.

Even if you could be able to force config loader to parse mission variables, the weapons loaded this way are not necessarily discarded when the mission ends. When you start another mission, it can reuse the weapon definition if it is still in the memory, and its own values of GENB_disp.

What I think everyone desires with custom properties is possible if classes can be built via XML/XSL. I wrote about it in the suggestions for Game 2 scripting. I'm not sure if there are any Civilization fans among you, but if you examine their latest (Civ 4) you will find for example all unit classes defined in a style-sheet.

This makes building add-ons extremely simple. There are a 'bazillion' graphical XML editors out there and all possible properties are displayed right in front of you. Also, they are more type-safe during construction if you've got a good XML editor.

Incorporate the ability for an editor to override with their own XML and viola! easy as pie.

For example, assuming a weapon had a magazine type "M16" associated to the magazine property (don't know what it is called in OFP). The mission editor could very easy write up an XML document:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

<Weapon>

 <Type>M16</Type>

     <Magazines>

       <Type>MyNewM16Mag</Type>

       <AmmoCount>160</AmmoCount>

       <AmmoType>M16</AmmoType>

     </Magazines>

</Weapon>

A new 160 count clip for the M16!!

Horrid example... but atleast you get the idea... no need to reconstruct or inherit. Simply overwrites the magazine properties with the predetermined style.

Also, there are plenty of XML libraries out there to do the parsing for you. From a coding standpoint it is really nice. I've already coded into an application for my work the ability to write up XML classes for what we call "Job Activities".

As new equipment is purchased, this means tasks can change. I figured instead of rebuilding our software for new classes or even worse making an extremely generic class.. I built a system which will take a minimum number of properties, but allow custom properties if needed. Reads in via XML and stored in a database.

[vektorboson 8]

@Q

The values of properties are simply said "strings" which are evaluated through the scripting engine.

Following example, make a dialog, with one control, and place for the x-property

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

x = " hint ""x-property gets evaluated!""; 0.1 ";

But this is only possible for properties that are not really strings. The text-property will display the string that is assigned to it.

@CrashDome

I agree with you that we need better facilities to change game/config values; one such thing can be done with the scripting language.

I like the current Config-system, though I'd wish that BIS would write a less forgiving parser.

Also I think that inheritance is a really nice feature; I don't like looking on XML-code, but that's a personal preference.

[.kju 3245]

well dont worry about my stupidity - get the idea what komuna is talking about  

i am not certain if (plain) xml gives one the possibilities what the ofp syntax is offering.

[crashdome 3]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">I don't like looking on XML-code, but that's a personal preference.

I felt the same way until I started using a more graphical editor. Now, I am used to both graphical and textual representation and it isn't so bothersome for me anymore.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">i am not certain if (plain) xml gives one the possibilities what the ofp syntax is offering.

On the contrary, it allows for more possibilities. If property values can be read dynamically through XML rather than compiled, you are allowing for a true manipulation of an object. If you substitute references for property values or other methods as outlined above you are relying on extra layers of processing to produce the same results.

On top of that, you are confined to the scripting engine's limitations and structure is somewhat a hit-and-miss until everyone figures out all the possibilities. With XML, the style-sheets determine what can and cannot be done and puts the structure right in front of the designers face. If BIS wants to overhaul a class structure all they need to do is redefine the style-sheet to ensure add-ons which might conflict or break are refused because they don't fit the style-sheet guidelines. It also outlines very clearly what has or has not been changed.

In all honesty, it is no different than a cpp file other than the structure has been seperated from the content. It makes incredibly easy code to manage in the case of mod-making.

Now, a cpp file is compiled before the program even launches whereas in the case of Civ 4 it is compiled just prior to run-time causing an increase in load time. However, there is no reason why we couldn't pre-compile an XML document into a PBO and only read/compile XML that changes content much like the ext file is read.

The inheritance problem isn't so much of a problem... to accomplish the same feat in XML simply requires a different approach.

Another additional benefit is the ability to tie all of this to external products. Need a score ladder for your tournament? Want to manage weapons used in a mission from some sort of web database? Even more elaborate: Want to prevent cheating by sending data from server to clients rather than relying on all data files to be client-side? Simply allow URLs in place of just directories!

[crashdome 3]

Aside from my ranting about XML above....

If an add-on is made with something like the following (for example only}:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">side = {side player};

Is the expression evaluated once at loading and is thus the same across all creations of said add-on (be it placed in editor or createUnit)

Or would a creatUnit command re-evaluate the expression?

I know Suma said the definition could remain in memory, but is it a definition that has been evaluated or not?

[UNN 0]

Quote[/b] ]Is the expression evaluated once at loading and is thus the same across all creations of said add-on (be it placed in editor or createUnit)

Initialy side player, defaults to UNKNOWN.

If you go into the editor and place a single unit as a West player, Side Player still remains UNKNOWN.

If you run the mission then exit back to the editor, side Player will then be WEST e.t.c

If you create an addon with this as it's side property:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">side=Call LoadFile "<Addon Path>\UNN_Side.sqf";

UNN_Side.sqf:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">private ["_result"];

Call LoadFile Format ["Side %1",Side Player];

_Result=4;

If ((Side Player)==WEST) Then

{

_Result=1;

}

Else

{

If ((Side Player)==EAST) Then

{

_Result=0;

};

};

_Result

Initialy the addon will not show up in the editor, as it defaults to side Unknown (4).

But if you create a player as East and run the mission. When you return to the editor the Addon will be displayed under side East. You can repeat this by allocating different sides to the player then run the mission.

Quote[/b] ]Or would a creatUnit command re-evaluate the expression?

It looks like it would default to side UNKNOWN, if you ran a single player mission once. But I have this setup to experiment with vehicles, which always come out as CIV in the editor, when you use createvehicle. So I can't say for sure without trying it on infantry.

P.S This

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Call LoadFile Format ["Side %1",Side Player];

Is just a way of returning a message for debugging.

[crashdome 3]

Hmm... really I just wanted to see if it would evaluate once and for subsequent missions use the same evaluation once it is in memory.

Perhaps "side player" wasn't a good test.. from what I am reading of your post, it does look like it re-evaluates

[Guest]

Ah! Q! I almost forgot we had that conversation!

Eh, eh... Indeed, in that conversation I mention a reliable method to alter properties values, but it only works for UI resources classes in resource.cpp and descritpion.ext.

This is an old object of study on which I've wasted a considerable amount of time. I remember trying to hack description.ext a few years ago so that I could actually configure addons. I meant to add new classes or overwrite the existant class properties from <span style='font-family:Courier New'>cfgVehicles</span>, but it didn't work at all.

When I found I could set properties with variables in resource.cpp, I tried the same in config.cpp too. Soon I'd be struck by disappointment; but, at least, I already had something to play with: animated UI. Then, I messed up with preprocessors and tried to dynamically alter or add properties during a mission. The result was always the same as before.

Therefore, I concluded: OFP configuration is interpreted when the game loads and stays static until the game shuts down. That also explains why there are seperate configuration files: config.cpp is a static configuration containing gameplay data, and multiplayer stability depends on that; resource.cpp classes are individualy interpreted when OFP receives instructions to load and draw the UI elements -- they won't be re-interpreted once an element is loaded/drawn, which justifies having to execute titleRsc or equivalent command everytime I want to see modifications on the same element class. The dynamics of UI resources was implemented so that mission makers could add new UI elements, such as text, images, etc.; and description.ext is the file in which it can be achieved, as well as cutText and titleText commands.

On behalf of my conclusion, I had quit on researching any further methods to alter ingame configuration. Now, I rather mess with preprocessors in order to facilitate development (ECP).

P.S.: One of the most remarkable stuff in OFP is the configuration inheritance and overwriting possibilities. How about re-configuring most community addons in a single file in order to balance them? It's possible and has been done, but I wonder about hybridisation and memory load... Think about it.

[.kju 3245]

hehe

yes yes - if the access value permits overwriting, you can do really nice things to other peoples configs - in good terms.

i didnt fully research how the priority of loading / setting the values is made, but the main config seems to have it anyway.

[UNN 0]

Quote[/b] ]Perhaps "side player" wasn't a good test.. from what I am reading of your post, it does look like it re-evaluates

No, I'm afraid it does not look as thought you can.

Up to now the only config properties that do re-evaluate themselves are:

Scope and User Action conditions.

User action conditions are obvious, I guess scope is included because that works in conjunction with the editor mode Cadet & Vet e.t.c