Display-only Dialogs

[ArMoGaDoN 0]

Been banging my head on this for weeks now.

I can get a non-interactive display-type dialog on-screen, no problem. This allows user to still walk around and shoot etc while the display-only-dialog stays on screen in the corner.

Using a label or text-box to display some text defined in description.ext also is no problem.

At runtime, no matter what I've tried, I cannot get that text to display any new updated information.  It seems set in stone and unable to change.

I have asked about this before, but maybe then I didn't explain this very clearly.

Does anyone know a way that this can be done, that will work and update the text-display to show new contents?

[igor drukov 0]

The way I understand it, you are confusing two things: resources, which are "hard-coded" in the description.ext, can't be updated and don't interfere with playing commands;

and dialogs, which can be updated and use a mouse-guided arrow for interaction, thereby stopping the player from walking and shooting and all.

AFAIK, there's no way of updating data without resorting to dialogs. Scripting gurus have had a conversation about this very topic here.

Hope that helps.

[zaphod 0]

but:

- what means the attribute "movingenabled=true" in resources ...

- what is the difference between a display and a dialog

- how is the ingame GPS-map created ... only hardcoded?

i have the same problem with upper right corner maps in berzerk games... i want it to act like ArmA GPS but you cannot zoom as you cannot alter texts as well...

it's just a resource shown by cutrsc

i didn't spend that much time about Displays, but i want to know, so i'll take a look, too.

regards,

zap

[igor drukov 0]

AFAIK, "movingenabled=true" means that you can change the position of the dialog on the screen.

I use the words "Resources" as opposed to "Dialogs" to refer to two different sets of commands: TitleRsc or CutRsc, as opposed to all the dialog commands, starting with "CreateDialog". This terminology is personal, but I believe it's quite clear. "Display", to me, is synonymous with "Dialog" because of the "FindDisplay" command.

I believe the GPS is hard-coded, yes. Let's hope I'm wrong!

[ManDay 0]

WarWolf @ July 16 2007,16:58)]Been banging my head on this for weeks now.

I can get a non-interactive display-type dialog on-screen, no problem. This allows user to still walk around and shoot etc while the display-only-dialog stays on screen in the corner.

How the f?

[Sol-TK 0]

Hiho,

you can update data in resources.

maybe this helps: _HUD.Intro.zip

In RSCTitles, you also have controls which you can manipulate with some of these commands.

ciao

[mandoble 1]

WarWolf @ July 16 2007,16:58)]I can get a non-interactive display-type dialog on-screen, no problem. This allows user to still walk around and shoot etc while the display-only-dialog stays on screen in the corner.

What are these??

EDIT:

Problem with controls in tittles is that they are affected and affect any tittleText or cutText present in the mission, including trigger text effects. Unless they may be put in some different layer ...

[crashdome 3]

Dont get your pants wet yet...

...from what I've gathered on this thread and others, somebody has merely re-discovered the difference between "Dialog" and "Resources" of OFP and nothing new has been presented otherwise.

..at least I cannot get any Resource controls to change.

[igor drukov 0]

Well you can actually update resources, as Sol-TK's extremely interesting example shows. But as ManDay showed in his thread too, you can't retrieve the idd of the created resources (well, I couldn't either).

I haven't found the way to use the Rsc on and off at will: once it appears, I can make it disappear and reappear once, but once only. What I did was globalvariablise the idd using the _this of the UnLoad EH. But it won't work after some time, and even freeze the game. I did some more tweaking, but of little interest.

Don't know if that helps, I'm just banging my head against the wall too.

[ArMoGaDoN 0]

Sorry, not trying to do anyone else's head in lol.

I mean Display not Dialog. Apologies if I confused my original question even further, believe or not I was trying to clarify...

Create a display resource in description.ext,

then using findDisplay to get the main screen ID, and then using createDisplay to create the on-screen display, which leaves your dude free to move.

The display itself has a ferame and a text element, which can display whatever text is defined in the resource definintion in descrition.ext, but no matter what I try I cannot get updated text into that display, for information display purposes.

It works FINE in a normal Dialog, but not a display, despite their apparent similarities - presumable there is shared code drawing the stuff, so why not allow updating with ctrlSetText?

Will take a look at that stuff posted above and let you know how I get on.

Thanks guys.

edit: hmm

that titleRsc in the HUD is interesting, has to be constantly reloaded though, but the createDisplay would be a better option if only it could have it's text updated.

Still playing, still banging head.

[weedomatic 0]

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.