createDisplay

[ManDay 0]

Okay. Sorry for the bad words about LAZA ( i guess it has been my fault).

Okay I got a bit forward now:

I copied the TeamSwitch-Display and created a facsimile called "RscDisplayManday" from it which I kept in the cpp:

This way I could be sure that there is no "exceptional" behaviour for "my" display defined anywhere else.

it worked. ( findDisplay 46 )createDisplay "RscDisplayManday"; does what it is supposed to do. behaviour:

dialog pop's up, when I click the mouse my character still shoots. when I press the appopriate buttons (WASD) it still moves. i only wasnt able to turn because the mouse itsself has changed to a mousepointer and doesnt control the characters heading anymore.

actually, i fear, that there is no way to create a dialog/display with the total controls retained. so for now - ill first trying to find out how to create a display out of data defined in the mission-folder itsself rather than in the engines config.cpp.

[weedomatic 0]

3.) I don't loose the feeling you are getting away from the topic (createDisplay) - will you please either stick there or stop to confusing me?

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.

[ManDay 0]

Mate try to reduce your replys (the helfull they are) to a minimum of important information. I feel taken for a **** fool when beeing explained loads of things I know by heart (must be some wrong in my head - still I ask you to)

*taking a deep breath* a'ight. it seems the point is that you store a handle for your display (meaning, the rsc) in the UI-EH.

Meanwhile, if you try to find your Rsc with ( findDisplay 515200 ) this will return NULL. this is the reason why my script didn't list the newly spawned display in the list.

why? yeah... WHY? why the heck will ( findDisplay 515200 ) ran in global namescope return NULL? Because normal displays are supposed to register themselfs in a global list which is browsed by findDisplay? I guess so.

anyway: At least using ressources as displays works now - thanks to your idea with the EH.

[weedomatic 0]

Quote[/b] ] ... when beeing explained loads of things I know by heart

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.

[ManDay 0]

A'ight. IDD = 300... didnt have this in my list as it only counted up to 200...

So what? Why do you use the fading ammo counter (thats the workarround with the most amazing bug i've ever heard of ) instead of IDD = 46 as said by me?

Dude, what's that? Where are we at? I think we already passed the point where we put things in the config. I did that this morning and it worked - dont you even read what I write

what we need to achieve is the CUSTOM (!!! displays working WITHOUT (!!!!!!! config modding!

[crashdome 3]

what we need to achieve is the CUSTOM (!!! displays working WITHOUT (!!!!!!! config modding!

How are you so sure it is even possible?

[ManDay 0]

It has to I am quite sure as it's possible to do so with Ressources.

If not this thread and my work is all for nothing

[UNN 0]

I think this is a usefull thread for all concerned.

[crashdome 3]

It has to   I am quite sure as it's possible to do so with Ressources.

If not this thread and my work is all for nothing    

I wouldn't say "for nothing". Someone has to at least try...

However, from what we know of OFP the rules are no different. The only thing new in ArmA seems to be the createDisplay and findDisplay command which seem to have functions more or less useful to addon config files and the dialogs/resources contained within. We can't even say for sure that a "display" is something new... not from what I've been reading anyway.

[weedomatic 0]

We can't even say for sure that a "display" is something new...

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.

[ManDay 0]

Just want to say "Thank you" again. Especially to you, weedomatic - your idea with storing a handle to the Rsc in the Rsc's EH is just perfect Thanks to you my next mission - this time a fun-mission with a lot of VFX - will be released soon.

Lets hope we somewhen will either figure a way to use custom displays with ( findDisplay 46 )createDisplay ... or BIS fixing some

Btw, a nice little hint we get from the Engine:

closeDialog display1

Error closeDialog: Type Display (dialog), exspected Number

"Display (dialog)"? What do we deduce from that?

[weedomatic 0]

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.

[ArMoGaDoN 0]

Sorry I started all this up again now - I have had no luck whatsoever getting any futher with displays either.

If someone from BIS happens to read all this, some sort of tutorial or documentation on how displays are supposed to be used might be a really useful thing right now :D