Arma Dialog Editor Preview

[General Barron 0]

Great work, and something that OFP/ArmA has always needed.

Anyway, just to sort of build on what you've already found out... you shouldn't really look at that giant list of parameters and go thru them one by one. Rather, you should be thinking in terms of control types (type = CT_xxx).

As you already noticed, not all control types use every parameter. Also, some (many) parameters do different things depending on what control type they are used in.

So you would be better off setting up each individual control type, then testing each individual parameter within that control type.

As a hint, you can find only the required parameters for each control type by simply leaving all parameters out (except type=), then trying to load the dialog. An error message will pop up, saying you are missing parameter XXX. Add that parameter in, then you'll get another error message telling you to add parameter YYY, and so on for every required parameter.

Oh yeah, to make things even more complicated: sometimes different styles (style = ST_xxx) for the same control type means that the same parameters act different. This isn't very common, but I did notice this behaviour in resources, so I'd assume the same could be true of dialogs.

Last thing, please do more work and make a resource editor as well! Resources are *very* similar to dialogs (only simpler), so this couldn't be too much more difficult to add in... see my tut on OFPEC for more info on resources.

[ColonelSandersLite 0]

Anyway, just to sort of build on what you've already found out... you shouldn't really look at that giant list of parameters and go thru them one by one. Rather, you should be thinking in terms of control types (type = CT_xxx).

As you already noticed, not all control types use every parameter. Also, some (many) parameters do different things depending on what control type they are used in.

So you would be better off setting up each individual control type, then testing each individual parameter within that control type.

As a hint, you can find only the required parameters for each control type by simply leaving all parameters out (except type=), then trying to load the dialog. An error message will pop up, saying you are missing parameter XXX. Add that parameter in, then you'll get another error message telling you to add parameter YYY, and so on for every required parameter.

I already know all of that. The only reason I'm running straight through the list right now is to sort the junk out and place what I can by simple logic. Just by doing a simple search for each parameter in ui.pbo and Bin.pbo I can tell how a parameter is used in general. It's easy to identify if it's just junk the game accesses directly in various dialogs (so worthless to everyone else). If on that search, the parameter type is only used in listboxes, that's a pretty solid hint that it's unique to list boxes. Sometimes simple logic is enough (Hmm... wonder what colorRoads[] does? Damn these cryptic names...)

So basically, my first pass is just to clean my list out, and build a list (as much as possible) of what parameter types go to which controls. There are 2 benifits of doing this like this:

First, I discover any properties that are completely undocumented and unknown of by the community at large. The last one I hit was blinkPeriod[] which makes the text fade in and out in the amount of time specified.

Second, I know roughly what goes where and the method of calling the parameters before I start really activly testing for exact behaviours of each parameter on control. Therefore, shorter list and much less time consuming.

Oh yeah, to make things even more complicated: sometimes different styles (style = ST_xxx) for the same control type means that the same parameters act different. This isn't very common, but I did notice this behaviour in resources, so I'd assume the same could be true of dialogs.

Last thing, please do more work and make a resource editor as well! Resources are *very* similar to dialogs (only simpler), so this couldn't be too much more difficult to add in... see my tut on OFPEC for more info on resources.

And to make it even worse, I have a small list of styles that are completely undocumented...

I'm not sure what you mean by resources. CutRscs and TitleRscs maybe? You have a tutorial on that.

I skimmed it and would suggest that CutRscs and TitleRscs and any others are not in fact some entity seperate from dialogs. They're just dialogs. The only difference is that they're called differently by the game, and the game automatically disables certain things. From the point of view of dialog design, they appear to be identical.

One thing I noticed skimming that though it is that this is totally incorrect:

Quote[/b] ]

//Don't know what this does. with 3D dialogs, this lets the user

//move the dialog around; but I have no idea what it does with cutrscs

movingEnable=false;

movingEnable lets the player move when the dialog is displayed, not makes it movable.

To make a dialog movable you need to specify moving = true in one of the controlsBackground classes. You can then click and drag anywhere in the area of that control to make the dialog move. If you click on another area of the dialog that's not in that control, the dialog doesn't move.

Example:

With this example, clicking and dragging anything but the black background means that the player can move the dialog.

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

class ParticleCircleDialog

{

idd = -1;

controlsBackground[] = {Back, DialogFrame, TitleBox, ControlPanel};

class Back : FullScreen_Black_Back{};

class DialogFrame : MainBack

{

moving = 1;

x = 0.05; y = 0.05; w = 0.9; h = 0.9;

};

class TitleBox : TitleBack

{

x = 0.0625; y = 0.0625; w = 0.875; h = 0.045;

};

class ControlPanel : ControlBack

{

x = 0.0625; y = 0.1075; w = 0.875; h = 0.7745;

};

objects[] = {};

controls[] =

{

Txt_1,

Btn_Close

};

With this example, you can only move the dialog by clicking and dragging the titlebox.

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

class ParticleCircleDialog

{

idd = -1;

controlsBackground[] = {Back, DialogFrame, TitleBox, ControlPanel};

class Back : FullScreen_Black_Back{};

class DialogFrame : MainBack

{

x = 0.05; y = 0.05; w = 0.9; h = 0.9;

};

class TitleBox : TitleBack

{

moving = 1;

x = 0.0625; y = 0.0625; w = 0.875; h = 0.045;

};

class ControlPanel : ControlBack

{

x = 0.0625; y = 0.1075; w = 0.875; h = 0.7745;

};

objects[] = {};

controls[] =

{

Txt_1,

Btn_Close

};

Oh, and these are text verticle alignment:

Quote[/b] ]

ST_UP 3 //Don't know what these do

ST_DOWN 4 //

ST_VCENTER 5 //(perhaps need to be combined with other styles?)

If you make a static text x = 0.25; y = 0.25; w = 0.5; h = 0.5; and set ST_VCENTER and ST_CENTER, the text will be centered in the static text area (vertical and horizontal). If you set set ST_UP and ST_CENTER, the text will be at the center-top of the box.

[crashdome 3]

One thing I noticed skimming that though it is that this is totally incorrect:

Quote[/b] ]

//Don't know what this does. with 3D dialogs, this lets the user

//move the dialog around; but I have no idea what it does with cutrscs

movingEnable=false;

movingEnable lets the player move when the dialog is displayed, not makes it movable.

Hmmm.. are you sure about that?

I've never seen a player able to move with a dialog up. I assumed it's because all controls (keys) get passed to the dialog instead of player control.

[ColonelSandersLite 0]

One thing I noticed skimming that though it is that this is totally incorrect:

Quote[/b] ]

//Don't know what this does. with 3D dialogs, this lets the user

//move the dialog around; but I have no idea what it does with cutrscs

movingEnable=false;

movingEnable lets the player move when the dialog is displayed, not makes it movable.

Hmmm.. are you sure about that?

I've never seen a player able to move with a dialog up. I assumed it's because all controls (keys) get passed to the dialog instead of player control.

Pretty sure.

I think it's designed to be used with cutscene resources and the like. For example, if you look in UI.pbo, the whole hud interface is just done with dialogs. You can move just fine with them open right ? I haven't gone around trying to figure out how to make a dialog that you can use to move though because I haven't had a chance to get to it. If I had to guess, I would think that you can't have any controls on the dialog that accept user input. That means no active text, no buttons, etc. I would likewise guess that 3d objects, static text, whatever would be allowed just fine.

One thing I'm absolutely positive about though is that it does not enable moving dialogs. That's what the moving command is for. I made that mistake creating my particle parameter utility when I was gearing up for the V2.0 release .

[General Barron 0]

Quote[/b] ]One thing I'm absolutely positive about though is that it does not enable moving dialogs. That's what the moving command is for.

Are you sure it doesn't just override the 'moving' parameter? That is to say:

if I've got a dialog with controls that have moving=true in them,

but I tell the dialog that movingEnabled=false,

then even clicking on those controls will not move the dialog?

Quote[/b] ]For example, if you look in UI.pbo, the whole hud interface is just done with dialogs.

I'm pretty sure the HUD's work with some hard-coded engine behavior. Just like the main game menu is done via configs, but it has special hard-coded behavior like quit the game, open a mission, etc.

So I'm saying, it isn't done JUST with dialogs.

Quote[/b] ]CutRscs and TitleRscs and any others are not in fact some entity seperate from dialogs. They're just dialogs. The only difference is that they're called differently by the game, and the game automatically disables certain things. From the point of view of dialog design, they appear to be identical.

Almost correct. Cut/titlerscs must be defined in class RscTitles, dialogs are defined outside of any base class.

Also, resources do not accept any input from the user (the mouse cursor isn't displayed), nor can they be affected by scripting commands in any way.

And yes, the control types are much more limited than what dialog control types are available (since they can't take user input).

The main advantage of resources is that you can still play the game normally while they are displayed.

But anyway, my main point is that they are so very similar to dialogs, that yes it would be nice, and perhaps easy, for support for them to be included in such an editor (basically you would just disable certain controls when creating one, and n the output file you would put them inside of class RscTitles).

[hoz 0]

What version of .net? I have 2.0 installed but I receive a trap error when I excute the exe.

edit: Ok I was a suckor and I downloaded all version of .net and still get an error when I start it up.

[zaphod 0]

a solution could be to build 2 dialogs for both ratios the user can select from mission start ... its more work but will fit best and is expandable to all other special cases like triple head and other ratios on more excusive monitors.

maybe there's a simple way to calculate these ratios inside the dialog editor automatically on save ... e.g. save as 4:3 ... save as 16:9 ...

it's just a suggestion ...

regards,

zap

[ColonelSandersLite 0]

Huh, missed generalbarron's last reply. I'll get to it when I've had some sleep...

What version of .net? I have 2.0 installed but I receive a trap error when I excute the exe.

edit: Ok I was a suckor and I downloaded all version of .net and still get an error when I start it up.

It *should* run on 1.1 or later. What version of windows are you running?

I can't really support specific errors right now since it's still very early WIP. I will see if I can't help you getting it to run at all for now though.

[hoz 0]

I'm running XP pro. I've reinstall 1.1 and no luck. Here is a pic of my error...

error

[ColonelSandersLite 0]

I'm running XP pro. I've reinstall 1.1 and no luck. Here is a pic of my error...

error

64 bit or 32?

Also, have you tried installing .net framework 3.0?

http://www.microsoft.com/downloa....lang=en

It *may* require it. I don't think it should, but it's possible.

Just to be sure, don't try to run it from the rar file. Make sure the whole thing is unpacked to some directory.

Also, I would suggest you make sure you have the correct versions of .net installed for your os. The x86 varient should not be installed on 64 bit xp for example.

Honestly though, at this stage, there's likely not a whole lot I can do for you. To be able to properly support it, I need to add debugging output and the like.

[hoz 0]

I'm running 32 bit and I have 3.0 installed and its unpacked in its own folder. I can wait till the next version to see if there is an improvement.

[ColonelSandersLite 0]

I'm running 32 bit and I have 3.0 installed and its unpacked in its own folder. I can wait till the next version to see if there is an improvement.

That's odd.

You're running the same os as me, and have the same versions of the .net platform I have installed, so it *should* run...

It's possible something else is interfering, but I don't know what.

I wonder if it's possible I uploaded the debugging build? That could potentially cause something like that, but then it would cause it for nearly everyone here.

I'll try rebuilding it here soon just to be sure that's not it.

[mrbean1112 0]

I am having the same problem... as Hoz

:-(

i think something is wrong with my .net though... because armaedit doesn't seem to like me either. gives me a memory error.

Im going to try microsoft update... and some other stuff. If i find a solution i'll letcha know.

[Nutty_101 0]

I'm running 32 bit and I have 3.0 installed and its unpacked in its own folder. I can wait till the next version to see if there is an improvement.

That's odd.

You're running the same os as me, and have the same versions of the .net platform I have installed, so it *should* run...

It's possible something else is interfering, but I don't know what.

I wonder if it's possible I uploaded the debugging build? That could potentially cause something like that, but then it would cause it for nearly everyone here.

I'll try rebuilding it here soon just to be sure that's not it.

Are any versions with classes or export ability due out anytime? Would be nice not having to test in arma as sometimes i boot myself out of the game due to fat fingers.

[Rommel 2]

lol, I was a sucker and thought the build you put on front page actually did something... back to learning dialogs then.

EDIT: Sorry for bumping a really old thread, just noticed the date!

[Mr Groch 0]

Don't work for me on Vista x64...

It is crashing on start... No error - just crash....