weedomatic

The number of ad hoc visible code-lines does not necessarily mean that the code de facto is simple. Hence, you should take a look at what's behind format, which is nothing but another function "hiding" code -- or rather executing code/things for you. So, the array-comparison function, when called/evoked, will result in "simple" code (per your definition) as well. However, as I said before, for the current "problem", the string-comparison is absolutely okay. The posted function remains a more generic solution, though. [Edit] Syntax

String-comparison is slow -- generally speaking, and not only in BIS' products. For such tiny strings, however, this might not really be an argument. I'd go for the suggested function, nevertheless.

Have you tried overwriting (e.g.) buildings' event handlers (e.g. the init-event handler) directly in your config yet? I.e. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//... class SomeBISBuilding{  //...  class EventHandlers  {    init =""; // Exec or call custom script here  }; //... }; Just a guess, cannot verify anything at the moment.

Implement a CfgFaces class in your addon-config (e.g. "NightOpFaces") containing an inner class defining the faces you want (e.g. "NightOpFace1, ..., "NightOpFaceN"). Your soldier-classes then just need to point to theses custom faces via attribute faceType, e.g. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> faceType = "NightOpFaces"; Faces are picked randomly, just like with regular soldier-classes, only that this time your faces are the range.

Units' behaviour(-s) are controlled by so called FSM's (finite state models)-files. You will have to program your own FSM or, most likely, use some FSM from other (combat) classes. If you search for posts containing "civilian AND FSM" within the last months, you will at least get multiple hints as where to start/go for your purpose.

isServer returns a value of type boolean, which is either true or false. You probably implied that, SNK, just wanted to make the implication explicit for the untrained programmer. Moreover, the whole construct ( ?: ) is just an abbreviated way for simple if-control structures (if-then). Edit: Markup, spelling

huh? Never mind, I just meant it does not necessarily have to be shown in order to change it.

Not really, if you mean visible as in showing it. AFAIR you can set and update text while the ui-element is not displayed ( i.e. ctrlShown _theControl == false), and show it at a later stage. The control certainly has to be enabled and active, though, no doubt. @Manday: Are there really such things as Transformers in space? J/K, nm. B]

Just tested it in a mission with code from this thread and the wiki-page. Mission contains init.sqf and keyspressed.sqf, code follows: init.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">keyspressed = compile preprocessFile "keyspressed.sqf"; sleep 0.5; // Display needs to init itself, so we give it time if(!IsNull (findDisplay 46)) then {(findDisplay 46) displaySetEventHandler ["KeyDown","_this call keyspressed"];}; keyspressed.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">// If you want something to be done on // any key: // hint "SOME KEY PRESSED!"; switch((_this select 1))do { // Reacts to "F" key only case 33: { hint "F KEY PRESSED!"; }; }; Without putting the init.sqf to sleep for a moment, it wouldn't find the display. May be my machine, don't know.

GranQ, I think it's <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">faceType = "YOUR_FACE_CLASS";// in the (custom) soldiers' classes. At least faces did not work for me. Thanks for the hint, however, I also could find instant use for your method.

Source: (BI-wiki page) <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_control displaySetEventHandler ["KeyDown", ""] Using two scripts: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> //init.sqf start keyspressed = compile preprocessFile "keyspressed.sqf"; _display = findDisplay 46; _display displaySetEventHandler ["KeyDown","_this call keyspressed"]; //init.sqf end //keyspressed.sqf start switch((_this select 1))do {   //F key   case 33:   {    // What to do ...   }; }; //keyspressed.sqf end Some key-codes are also provided on the page above. Edit: Don't know if this will work with mouse-events -- haven't tested.

Controls are part(-s) of a dialog, but not the dialog per se. Amongst other things, the dialog serves as a named container for controls such as text-fields and the like associated with it (cf. wiki: Dialog control). Hence, you need (to create) a dialog that contains unique controls (via their idc), get access to the controls (e.g. via displayCtrl: wiki) and then use the ctrlSetText on an adequate control (text control) in order to set the text in an appropriate statement. There are some tutorials out there for creating dialogs, including the wiki-page above, but you might also want to check out dialogs with text-elements that others have already made available to the public.

Due to my successes in having a display that stays as long as I want it to, does not block movement, has one custom picture and one custom text resource that can be updated on runtime whenever I want, I wonder if you people here still couldn't accomplish this? Most knowledge came from the example contained in this thread and it now works on mission-as well as addon-level for me. Wrt. to interference(-s) with standard resources like titles used throught ArmA: I implemented a custom (title) resource (cpp->RscTitles) with custom controls, which is initiated via titleRsc once (or several times, see below). On load the resource executes a variable-assignment which I use in the scripts to manipulate the controls (runtime): E.g. switch them on and off via ctrlShow, change text, image, etc. The resource, however, has to be displayed long enough for the variable-assignment in the onLoad statement to actually work, i.e. so that the variable is available long enough. To ensure this, the duration attribute of my custom resource is set high (some code from my config.cpp, within RscTitles): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class HIT_DISPLAY { idd = 44200; movingEnable = 0; controls[] = {"BackImage","OverlayBODY","OverlayLEGS","OverlayARMS","OverlayHEAD","StatusText1","StatusText2"}; onLoad = "HIT_DISPLAY = (_this select 0);"; duration = 100000; class BackImage : RscPicture { idc = 515203; x = 0.9; y = 0.8; w = 0.06; h = 0.08; text ="\HitIndicator\stats_infantry_ca.paa"; sizeEx = 1; }; Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â // more control-definitions: } Â Another method to have the handle/var (e.g. HIT_DISPLAY) available when you want, is to execute (e.g.) titleRsc["HIT_DISPLAY", "PLAIN"] and get the controls every time you need the display, e.g. like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> // root display; HIT_DISPLAY globally availabe when titleRsc'ed the first time (HUD assigned in its "onLoad") display = HIT_DISPLAY; // text control 1 ctrlStatusText1 = display displayCtrl 515210; // text control 2 ctrlStatusText2 = display displayCtrl 515211; // image control ctrlImage = display displayCtrl 515203; So, this has to be done repeatedly. The execute-once method, however, forces you to show/hide the displays (if that is needed at all...) repeatedly, since it will only disappear after what is defined in duration. When I switched from mission- to addon-level, the main problem I had was to actually fire the titleRsc-command somehow on every mission start. I did this by having a script do that, which is executed in the CAManBase-init. I have a strange feeling that this overriding will cause me trouble at some stage, even though the script only does this for certain "men", i.e. the player/dummy at the moment. I hope someone understood what I meant. I will most likely 'release' my little addon soonish, so you can go and rip the code apart. I don't claim to have done something phenomenal nor really new, I am posting this since many had no success at all (?) and I did not notice any malfunctioning or modified standard resources until now.

AFAIR it was not my idea originally, but let's leave it like that. I also finally managed to get what I wanted. It is not 100% optimal, but my hit indicator works as an addon now: In other words, I have implanted custom RscTitles via cpp that I can control like I was able on description.ext-level. I will post my findings in that other display-thread.

Looking at other programming languages it makes perfect sense to have entities like GUI-elements generic in use: I.e. use one and the same abstract thing in different contexts. E.g. you take a frame or panel class and use their instances for (modal) dialogs, status bars, permanent ui's, menu items, tooltips, etc. I also wonder, if, say you manage to get hold of the "main" (RscIngameUI or something like that I suppose) at some stage, and you create custom child-dialogs, wouldn't their main-ui-dependancy/relation cause your items to behave like the rest? At least it seems to me, since I cannot override important information at the moment. I really hope that some attributes in top-level classes by BIS are not sealed to eternity. At the moment this (amongst probably many other things) seems to prevent custom behaviour by means of overwriting and expanding entities.

You do, maybe others don't. Although I am risking my head now: I finally managed to config(.cpp) a 'controllable' display, but the bugger is still attached to RscIngameUI, hence fading/in out with the e.g. the ammo-counter. Anyone? Edit: And, btw., I did not need to findDisplay them, I just passed them as argument(-s) and ctrlDisplay'ed the ui-elements. Edit II: I should not have been so naive to post after the first success: The "'controllable' display" was controllable once, when the resource (RscPicture) is loaded. After that, no more access. Plus, custom text-resources are not shown.

Not my intention. I am still talking about displays -- obviously this did not surface well enough only because I did not use createDisplay? No worries, I will stop confusing you after I've written the answer to your other question. I used the example from the somewhere above this post contained thread I mentioned (get it, the rest is based on its code). It contains two .hpp-files, and one description.ext file. The description.ext file actually only servers as the interface to the two .hpp-files, so it is pretty much empty wrt. to explicit code. Hence, the most interesting file is the hud.hpp file. Here is a snippet (from my modified version): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class RscTitles { titles[] = {"HUD"}; class HUD { idd = 515200; movingEnable =  1; duration   =  100000; fadein    =  0; fadeout    =  0; name = "HUD"; controls[]={"Text","Image","OverlayLEGS", "OverlayARMS","OverlayBODY", "OverlayHEAD"}; onLoad = "HUD=(_this select 0)"; // (A) class Text : RscStructuredText { idc = 515202; x = 0.8; y = 0.9; w = 0.6; h = 2; default = true; style = ST_LEFT; text = ""; }; class Image : RscPicture { idc = 515203; x = 0.9; y = 0.8; w = 0.06; h = 0.08; text ="stats_infantry_ca.paa"; sizeEx = 1; }; // and so on for "OverlayLEGS","OverlayARMS", // "OverlayBODY","OverlayHEAD" }; } Look at comment (A): onLoad = "HUD=(_this select 0)"; // (A). HUD is/will be the variable/handle that I use in scripts to control e.g. the text-ui-element (class Text : RscStructuredText). In addition the .hpp’s and .ext I have some sqf’s sitting in the mission folder. One of them is hudInit.sqf which is called on mission start (for example via init.sqf that also initializes the following variables (e.g. display)). Some of the script’s code: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> titleRSC["HUD","PLAIN"]; This one loads the resource for the first time and gives access to the display (see below). It is mandatory, and if you do not want the ui to show up directly, you can hide the display (see below, again). <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> // root display; HUD is assigned in hud.hpp (statement in onLoad-attribute) display = HUD; // redundant, actually // text control ctrlText = display displayCtrl 515202; // image control ctrlImage = display displayCtrl 515203; // more controls … // // hide controls at start of mission //ctrlOverlayBODY ctrlShow false; //ctrlOverlayLEGS ctrlShow false; //ctrlOverlayARMS ctrlShow false; //ctrlOverlayHEAD ctrlShow false; // etc. // Now you have variables (ctrl*) that can control the ui-elements. In another script this code <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> //code _text = format ["NEW WOUND: %1",_hitZone ] + "<br />"; _text = _text + format ["%1",getDammage player  ] + "<br />"; ctrlText ctrlSetStructuredText parseText _text; //code for example updates the text-ui-element I defined earlier. Don’t be irritated about the local variables. If you replace _text with a string like “Hello†in the last line, that would of course work as well. Hope, that helped a bit. Good luck with your project.

Yes, plus more -- but only within a mission, i.e. by means of custom files and code in the mission folder at the moment. Edit: Apologies, I was using titleRSC.

Using, manipulating, and raping displays/resources was not a problem as long as I was testing things on mission-level, i.e. I used description.ext, some hpp's and sqf's to build a custom, controllable display. My plan was to first get experience with resources per se by what I just said and then port it to a more generic level (addon) so no missions have to be altered to use the custom display(-s). Currently, the main problems are the dependency on the main ingame-UI (my display fades in/out, uncontrollably) and inability to manipulate the display during runtime. These problems I had not had and seen, before I switched to config-level -- and now I see more parallels to your "paradigm" as well. Right now I am trying to make the display a global object via variable-assignment in its onLoad-attribute, so that scripts within the addon can directly manipulate it. So far, all I get is a null-object, no matter how I try to make the display available to scripts within the addon. Calling scripts in onload of the display is successful -- passing the display to them as argument or assigning the display to a global var in onLoad did not work, sadly. I'll go and waste some more of my vacation and see if I can do something about that annoyance. Â Edit: Here's some more tools for your purpose: ArmA: Community Tools.

Things have come to a temporary halt for me as well. Access and dynamic interaction to/with resources worked well ... as part of a mission with some custom .hpp's,  description.ext. Porting the knowledge and code from  that to an addon, i.e. config.cpp, was trickier than I thought first, though. I have never gone really deep into making addons before, so I might be missing things due to lack of knowledge. However, my biggest problem atm circles around not being able to get hold of the display. Hence, I cannot get control of its children. Neither via idd nor via var' or the like does it seem possible to find(Display) it and assign the display to a var in order to manipulate its children. Changing idd's was not of great help, too. Your difficulties remind me of mine now, somehow . I will do some more research and tests later.

Really? I did not have any problems in telling the displays to do heterogeneous and dynamic/runtime actions (, yet!. Explain, please.

Hello, does it really have to be the createDisplay command? I myself tried getting createDisplay to somehow create a modal dialog, but I gave up due to insufficient documentation and too much time wasted due to knowledge induction processes, i.e. trial and error mainly. I found this Thread and especially the contained example particularly useful in creating displays that do not require any direct user interaction, i.e. non-blocking dialogs as some here put it. To put my part in a nutshell: Switching from createDisplay to titleRSC[] did it for me. Also, having the line onLoad = "GUI=(_this select 0)"; Â in your GUI-definition (mine is contained within a RscTitles class) gives you a nice reference (GUI in this case) to control your GUI-elements. If you didn't understand the last part, maybe you will after studying the example mentioned above or after some less lazy person has explained it. If, however, you are "just" trying to do something like this ('non-blocking' display, controllable controls), I might elaborate a bit more. I am not being arrogant, just lazy. Bye, W Edit: Grammar

Syntax highlighting rules can be customized in most of the mentioned editors fardwark mentioned. Plus, someone already did a custom ArmA-highlighter for notepad++. (Cannot be bothered to find the link now . Would be nice if that person also added the missing auto-completion vocabulary. Back to topic..) For .cpp-files, regular C++-style highlighting in most editors will do, however.

In the On Act. (on activation) field of the trigger put something like <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> enemyUnit setCombatMode "red"; where enemyUnit corresponds to the name you gave an enemy unit (not yourself) in its Name field. See setCombatMode for (some) more details.

You are using an illegal operator. Greater than or equal to is implemented as x >= y